Rollup of 8 pull requests
Successful merges:
- #66183 (*Syntactically* permit visibilities on trait items & enum variants)
- #66566 (Document pitfall with `impl PartialEq<B> for A`)
- #66575 (Remove pretty printing of specific nodes in AST)
- #66587 (Handle statics in MIR as const pointers)
- #66619 (follow the convention in this file to use third-person singular verbs)
- #66633 (Error code's long explanation cleanup)
- #66637 (fix reoccuring typo: dereferencable -> dereferenceable)
- #66639 (resolve: more declarative `fresh_binding`)
Failed merges:
r? @ghost
The previous strategy of removing `Drop` and `StorageDead` for promoted
locals only worked for rvalue lifetime extension. We now use the same
implementation for promotion across all kinds of items.
The previous test was incorrect. `const fn`s are *always* promotable
when inside a `const`, so it should pass. The error was caused by a bug
in `promote_consts`. I've added a failing test outside a `const`
alongside the existing one, which is now run-pass.
resolve: more declarative `fresh_binding`
Following up on https://github.com/rust-lang/rust/pull/64111, this PR redefines `fresh_binding` wrt. `already_bound_and` and `already_bound_or` in a more declarative and simplified fashion.
cc #54883
r? @petrochenkov
Handle statics in MIR as const pointers
This is the first PR towards the goal of removing `PlaceBase::Static`. In this PR:
* Statics are lowered to dereferencing a const pointer.
* The temporaries holding such pointers are tracked in MIR, for the most part this is only used for diagnostics. There are two exceptions:
* The borrow checker has some checks for thread-locals that directly use this data.
* Const checking will suppress "cannot dereference raw pointer" diagnostics for pointers to `static mut`/`extern static`. This is to maintain the current behaviour (12 tests fail otherwise).
The following are left to future PRs (I think that @spastorino will be working on the first 3):
* Applying the same treatments to promoted statics.
* Removing `PlaceBase::Static`.
* Replacing `PlaceBase` with `Local`.
* Moving the ever growing collection of metadata that we have for diagnostics in MIR passes somewhere more appropriate.
r? @oli-obk
Remove pretty printing of specific nodes in AST
The ability to print a specific item as identified by NodeId or path
seems not particularly useful, and certainly carries quite a bit of
complexity with it.
This is intended to simplify our CLI parsing a bit and remove a
non-uncomplicated piece of it; I largely did this to remove the
dependency on NodeId from librustc/session but it's not really
necessary to do so in this invasive a way. The alternative is
moving it to librustc_interface or driver, probably.
*Syntactically* permit visibilities on trait items & enum variants
Fixes#65041
Suppose we have `$vis trait_item` or `$vis enum_variant` and `$vis` is a `:vis` macro fragment. Before this PR, this would fail to parse. This is now instead allowed as per language team consensus in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286. (See added tests for elaboration.)
Moreover, we now also permit visibility modifiers on trait items & enum variants *syntactically* but reject them with semantic checks (in `ast_validation`):
```rust
#[cfg(FALSE)]
trait Foo { pub fn bar(); } // OK
#[cfg(FALSE)]
enum E { pub U } // OK
```
Some environment variables (like DEPLOY or DEPLOY_ALT for dist builders,
or IMAGE on Linux builders) are set on a lot of builders, and whether
they should be present or not can be detected automatically based on the
builder name and the platform.
This commit simplifies the CI configuration by automatically setting
those environment variables.
Add a proc-macro to derive HashStable in librustc dependencies
A second proc-macro is added to derive HashStable for crates librustc depends on.
This proc-macro HashStable_Generic (to bikeshed) allows to decouple code and some librustc's boilerplate.
Not everything is migrated, because `Span` and `TokenKind` require to be placed inside librustc.
Types using them stay there too.
Split out of #66279
r? @Zoxc
