| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
Simplify span caches
Split from https://github.com/rust-lang/rust/pull/143882
r? `@petrochenkov`
|
|
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)`.
|
|
actually provide the correct args to coroutine witnesses
rust-lang/rust#145194 accidentally provided all arguments of the closure to the witness, but the witness only takes the generic parameters of the defining scope: https://github.com/rust-lang/rust/blob/216cdb7b22b637cef75b7225c642cb7587192643/compiler/rustc_hir_typeck/src/closure.rs#L164
Fixes rust-lang/rust#145288
|
|
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.
|
|
Port `#[custom_mir(..)]` to the new attribute system
r? ``````````@jdonszelmann``````````
|
|
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.
Fixes rust-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`
|
|
|
|
|
|
|
|
|
|
Rollup of 21 pull requests
Successful merges:
- rust-lang/rust#118087 (Add Ref/RefMut try_map method)
- rust-lang/rust#122661 (Change the desugaring of `assert!` for better error output)
- rust-lang/rust#142640 (Implement autodiff using intrinsics)
- rust-lang/rust#143075 (compiler: Allow `extern "interrupt" fn() -> !`)
- rust-lang/rust#144865 (Fix tail calls to `#[track_caller]` functions)
- rust-lang/rust#144944 (E0793: Clarify that it applies to unions as well)
- rust-lang/rust#144947 (Fix description of unsigned `checked_exact_div`)
- rust-lang/rust#145004 (Couple of minor cleanups)
- rust-lang/rust#145005 (strip prefix of temporary file names when it exceeds filesystem name length limit)
- rust-lang/rust#145012 (Tail call diagnostics to include lifetime info)
- rust-lang/rust#145065 (resolve: Introduce `RibKind::Block`)
- rust-lang/rust#145120 (llvm: Accept new LLVM lifetime format)
- rust-lang/rust#145189 (Weekly `cargo update`)
- rust-lang/rust#145235 (Minor `[const]` tweaks)
- rust-lang/rust#145275 (fix(compiler/rustc_codegen_llvm): apply `target-cpu` attribute)
- rust-lang/rust#145322 (Resolve the prelude import in `build_reduced_graph`)
- rust-lang/rust#145331 (Make std use the edition 2024 prelude)
- rust-lang/rust#145369 (Do not ICE on private type in field of unresolved struct)
- rust-lang/rust#145378 (Add `FnContext` in parser for diagnostic)
- rust-lang/rust#145389 ([rustdoc] Revert "rustdoc search: prefer stable items in search results")
- rust-lang/rust#145392 (coverage: Remove intermediate data structures from mapping creation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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.
|
|
Port the `#[linkage]` attribute to the new attribute system
r? `@jdonszelmann`
|
|
Reduce some queries around associated items
|
|
Co-authored-by: Boxy <rust@boxyuwu.dev>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
More `Printer` cleanups
A sequel to rust-lang/rust#144776.
r? ```@davidtwco```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When trying to construct a struct that has a public field of a private type, suggest using `..` if that field has a default value.
```
error[E0603]: struct `Priv1` is private
--> $DIR/non-exhaustive-ctor.rs:25:39
|
LL | let _ = S { field: (), field1: m::Priv1 {} };
| ------ ^^^^^ private struct
| |
| while setting this field
|
note: the struct `Priv1` is defined here
--> $DIR/non-exhaustive-ctor.rs:14:4
|
LL | struct Priv1 {}
| ^^^^^^^^^^^^
help: the field `field1` you're trying to set has a default value, you can use `..` to use it
|
LL | let _ = S { field: (), .. };
| ~~
```
|
|
rename `TraitRef::from_method` to `from_assoc`
also add a note to `GenericArgs::truncate_to`
|
|
Rollup of 23 pull requests
Successful merges:
- rust-lang/rust#141658 (rustdoc search: prefer stable items in search results)
- rust-lang/rust#141828 (Add diagnostic explaining STATUS_STACK_BUFFER_OVERRUN not only being used for stack buffer overruns if link.exe exits with that exit code)
- rust-lang/rust#144823 (coverage: Extract HIR-related helper code out of the main module)
- rust-lang/rust#144883 (Remove unneeded `drop_in_place` calls)
- rust-lang/rust#144923 (Move several more float tests to floats/mod.rs)
- rust-lang/rust#144988 (Add annotations to the graphviz region graph on region origins)
- rust-lang/rust#145010 (Couple of minor abi handling cleanups)
- rust-lang/rust#145017 (Explicitly disable vector feature on s390x baseline of bad-reg test)
- rust-lang/rust#145027 (Optimize `char::is_alphanumeric`)
- rust-lang/rust#145050 (add member constraints tests)
- rust-lang/rust#145073 (update enzyme submodule to handle llvm 21)
- rust-lang/rust#145080 (Escape diff strings in MIR dataflow graphviz)
- rust-lang/rust#145082 (Fix some bad formatting in `-Zmacro-stats` output.)
- rust-lang/rust#145083 (Fix cross-compilation of Cargo)
- rust-lang/rust#145096 (Fix wasm target build with atomics feature)
- rust-lang/rust#145097 (remove unnecessary `TypeFoldable` impls)
- rust-lang/rust#145100 (Rank doc aliases lower than equivalently matched items)
- rust-lang/rust#145103 (rustc_metadata: remove unused private trait impls)
- rust-lang/rust#145115 (defer opaque type errors, generally greatly reduce tainting)
- rust-lang/rust#145119 (rustc_public: fix missing parenthesis in pretty discriminant)
- rust-lang/rust#145124 (Recover `for PAT = EXPR {}`)
- rust-lang/rust#145132 (Refactor map_unit_fn lint)
- rust-lang/rust#145134 (Reduce indirect assoc parent queries)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
also add a note to `GenericArgs::truncate_to`
|
|
remove unnecessary `TypeFoldable` impls
|
|
add a scope for `if let` guard temporaries and bindings
This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (https://github.com/rust-lang/rust/pull/141295#issuecomment-2968975596). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings.
This only introduces a new scope for match arms with guards. Perf results (https://github.com/rust-lang/rust/pull/143376#issuecomment-3034922617) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (rust-lang/rust#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes).
Tracking issue for `if_let_guard`: rust-lang/rust#51114
Tests are adapted from examples by `@traviscross,` `@est31,` and myself on rust-lang/rust#141295.
|
|
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
|
|
Use `tcx.short_string()` in more diagnostics
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
|
|
|
|
A couple small changes for rust-analyzer next-solver work
Originally written by `@flodiebold`
|
|
coverage: Remove all unstable support for MC/DC instrumentation
Preliminary support for a partial implementation of “Modified Condition/Decision Coverage” instrumentation was added behind the unstable flag `-Zcoverage-options=mcdc` in 2024. These are the most substantial PRs involved:
- rust-lang/rust#123409
- rust-lang/rust#126733
At the time, I accepted these PRs with relatively modest scrutiny, because I did not want to stand in the way of independent work on MC/DC instrumentation. My hope was that ongoing work by interested contributors would lead to the code becoming clearer and more maintainable over time.
---
However, that MC/DC code has proven itself to be a major burden on overall maintenance of coverage instrumentation, and a major obstacle to other planned improvements, such as internal changes needed for proper support of macro expansion regions.
I have also become reluctant to accept any further MC/DC-related changes that would increase this burden.
That tension has resulted in an unhappy impasse. On one hand, the present MC/DC implementation is not yet complete, and shows little sign of being complete at an acceptable level of code quality in the foreseeable future. On the other hand, the continued existence of this partial MC/DC implementation is imposing serious maintenance burdens on every other aspect of coverage instrumentation, and is preventing some of the very improvements that would make it easier to accept expanded MC/DC support in the future.
While I know this will be disappointing to some, I think the healthy way forward is accept that I made the wrong call in accepting the current implementation, and to remove it entirely from the compiler.
|
|
Add support for `ty::Instance` path shortening in diagnostics
Make `ty::Instance` able to use `short_string` and usable in structured errors directly. Remove some ad-hoc type shortening logic.
|
