Fix early param lifetimes in generic_const_exprs
In cases like below, we never actually be able to capture region name for two reasons, first `'static` becomes anonymous lifetime and second we never capture region if it doesn't have a name so this results in ICE.
```
struct DataWrapper<'static> {
data: &'a [u8; Self::SIZE],
}
impl DataWrapper<'a> {
```
Fixes https://github.com/rust-lang/rust/issues/118021
Expand Miri's BorTag GC to a Provenance GC
As suggested in https://github.com/rust-lang/miri/issues/3080#issuecomment-1732505573
We previously solved memory growth issues associated with the Stacked Borrows and Tree Borrows runtimes with a GC. But of course we also have state accumulation associated with whole allocations elsewhere in the interpreter, and this PR starts tackling those.
To do this, we expand the visitor for the GC so that it can visit a BorTag or an AllocId. Instead of collecting all live AllocIds into a single HashSet, we just collect from the Machine itself then go through an accessor `InterpCx::is_alloc_live` which checks a number of allocation data structures in the core interpreter. This avoids the overhead of all the inserts that collecting their keys would require.
r? ``@RalfJung``
Remove `--check-cfg` checking of command line `--cfg` args
Back in https://github.com/rust-lang/rust/pull/100574 we added to the `unexpected_cfgs` lint the checking of `--cfg` CLI arguments and emitted unexpected names and values for them.
The implementation works as expected, but it's usability in particular when using it in combination with Cargo+`RUSTFLAGS` as people who set `RUSTFLAGS=--cfg=tokio_unstable` (or whatever) have `unexpected_cfgs` warnings on all of their crates is debatable. ~~To fix this issue this PR proposes that we split the CLI argument checking into it's own separate allow-by-default lint: `unexpected_cli_cfgs`.~~
~~This has the advantage of letting people who want CLI warnings have them (although not by default anymore), while still linting on every unexpected cfg name and values in the code.~~
After some discussion with the Cargo team ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/check-cfg.20and.20RUSTFLAGS.20interaction)) and member of the compiler team (see below), I propose that we follow the suggestion from `@epage:` never check `--cfg` arguments, but still reserve us the possibility to do it later.
We would still lint on unexpected cfgs found in the source code no matter the `--cfg` args passed. This mean reverting https://github.com/rust-lang/rust/pull/100574 but NOT https://github.com/rust-lang/rust/pull/99519.
r? `@petrochenkov`
Add `HashStable_NoContext` to simplify `HashStable` implementations in `rustc_type_ir`
adds `derive(HashStable_NoContext)` which is a derived `HashStable` implementation that has no `HashStableContext` bound, and which adds `where` bounds for `HashStable` based off of *fields* and not generics.
This means we can `derive(HashStable_NoContext)` in more places in `rustc_type_ir` rather than having to hand-roll implementations.
Add `$message_type` field to distinguish json diagnostic outputs
Currently the json-formatted outputs have no way to unambiguously determine which kind of message is being output. A consumer can look for specific fields in the json object (eg "message"), but there's no guarantee that in future some other kind of output will have a field of the same name.
This PR adds a `"type"` field to add json outputs which can be used to unambiguously determine which kind of output it is. The mapping is:
`diagnostic`: regular compiler diagnostics
`artifact`: artifact notifications
`future_incompat`: Future incompatibility report
`unused_extern`: Unused crate warnings/errors
This matches the "internally tagged" representation for serde enums.
Add place.ty() and Ty build from a kind to smir
Add a method to retrieve the type of a place and a few utility functions needed to build the projection type. I decided to return a result to avoid panicking if the user passes invalid inputs, such as wrong list of locals.
r? `@spastorino`
Rollup of 8 pull requests
Successful merges:
- #117327 (Add documentation for some queries)
- #117835 (Note about object lifetime defaults in does not live long enough error)
- #117851 (Uplift `InferConst` to `rustc_type_ir`)
- #117973 (test: Add test for async-move in 2015 Rust proc macro)
- #117992 (Don't require intercrate mode for negative coherence)
- #118010 (Typeck break expr even if break is illegal)
- #118026 (Don't consider regions in `deref_into_dyn_supertrait` lint)
- #118089 (intercrate_ambiguity_causes: handle self ty infer + reservation impls)
r? `@ghost`
`@rustbot` modify labels: rollup
When we encounter a function with a return type that has an anonymous
lifetime with no argument to borrow from, besides suggesting the
`'static` lifetime we now also suggest changing the arguments to be
borrows or changing the return type to be an owned type.
```
error[E0106]: missing lifetime specifier
--> $DIR/variadic-ffi-6.rs:7:6
|
LL | ) -> &usize {
| ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
|
LL | ) -> &'static usize {
| +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
|
LL | x: &usize,
| +
help: ...or alternatively, to want to return an owned value
|
LL - ) -> &usize {
LL + ) -> usize {
|
```
Fix#85843.
