- 25 3月, 2021 2 次提交
-
-
由 Nixon Enraght-Moony 提交于
Closes #80664
-
由 Nixon Enraght-Moony 提交于
-
- 24 3月, 2021 30 次提交
-
-
由 bors 提交于
Run analyses before thir-tree dumps Fixes #83048
-
由 bors 提交于
Expose str::SplitInclusive in alloc and therefore in std This seems to have been omitted from the beginning when this feature was first introduced in 86bf9629. Most users won't need to name this type which is probably why this wasn't noticed in the meantime. See #83372 for a different but related bug. ### Notes for reviewers I think I have got this right but TBH I am not very familiar with the relationship between core and std and so on. <strike>I also haven't don't any kind of test (not even a build) yet. I will do a local docs build to see that the type now appears in the std docs.</strike> I did a local docs build and it has made this type appear as `std::str::SplitInclusive` as expected The linkification of the return value from `str::split_inclusive` teleports me to the online url for `core::str::SplitInclusive`. I think this may be a rustdoc anomaly (similar to #79630 maybe) but I am not sure. Perhaps it means I haven't done the `std` -> `core` referrence correctly. I made this insta-stable since it seems like simply a bug. Please LMK if that is not right. *(edited to add:)* In particular, IDK how this ought to relate to the (?)current release process.
-
由 bors 提交于
implement `feature(const_generics_defaults)` Implements const generics defaults `struct Example<const N: usize=3>`, as well as a query for getting the default of a given const-parameter's def id. There are some remaining FIXME's but they were specified as not blocking for merging this PR. This also puts the defaults behind the unstable feature gate `#![feature(const_generics_defaults)]`. ~~This currently creates a field which is always false on `GenericParamDefKind` for future use when consts are permitted to have defaults. I'm not sure if this is exactly what is best for adding default parameters, but I mimicked the style of type defaults, so hopefully this is ok.~~ r? `@lcnr`
-
由 David Tolnay 提交于
-
由 bors 提交于
Rollup of 9 pull requests Successful merges: - #83051 (Sidebar trait items order) - #83313 (Only enable assert_dep_graph when query-dep-graph is enabled.) - #83353 (Add internal io::Error::new_const to avoid allocations.) - #83391 (Allow not emitting `uwtable` on Android) - #83392 (Change `-W help` to display edition level.) - #83393 (Codeblock tooltip position) - #83399 (rustdoc: Record crate name instead of using `None`) - #83405 (Slight visual improvements to warning boxes in the docs) - #83415 (Remove unnecessary `Option` wrapping around `Crate.module`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
-
由 Dylan DPC 提交于
Remove unnecessary `Option` wrapping around `Crate.module` I'm wondering if it was originally there so that we could `take` the module which enables `after_krate` to take an `&Crate`. However, the two impls of `after_krate` only use `Crate.name`, so we can pass just the name instead.
-
由 Dylan DPC 提交于
Slight visual improvements to warning boxes in the docs First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the [`text-shadow`](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow#browser_compatibility). For consistency the microscope has the black border too. Alternatively I had `drop-shadow(0px 0px 1px black);` in mind but its [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()#browser_compatibility) doesn't look as good and the blurry shadow probably doesn't look as good either. Then, I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum. But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. _only supported on Unix_). These are currently blue. I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform, your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance "This is available since 1.0.0". None of the current three box types (unstable, deprecated and portability) are that. I think purple is a better fit for it because it's kind of in the middle between "use it" and "don't use it". Deprecated is definitely "don't use it". To illustrate this better, here's a color spectrum: Blue = friendly, "use it". ![image](https://user-images.githubusercontent.com/35064754/112139891-9a6b0f80-8bd3-11eb-94e1-dc747a3d4cf9.png) Red = danger, "don't use it". And the purple in the middle (the color that the portability box now has) probably represents "use it if you have to", so it's not entirely friendly and not entirely a danger. That is why I think it fits. However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes. This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes: ![image](https://user-images.githubusercontent.com/35064754/112139327-ebc6cf00-8bd2-11eb-88ac-25219b43a1a0.png) ![image](https://user-images.githubusercontent.com/35064754/112139392-000acc00-8bd3-11eb-90c2-81feec93c521.png)
-
由 Dylan DPC 提交于
rustdoc: Record crate name instead of using `None` Fixes #83365. r? `@jyn514`
-
由 Dylan DPC 提交于
Codeblock tooltip position The codeblocks tooltips were misplaced. Normally, there is no top margin applied to a tooltip unless the codeblock is the first element of the doc block. The CSS rule was too vague though, applying it to all tooltips where the codeblock was the first child of its parent. Which can be easily seen with lists: Before: ![Screenshot from 2021-03-22 22-05-16](https://user-images.githubusercontent.com/3050060/112059812-a667ba80-8b5c-11eb-88dd-1c598ceb3766.png) After: ![Screenshot from 2021-03-22 22-06-31](https://user-images.githubusercontent.com/3050060/112059815-a7005100-8b5c-11eb-9e40-8fc57513e498.png) r? ``@Nemo157``
-
由 Dylan DPC 提交于
Change `-W help` to display edition level. `-W help` was not honoring the `--edition` flag when displaying the default lint level. It was using the edition for sorting, but not for the final display. This isn't important right now as there aren't any edition-specific lint levels. Also, the `declare_lint` macro is broken and doesn't even allow setting them right now. However, I figure it wouldn't hurt to fix this before I forget about it, in case edition-specific lints are ever used in the future.
-
由 Dylan DPC 提交于
Allow not emitting `uwtable` on Android `uwtable` is marked as required on Android, so it can't be disabled via `-C force-unwind-tables=no`. However, I found that the reason it's marked as required was to resolve a [backtrace issue in Gecko](https://github.com/rust-lang/rust/issues/49867), and I haven't find any other reasons that make it required ([yet](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Unwind.20tables.20are.20strictly.20required.20on.20Windows.20and.20Android)). Therefore, I assume it's safe to turn it off if a (nice) backtrace is not needed, and submit this PR to allow `-C force-unwind-tables=no` when targeting Android. Note that I haven't tested this change on Android as I don't have an Android environment for testing.
-
由 Dylan DPC 提交于
Add internal io::Error::new_const to avoid allocations. This makes it possible to have a io::Error containing a message with zero allocations, and uses that everywhere to avoid the *three* allocations involved in `io::Error::new(kind, "message")`. The function signature isn't perfect, because it needs a reference to the `&str`. So for now, this is just a `pub(crate)` function. Later, we'll be able to use `fn new_const<MSG: &'static str>(kind: ErrorKind)` to make that a bit better. (Then we'll also be able to use some ZST trickery if that would result in more efficient code.) See https://github.com/rust-lang/rust/issues/83352
-
由 Dylan DPC 提交于
Only enable assert_dep_graph when query-dep-graph is enabled. This is a debugging option. The only effect should be on rustc tests. r? ``@michaelwoerister``
-
由 Dylan DPC 提交于
Sidebar trait items order We were actually sorting `Symbol` and not `String`, creating a completely invalid sort result. I added a test to prevent regressions. r? ``@jyn514``
-
由 kadmin 提交于
-
由 bors 提交于
Rename `source` to `span` and `span` to `source` - Rename `clean::Item.source` to `span` - Rename `clean::Span::span()` to `clean::Span::inner()` - Rename `rustdoc_json_types::Item.source` to `span` - rustdoc-json: Rename `Import.span` to `Import.source` *See also the [discussion on Zulip][z] (this is a bit more than discussed in that conversation, but all the changes are related).* r? `@jyn514` [z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/get.20span.20of.20file.20from.20name/near/229603729
-
由 Camelid 提交于
The previous changes mean that we can now remove this `Option`.
-
由 Camelid 提交于
I'm wondering if it was originally there so that we could `take` the module which enables `after_krate` to take an `&Crate`. However, the two impls of `after_krate` only use `Crate.name`, so we can pass just the name instead.
-
由 Camelid 提交于
Co-authored-by: NJoshua Nelson <joshua@yottadb.com>
-
由 kadmin 提交于
-
由 kadmin 提交于
A bunch of nits fixed, and a new test for pretty printing the AST.
-
由 kadmin 提交于
-
由 kadmin 提交于
-
由 lcnr 提交于
-
由 varkor 提交于
-
由 kadmin 提交于
This currently creates a field which is always false on GenericParamDefKind for future use when consts are permitted to have defaults Update const_generics:default locations Previously just ignored them, now actually do something about them. Fix using type check instead of value Add parsing This adds all the necessary changes to lower const-generics defaults from parsing. Change P<Expr> to AnonConst This matches the arguments passed to instantiations of const generics, and makes it specific to just anonymous constants. Attempt to fix lowering bugs
-
由 Camille GILLOT 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
- 23 3月, 2021 8 次提交
-
-
由 bors 提交于
Remove assignments to ZST places instead of marking ZST return place as unused partially reverts #83118 requested by `@tmiasko` in https://github.com/rust-lang/rust/pull/83118#issuecomment-799692574 r? `@oli-obk`
-
由 Ian Jackson 提交于
This seems to have been omitted from the beginning when this feature was first introduced in 86bf9629. Most users won't need to name this type which is probably why this wasn't noticed in the meantime. Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>
-
由 r00ster91 提交于
-
由 bors 提交于
rustc: changes to allow an llvm update This lets LLVM be built using 2b5f3f446f36, which is only a few weeks old. The next change in LLVM (5de2d189e6ad) breaks rustc again by removing a function that's exposed into the Rust code, but I'll file a bug about that separately. Please scrutinize the `thinLTOResolvePrevailingInIndex` call, as I'm not at all sure an empty config is right. I'm also suspicious that a specific alignment could be specified in the call to CreateAtomicCmpXchg, but I don't know enough to figure that out. Thanks!
-
由 bors 提交于
Add `debug-refcell` feature to libcore See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Attaching.20backtraces.20to.20RefCell/near/226273614 for some background discussion This PR adds a new off-by-default feature `debug-refcell` to libcore. When enabled, this feature stores additional debugging information in `RefCell`. This information is included in the panic message when `borrow()` or `borrow_mut()` panics, to make it easier to track down the source of the issue. Currently, we store the caller location for the earliest active borrow. This has a number of advantages: * There is only a constant amount of overhead per `RefCell` * We don't need any heap memory, so it can easily be implemented in core * Since we are storing the *earliest* active borrow, we don't need any extra logic in the `Drop` implementation for `Ref` and `RefMut` Limitations: * We only store the caller location, not a full `Backtrace`. Until we get support for `Backtrace` in libcore, this is the best tha we can do. * The captured location is only displayed when `borrow()` or `borrow_mut()` panics. If a crate calls `try_borrow().unwrap()` or `try_borrow_mut().unwrap()`, this extra information will be lost. To make testing easier, I've enabled the `debug-refcell` feature by default. I'm not sure how to write a test for this feature - we would need to rebuild core from the test framework, and create a separate sysroot. Since this feature will be off-by-default, users will need to use `xargo` or `cargo -Z build-std` to enable this feature. For users using a prebuilt standard library, this feature will be disabled with zero overhead. I've created a simple test program: ```rust use std::cell::RefCell; fn main() { let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let _first = val.borrow(); let _second = val.borrow(); let _third = val.borrow_mut(); }); let _ = std::panic::catch_unwind(|| { let val = RefCell::new(true); let first = val.borrow_mut(); drop(first); let _second = val.borrow_mut(); let _thid = val.borrow(); }); } ``` which produces the following output: ``` thread 'main' panicked at 'already borrowed: BorrowMutError at refcell_test.rs:6:26', refcell_test.rs:8:26 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at 'already mutably borrowed: BorrowError at refcell_test.rs:16:27', refcell_test.rs:18:25 ```
-
由 Camelid 提交于
Now that we record the crate's name in its `clean::Item`, pushing the crate name onto the `stack` causes duplicate paths. E.g., the URL generated for the path `::foo::bar::baz` would be something like ../foo/foo/bar/baz With this commit, the URL is corrected to ../foo/bar/baz
-
由 bors 提交于
Rollup of 7 pull requests Successful merges: - #80705 (Update Source Code Pro and include italics) - #81917 (Update RELEASES.md for 1.51.0) - #82732 (Remove theme.js file) - #83356 (rustdoc: Replace pair of `Option`s with an enum) - #83384 (rename :pat2018 -> :pat2015) - #83385 (
⬆ rust-analyzer) - #83389 (add rust-analyzer rustc_private option in librustdoc Cargo.toml) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup -
由 Camelid 提交于
-