Reattach all grandchildren when constructing specialization graph.
Specialization graphs are constructed by incrementally adding impls in the order of declaration. If the impl being added has its specializations in the graph already, they should be reattached under the impl. However, the current implementation only reattaches the one found first. Therefore, in the following specialization graph,
```
Tr1
|
I3
/ \
I1 I2
```
If `I1`, `I2`, and `I3` are declared in this order, the compiler mistakenly constructs the following graph:
```
Tr1
/ \
I3 I2
|
I1
```
This patch fixes the reattach procedure to include all specializing grandchildren-to-be.
Fixes#50452.
std: Synchronize access to global env during `exec`
This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix#46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
* First, the global environment is reset during `exec` but, but if the
`exec` call fails then the global environment was a dangling pointer
into free'd memory as the block of memory was deallocated when
`Command` is dropped. This is fixed in this commit by installing a
`Drop` stack object which ensures that the `environ` pointer is
preserved on a failing `exec`.
* Second, the global environment was accessed in an unsynchronized
fashion during `exec`. This was fixed by ensuring that the
Rust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Closes#55775
This commit, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix#46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
* First, the global environment is reset during `exec` but, but if the
`exec` call fails then the global environment was a dangling pointer
into free'd memory as the block of memory was deallocated when
`Command` is dropped. This is fixed in this commit by installing a
`Drop` stack object which ensures that the `environ` pointer is
preserved on a failing `exec`.
* Second, the global environment was accessed in an unsynchronized
fashion during `exec`. This was fixed by ensuring that the
Rust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Closes#55775
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
xLTO: Don't pass --plugin-opt=thin to LLD. That's not supported anymore.
It seems that `-plugin-opt=thin` is not needed anymore when invoking LLD for ThinLTO. Unfortunately, still passing the option makes LLD crash instead of giving a deprecation warning or something.
Check for negative impls when finding auto traits
Fixes#55321
When AutoTraitFinder begins examining a type, it checks for an explicit
negative impl. However, it wasn't checking for negative impls found when
calling 'select' on predicates found from nested obligations.
This commit makes AutoTraitFinder check for negative impls whenever it
makes a call to 'select'. If a negative impl is found, it immediately
bails out.
Normal users of SelectioContext don't need to worry about this, since
they stop as soon as an Unimplemented error is encountered. However, we
add predicates to our ParamEnv when we encounter this error, so we need
to handle negative impls specially (so that we don't try adding them to
our ParamEnv).
impl_stable_hash_for: support enums and tuple structs with generic parameters
Port a bunch of implementations over to the macro, now that that is possible.
Document optimizations enabled by FusedIterator
When reading this I wondered what “some significant optimizations” referred to. As far as I can tell from reading code, the specialization of `.fuse()` is the only case where `FusedIterator` has any impact at all. Is this accurate @Stebalien?
global allocators: add a few comments
These comments answer some questions that came up when I tried to understand how the control flow works for the global allocator, `Global` and `System`.
r? @alexcrichton
Reference count `crate_inherent_impls`s return value.
The repeated cloning of the result in `inherent_impls` queries has quite
an impact on crates with many inherent trait implementations.
For instance on https://github.com/jmesmon/stm32f429, `cargo check` went from 75 seconds to 38 seconds on my machine.
string: Add documentation for `From` impls
Hi this is part of #51430. I'm a first time contributor, so I started with a small task adding a bit of documentation for From impls.
Fix TLS errors when downloading stage0
While attempting to test #49878 on Windows I hit the following error when attempting to download stage0.
```
The request was aborted: Could not create SSL/TLS secure channel
```
Instead of using the shell, we can just use `urllib`, which seems to fix the issue.
Make PhantomData #[structural_match]
fixes https://github.com/rust-lang/rust/issues/55028
This makes `PhantomData<T>` structurally matchable, irrespective of whether `T` is, per the discussion on this week's language team meeting (the general consensus was that this was a bug-fix).
All types containing `PhantomData<T>` and which used `#[derive(PartialEq, Eq)]` and were previously not `#[structural_match]` only because of `PhantomData<T>` will now be `#[structural_match]`.
r? @nikomatsakis
rustdoc: don't inline `pub use some_crate` unless directly asked to
cc https://github.com/rust-lang/rust/issues/52509 (fixes it? i'm not sure about my comment summoning the docs team)
When rustdoc encounters a `pub use` statement for an item from another crate, it will eagerly inline its contents into your crate. This somewhat clashes with the new paths behavior in Rust 2018, in which crates are implicitly linked and re-exported with `pub use` instead of `pub extern crate`. In rust 2015, `pub extern crate` would only create a single line for its re-export in the docs, so i'm making it do the same with `pub use some_crate;`.
The exact new behavior is like this: *If rustdoc sees a `pub use` statement, and the item being imported is the root of another crate, it will only inline it if `#[doc(inline)]` is provided.* I made it only avoid crate roots because otherwise it would stop inlining any module, which may or may not be what people want.
Use read_unaligned instead of read in transmute_copy
Closes: #55044
This change could result in performance regression on non-x86 platforms. (but it also can fix some of UB which lurks in existing programs) An alternative would be to update `transmute_copy` documentation with alignment requirements.
