This re-introduces a `Config.libdir_relative` field, now derived from
`libdir` and made relative to `prefix` if necessary.
This fixes a regression from #46592 when `--libdir` is given an absolute
path. `Builder::sysroot_libdir` should always use a relative path so
its callers don't clobber system locations, and `librustc` also asserts
that `CFG_LIBDIR_RELATIVE` is really relative.
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
RFC 2070 part 1: PanicInfo and Location API changes
This implements part of https://rust-lang.github.io/rfcs/2070-panic-implementation.html
Tracking issue: https://github.com/rust-lang/rust/issues/44489
* Move `std::panic::PanicInfo` and `std::panic::Location` to a new `core::panic` module. The two types and the `std` module were already `#[stable]` and stay that way, the new `core` module is `#[unstable]`.
* Add a new `PanicInfo::message(&self) -> Option<&fmt::Arguments>` method, which is `#[unstable]`.
* Implement `Display` for `PanicInfo` and `Location`
Don't promote to 'static the result of dereferences.
This is a **breaking change**, removing copies out of dereferences from rvalue-to-`'static` promotion.
With miri we won't easily know whether the dereference itself would see the same value at runtime as miri (e.g. after mutating a `static`) or even if it can be interpreted (e.g. integer pointers).
One alternative to this ban is defining at least *some* of those situations as UB, i.e. you shouldn't have a reference in the first place, and you should work through raw pointers instead, to avoid promotion.
**EDIT**: The other *may seem* to be to add some analysis which whitelists references-to-constant-values and assume any values produced by arbitrary computation to not be safe to promote dereferences thereof - but that means producing a reference from an associated constant or `const fn` would necessarily obscure it, and in the former case, this could still impact code that runs on stable today. What we do today to track "references to statics" only works because we restrict taking a reference to a `static` at all to other `static`s (which, again, are currently limited in that they can't be read at compile-time) and to runtime-only `fn`s (*not* `const fn`s).
I'm primarily opening this PR with a conservative first approximation (e.g. `&(*r).a` is not allowed, only reborrows are, and in the old borrow only implicit ones from adjustments, at that) for cratering.
r? @nikomatsakis
