Rollup of 8 pull requests #77470
Merged
Rollup of 8 pull requests #77470
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Deriving debug prints all the values including keys. But ValuesMut struct should only print the values.
The thread local LOCAL_STDOUT and LOCAL_STDERR are only used by the test crate to capture output from tests when running them in the same process in differen threads. However, every program will check these variables on every print, even outside of testing. This involves allocating a thread local key, and registering a thread local destructor. This can be somewhat expensive. This change keeps a global flag (LOCAL_STREAMS) which will be set to true when either of these local streams is used. (So, effectively only in test and benchmark runs.) When this flag is off, these thread locals are not even looked at and therefore will not be initialized on the first output on every thread, which also means no thread local destructors will be registered.
This connects to rust-lang/rustup#794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release, we write duplicate manifests to `stable`. With this change, only when we're doing a stable release, also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request, say, `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order).
adt_destructor by default also validates the Drop impl using
dropck::check_drop_impl, which contains an expect_local(). This
leads to ICE in check_const_item_mutation if the const's type is
not a local type.
thread 'rustc' panicked at 'DefId::expect_local: `DefId(5:4805 ~ alloc[d7e9]::vec::{impl#50})` isn't local', compiler/rustc_span/src/def_id.rs:174:43
stack backtrace:
0: rust_begin_unwind
1: rustc_span::def_id::DefId::expect_local::{{closure}}
2: rustc_typeck::check::dropck::check_drop_impl
3: rustc_middle::ty::util::<impl rustc_middle::ty::context::TyCtxt>::calculate_dtor::{{closure}}
4: rustc_middle::ty::trait_def::<impl rustc_middle::ty::context::TyCtxt>::for_each_relevant_impl
5: rustc_middle::ty::util::<impl rustc_middle::ty::context::TyCtxt>::calculate_dtor
6: rustc_typeck::check::adt_destructor
7: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::adt_destructor>::compute
8: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
9: rustc_query_system::query::plumbing::get_query_impl
10: rustc_mir::transform::check_const_item_mutation::ConstMutationChecker::is_const_item_without_destructor
Fix Debug implementations of some of the HashMap and BTreeMap iterator types HashMap's `ValuesMut`, BTreeMaps `ValuesMut`, IntoValues and `IntoKeys` structs were printing both keys and values on their Debug implementations. But they are iterators over either keys or values. Irrelevant values should not be visible. With this PR, they only show relevant fields. This fixes #75297. [Here's an example code.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0c79356ed860e347a0c1a205616f93b7) This prints this on nightly: ``` ValuesMut { inner: IterMut { range: [(1, "hello"), (2, "goodbye")], length: 2 } } IntoKeys { inner: [(1, "hello"), (2, "goodbye")] } IntoValues { inner: [(1, "hello"), (2, "goodbye")] } [(2, "goodbye"), (1, "hello")] ``` After the patch this example prints these instead: ``` ["hello", "goodbye"] ["hello", "goodbye"] [1, 2] ["hello", "goodbye"] ``` I didn't add test cases for them, since I couldn't see any tests for Debug implementations anywhere. But please let me know if I should add it to a specific place. r? @dtolnay
Write manifest for MAJOR.MINOR channel to enable rustup convenience This connects to rust-lang/rustup#794. It's hard to remember if there have been patch releases for old versions when you'd like to install the latest in a MAJOR.MINOR series. When we're doing a stable release, we write duplicate manifests to `stable`. With this change, only when we're doing a stable release, also write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup (and any other tooling that builds Rust release URLs) to request, say, `1.45` and get `1.45.2` (assuming `1.45.2` is the latest available `1.45` and assuming that we never publish patch releases out of order). I tested the best I could; it's a bit hard to get everything set up right to be able to run the build-manifest tool. But I was able to run it with a release of "1.45.2" and in addition to the files like `channel-rust-1.45.2.toml` and `channel-rust-stable.toml` (and other manifests) that I got before this change, I now get `channel-rust-1.45.toml`. I believe this change to be safe to deploy as it does not change or remove anything about manifests, just adds more. The actions in rust-central-station that interact with manifests appear to use wildcards in such a way that it will pick up these files without any problems. There will need to be changes to `rustup` before `rustup install 1.45` will work, but we can wait for a stable release and stable patch releases to happen with this change before making the `rustup` changes, so that we're not committing to anything before we know it works.
…=pickfire Add missing examples for Fd traits Not sure what happened here... This is a reopening of #77142 r? @Dylan-DPC
Bypass const_item_mutation if const's type has Drop impl Follow-up to #75573. This PR disables the const_item_mutation lint in cases that the const has a Drop impl which observes the mutation. ```rust struct Log { msg: &'static str } const LOG: Log = Log { msg: "" }; impl Drop for Log { fn drop(&mut self) { println!("{}", self.msg); } } LOG.msg = "wow"; // prints "wow" ``` r? @Aaron1011
…=dtolnay
Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used.
The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However, every program will check these variables on every print, even outside of testing.
This involves allocating a thread local key, and registering a thread local destructor. This can be somewhat expensive.
This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So, effectively only in test and benchmark runs.) When this flag is off, these thread locals are not even looked at and therefore will not be initialized on the first output on every thread, which also means no thread local destructors will be registered.
---
Together with #77154, this should make output a little bit more efficient.
Permit ty::Bool in const generics for v0 mangling This should unbreak using new-symbol-mangling = true in config.toml (once it lands in beta anyway). Fixes #76365 (well, it will, but seems fine to close as soon as we have support) r? @eddyb (for mangling) but I'm okay with some other reviewer too :)
|
📌 Commit eff6398 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions, checks-azure |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Failed merges:
r? @ghost