Switch next solver to use a specific associated type for trait def id
The compiler just puts `DefId` in there, but rust-analyzer uses different types for each kind of item.
See [the Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Implmentating.20New.20Trait.20Solver/near/534329794). In short, it will be a tremendous help to r-a to use specific associated types, while for the solver and the compiler it's a small change. So I ported `TraitId`, as a proof of concept and it's also likely the most impactful.
r? types
Region inference: Use outlives-static constraints in constraint search
Revise the extra `r: 'static` constraints added upon universe issues to add an explanation, and use that explanation during constraint blame search. This greatly simplifies the region inference logic, which now does not need to reverse-engineer the event that caused a region to outlive `'static`.
This cosmetically changes the output of two UI tests. I blessed them i separate commits with separate motivations, but that can of course be squashed as desired. We probably want that.
The PR was extracted out of rust-lang/rust#130227 and consists of one-third of its functional payload.
r? lcnr
Support non-defining uses in HIR typeck
This changes the impl of `NormalizesTo` for opaque types to be structural during HIR typeck. The previous impl equated region variables of the opaque type key with existing entries which can result in spurious leak check errors and also results in mismatches with MIR borrowck, theoretically causing ICE.
The approach is very similar to rust-lang/rust#145244 in MIR typeck:
- we collect all uses of opaque types during HIR typeck
- before writeback, we search for *defining uses*
- the opaque type key has fully universal generic args modulo regions
- the hidden type has no infer vars
- we use these defining uses to compute the concrete type for the opaque and map it to the definition site
- we use this concrete type to check the type of all uses of opaques during HIR typeck. This also constrains infer vars in non-defining uses
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/135, fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/49.
r? `@BoxyUwU`
interpret/allocation: get_range on ProvenanceMap
Helper method to grab all provenances in a given address range for an allocation, making some logic in Miri nicer.
change HIR typeck region uniquification handling approach
rust-lang/rust#144405 causes structural lookup of opaque types to not work during HIR typeck, so instead avoid uniquifying goals and instead only reprove them if MIR borrowck actually encounters an error.
This doesn't perfectly maintain the property that HIR typeck succeeding implies that MIR typeck succeeds, instead weakening this check to only guarantee that HIR typeck implies that MIR typeck succeeds modulo region uniquification. This means we still get the actually desirable ICEs if we MIR building is broken or we forget to check some property in HIR typeck, without having to deal with the fallout of uniquification in HIR typeck itself.
We report errors using the original obligation sources of HIR typeck so diagnostics aren't that negatively impacted either.
Here's the history of region uniquification while working on the new trait solver:
- rust-lang/rust#107981
- rust-lang/rust#110180
- rust-lang/rust#114117
- rust-lang/rust#130821
- rust-lang/rust#144405
- rust-lang/rust#145706 <- we're here 🎉
r? `@BoxyUwU`
Refactor lint buffering to avoid requiring a giant enum
Lint buffering currently relies on a giant enum `BuiltinLintDiag` containing all the lints that might potentially get buffered. In addition to being an unwieldy enum in a central crate, this also makes `rustc_lint_defs` a build bottleneck: it depends on various types from various crates (with a steady pressure to add more), and many crates depend on it.
Having all of these variants in a separate crate also prevents detecting when a variant becomes unused, which we can do with a dedicated type defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types directly.
Because the existing `BuiltinLintDiag` requires some additional types in order to decorate some variants, which are only available later in `rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn LintDiagnostic` case and the `BuiltinLintDiag` case.
---
With the infrastructure in place, use it to migrate three of the enum variants to use `LintDiagnostic` directly, as a proof of concept and to demonstrate that the net result is a reduction in code size and a removal of a boilerplate-heavy layer of indirection.
Also remove an unused `BuiltinLintDiag` variant.
Revise the extra `r: 'static` constraints added upon universe issues
to add an explanation, and use that explanation during constraint blame
search. This greatly simplifies the region inference logic, which
now does not need to reverse-engineer the event that caused a region
to outlive 'static.
Lint buffering currently relies on a giant enum `BuiltinLintDiag`
containing all the lints that might potentially get buffered. In
addition to being an unwieldy enum in a central crate, this also makes
`rustc_lint_defs` a build bottleneck: it depends on various types from
various crates (with a steady pressure to add more), and many crates
depend on it.
Having all of these variants in a separate crate also prevents detecting
when a variant becomes unused, which we can do with a dedicated type
defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types
directly.
This requires boxing, but all of this is already on the slow path
(emitting an error).
Because the existing `BuiltinLintDiag` requires some additional types in
order to decorate some variants, which are only available later in
`rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn
LintDiagnostic` case and the `BuiltinLintDiag` case.
Unconditionally-const supertraits are considered not dyn compatible
Let's save some space in the design of const traits by making `dyn Trait` where `trait Trait: const Super` not dyn compatible.
Such a trait cannot satisfy `dyn Trait: Trait`; we could in the future make this dyn compatible but *NOT* implement `Trait`, but that's a bit weird and seems like it needs to be independently justified moving forward.
Fixes https://github.com/rust-lang/rust/issues/145198
r? fee1-dead
`rustc_errors` depends on numerous crates, solely to implement its
`IntoDiagArg` trait on types from those crates. Many crates depend on
`rustc_errors`, and it's on the critical path.
We can't swap things around to make all of those crates depend on
`rustc_errors` instead, because `rustc_errors` would end up in
dependency cycles.
Instead, move `IntoDiagArg` into `rustc_error_messages`, which has far
fewer dependencies, and then have most of these crates depend on
`rustc_error_messages`.
This allows `rustc_errors` to drop dependencies on several crates,
including the large `rustc_target`.
(This doesn't fully reduce dependency chains yet, as `rustc_errors`
still depends on `rustc_hir` which depends on `rustc_target`. That will
get fixed in a subsequent commit.)
Pretty print the name of an future from calling async closure
Fixes https://github.com/rust-lang/rust/issues/145606 by introducing a way to customize the path rendering of async closures' futures in the pretty printer API.
mention lint group in default level lint note
### Summary
This PR updates lint diagnostics so that default-level notes now mention the lint group they belong to, if any.
Fixes: rust-lang/rust#65464.
### Example
```rust
fn main() {
let x = 5;
}
```
Before:
```
= note: `#[warn(unused_variables)]` on by default
```
After:
```
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
```
### Unchanged Cases
Messages remain the same when the lint level is explicitly set, e.g.:
* Attribute on the lint `#[warn(unused_variables)]`:
```
note: the lint level is defined here
LL | #[warn(unused_variables)]
| ^^^^^^^^^^^^^^^^
```
* Attribute on the group `#[warn(unused)]:`:
```
= note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
```
* CLI option `-W unused`:
```
= note: `-W unused-variables` implied by `-W unused`
= help: to override `-W unused` add `#[allow(unused_variables)]`
```
* CLI option `-W unused-variables`:
```
= note: requested on the command line with `-W unused-variables`
```
Visit and print async_fut local for async drop.
This is a bugfix for a MIR local we forget to visit.
I had a lot of trouble reading the docs for `async_fut`, so I'm not certain about the change to the pretty-printer.
Couple of codegen_fn_attrs improvements
As noted in https://github.com/rust-lang/rust/pull/144678#discussion_r2245060329 here is no need to keep link_name and export_name separate, which the third commit fixes by merging them. The second commit removes some dead code and the first commit merges two ifs with equivalent conditions. The last commit is an unrelated change which removes an unused `feature(autodiff)`.
Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`
This came up during the sanitizer stabilization (rust-lang/rust#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)).
The new attribute also works on modules, traits and impl items and thus enables usage as the following:
```rust
#[sanitize(address = "off")]
mod foo {
fn unsanitized(..) {}
#[sanitize(address = "on")]
fn sanitized(..) {}
}
trait MyTrait {
#[sanitize(address = "off")]
fn unsanitized_default(..) {}
}
#[sanitize(thread = "off")]
impl MyTrait for () {
...
}
```
r? ```@rcvalle```
This removes the #[no_sanitize] attribute, which was behind an unstable
feature named no_sanitize. Instead, we introduce the sanitize attribute
which is more powerful and allows to be extended in the future (instead
of just focusing on turning sanitizers off).
This also makes sanitize(kernel_address = ..) attribute work with
-Zsanitize=address
To do it the same as how clang disables address sanitizer, we now
disable ASAN on sanitize(kernel_address = "off") and KASAN on
sanitize(address = "off").
The same was added to clang in https://reviews.llvm.org/D44981.
This change implements the #[sanitize(..)] attribute, which opts to
replace the currently unstable #[no_sanitize]. Essentially the new
attribute works similar as #[no_sanitize], just with more flexible
options regarding where it is applied. E.g. it is possible to turn
a certain sanitizer either on or off:
`#[sanitize(address = "on|off")]`
This attribute now also applies to more places, e.g. it is possible
to turn off a sanitizer for an entire module or impl block:
```rust
\#[sanitize(address = "off")]
mod foo {
fn unsanitized(..) {}
#[sanitize(address = "on")]
fn sanitized(..) {}
}
\#[sanitize(thread = "off")]
impl MyTrait for () {
...
}
```
This attribute is enabled behind the unstable `sanitize` feature.
