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.
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.
Print regions in `type_name`.
Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions.
Fixesrust-lang/rust#145168.
r? `@lcnr`
const-eval: full support for pointer fragments
This fixes https://github.com/rust-lang/const-eval/issues/72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in https://github.com/rust-lang/rust/pull/137280.
For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics:
```rust
use std::{mem::{self, MaybeUninit}, ptr};
type Byte = MaybeUninit<u8>;
const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) {
let mut i = 0;
while i < n {
*dst.add(i) = *src.add(i);
i += 1;
}
}
const _MEMCPY: () = unsafe {
let ptr = &42;
let mut ptr2 = ptr::null::<i32>();
// Copy from ptr to ptr2.
memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>());
assert!(*ptr2 == 42);
};
```
What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again.
We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^
This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to https://github.com/rust-lang/unsafe-code-guidelines/issues/558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
Patterns: represent constants as valtrees
Const patterns are always valtrees now. Let's represent that in the types. We use `ty::Value` for this since it nicely packages value and type, and has some convenient methods.
Cc `@Nadrieril` `@BoxyUwU`
Currently they are skipped, which is a bit weird, and it sometimes
causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all
regions are now printed as `'_` in non-optional places. Not perfect, but
better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the
`PASS_NAMES` sanity check still works. It is also renamed as
`simplify_pass_type_name` and made non-const, because it doesn't need
to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as
`should_print_optional_region`, which makes it clearer that it only
applies to some regions.
Fixes#145168.
