| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Improve recovery when users write `where:`
Improve recovery of `where:`.
Fixes https://github.com/rust-lang/rust/issues/143023
The erroneous suggestion was because we were seeing `:` then a type, which the original impl thought must be a struct field. Make this a bit more accurate by checking for a non-reserved ident (which should be a field name).
Also, make a custom parser error for `where:` so we can continue parsing after the colon.
|
|
Port `#[used]` to new attribute parsing infrastructure
Ports `used` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
r? ``@jdonszelmann``
|
|
add #![rustc_no_implicit_bounds]
Follow-up from rust-lang/rust#137944.
Adds a new `rustc_attrs` attribute that stops rustc from adding any default bounds. Useful for tests where default bounds just add noise and make debugging harder.
After reviewing all tests with `?Sized`, these tests seem like they could probably benefit from `#![rustc_no_implicit_bounds]`.
- Skipping most of `tests/ui/unsized` as these seem to want to test `?Sized`
- Skipping tests that used `Box<T>` because it's still bound by `T: MetaSized`
- Skipping parsing or other tests that cared about `?Sized` syntactically
- Skipping tests for `derive(CoercePointee)` because this appears to check that the pointee type is relaxed with `?Sized` explicitly
r? `@lcnr`
|
|
|
|
Similar to the existing nullpointer and alignment checks, this checks
for valid enum discriminants on creation of enums through unsafe
transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly
sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid
construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for
keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
|
|
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
|
|
parsing infrastructure
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
After reviewing all tests with `?Sized` and discussing with lcnr, these
tests seem like they could probably benefit from
`#![rustc_no_implicit_bounds]`.
|
|
|
|
Rollup of 18 pull requests
Successful merges:
- rust-lang/rust#137843 (make RefCell unstably const)
- rust-lang/rust#140942 (const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns)
- rust-lang/rust#142549 (small iter.intersperse.fold() optimization)
- rust-lang/rust#142637 (Remove some glob imports from the type system)
- rust-lang/rust#142647 ([perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation)
- rust-lang/rust#142700 (Remove incorrect comments in `Weak`)
- rust-lang/rust#142927 (Add note to `find_const_ty_from_env`)
- rust-lang/rust#142967 (Fix RwLock::try_write documentation for WouldBlock condition)
- rust-lang/rust#142986 (Port `#[export_name]` to the new attribute parsing infrastructure)
- rust-lang/rust#143001 (Rename run always )
- rust-lang/rust#143010 (Update `browser-ui-test` version to `0.20.7`)
- rust-lang/rust#143015 (Add `sym::macro_pin` diagnostic item for `core::pin::pin!()`)
- rust-lang/rust#143033 (Expand const-stabilized API links in relnotes)
- rust-lang/rust#143041 (Remove cache for citool)
- rust-lang/rust#143056 (Move an ACE test out of the GCI directory)
- rust-lang/rust#143059 (Fix 1.88 relnotes)
- rust-lang/rust#143067 (Tracking issue number for `iter_macro`)
- rust-lang/rust#143073 (Fix some fixmes that were waiting for let chains)
Failed merges:
- rust-lang/rust#143020 (codegen_fn_attrs: make comment more precise)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Move an ACE test out of the GCI directory
In https://github.com/rust-lang/rust/pull/122988, a test pertaining to `associated_const_equality` was placed into the directory meant for `generic_const_items`. Let's move it where it belongs.
While at it, I took the time to further minimize the test and to add a description. You can use 1.67.1 (as reported in rust-lang/rust#108220) to verify that I didn't butcher it. For additional context, the issue was likely fixed in rust-lang/rust#112718 (but I'm also cc'ing rust-lang/rust#140467 which further fixed things up and has more context).
I only performed quick and dirty git/GitHub archeology, so I don't have the full picture here. For one, I'm not even sure if this regression test is worth it.
Anyway, I just want it gone from the GCI dir :)
|
|
Port `#[export_name]` to the new attribute parsing infrastructure
This PR contains two changes, in separate commits for reviewability:
- Ports `export_name` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
- Moves the check for mixing export_name/no_mangle to check_attr.rs and improve the error message, which previously had a mix of 2021/2024 edition syntax
r? ``@jdonszelmann``
|
|
const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns
This fixes https://github.com/rust-lang/rust/issues/140653 by accepting code such as this:
```rust
static FOO: AtomicU32 = AtomicU32::new(0);
const C: &'static AtomicU32 = &FOO;
```
This can be written entirely in safe code, so there can't really be anything wrong with it.
We also accept the much more questionable following code, since it looks very similar to the interpreter:
```rust
static mut FOO2: u32 = 0;
const C2: &'static u32 = unsafe { &mut FOO2 };
```
Using this without causing UB is at least very hard (the details are unclear since it is related to how the aliasing model deals with the staging of const-eval vs runtime code).
If a constant like `C2` is used as a pattern, we emit an error:
```
error: constant BAD_PATTERN cannot be used as pattern
--> $DIR/const_refs_to_static_fail.rs:30:9
|
LL | BAD_PATTERN => {},
| ^^^^^^^^^^^
|
= note: constants that reference mutable or external memory cannot be used as pattern
```
(If you somehow manage to build a pattern with constant `C`, you'd get the same error, but that should be impossible: we don't have a type that can be used in patterns and that has interior mutability.)
The same treatment is afforded for shared references to `extern static`, for the same reason: the const evaluation is entirely fine with it, we just can't build a pattern for it -- and when using interior mutability, this can be totally sound.
We do still not accept anything where there is an `&mut` in the final value of the const, as that should always require unsafe code and it's hard to imagine a sound use-case that would require this.
|
|
The `macro_rules!` parser was written to match the series of rules using
the macros-by-example (MBE) engine and a hand-written equivalent of the
left-hand side of a MBE macro. This was complex to read, difficult to
extend, and produced confusing error messages. Because it was using the
MBE engine, any parse failure would be reported as if some macro was
being applied to the `macro_rules!` invocation itself; for instance,
errors would talk about "macro invocation", "macro arguments", and
"macro call", when they were actually about the macro *definition*.
And in practice, the `macro_rules!` parser only used the MBE engine to
extract the left-hand side and right-hand side of each rule as a token
tree, and then parsed the rest using a separate parser.
Rewrite it to parse the series of rules using a simple loop, instead.
This makes it more extensible in the future, and improves error
messages. For instance, omitting a semicolon between rules will result
in "expected `;`" and "unexpected token", rather than the confusing "no
rules expected this token in macro call".
This work was greatly aided by pair programming with Vincenzo Palazzo
and Eric Holk.
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#124595 (Suggest cloning `Arc` moved into closure)
- rust-lang/rust#139594 (Simplify `ObligationCauseCode::IfExpression`)
- rust-lang/rust#141311 (make `tidy-alphabetical` use a natural sort)
- rust-lang/rust#141648 ([rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion)
- rust-lang/rust#142285 (tests: Do not run afoul of asm.validity.non-exhaustive in input-stats)
- rust-lang/rust#142393 (Don't give APITs names with macro expansion placeholder fragments in it)
- rust-lang/rust#142884 (StableMIR: Add method to retrieve body of coroutine)
- rust-lang/rust#142981 (Make missing lifetime suggestion verbose)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
such constants as patterns
|
|
Make missing lifetime suggestion verbose
I keep seeing this suggestion when working on rustc, and it's annoying that it's inline. Part of https://github.com/rust-lang/rust/issues/141973. Feel free to close this if there's another PR already doing this.
r? ``@estebank``
|
|
Don't give APITs names with macro expansion placeholder fragments in it
The `DefCollector` previously called `pprust::ty_to_string` to construct a name for APITs (arg-position impl traits). The `ast::Ty` that was being formatted however has already had its macro calls replaced with "placeholder fragments", which end up rendering like `!()` (or ICEing, in the case of rust-lang/rust#140333, since it led to a placeholder struct field with no name).
Instead, collect the name of the APIT *before* we visit its macros and replace them with placeholders in the macro expander. This makes the implementation a bit more involved, but AFAICT there's no better way to do this since we can't do a reverse mapping from placeholder fragment -> original macro call AST.
Fixes rust-lang/rust#140333
|
|
tests: Do not run afoul of asm.validity.non-exhaustive in input-stats
This addresses one of the three powerpc64-unknown-linux-musl test failures in https://github.com/rust-lang/rust/issues/142280
I was motivated to cover it myself because technically this is also compile-time UB if we compile a program that has `asm!` with x86-64-specific instructions on another platform. That'll only mean something if this is ever switched to build-pass, or if checking emits object code, but conveniently "nop" is valid assembly on all platforms anyone has implemented Rust codegen for. Even the weird ones LLVM doesn't support, like PA-RISC or Common Intermediate Language.
...except GPUs. Not sure about those.
r? ```@nnethercote```
|
|
Simplify `ObligationCauseCode::IfExpression`
This originally started out as an experiment to do less incremental invalidation by deferring the span operations that happen on the good path in `check_expr_if`, but it ended up not helping much (or at least not showing up in our incremental tests).
As a side-effect though, I think the code is a lot cleaner and there are modest diagnostics improvements with overlapping spans, so I think it's still worth landing.
|
|
Suggest cloning `Arc` moved into closure
```
error[E0382]: borrow of moved value: `x`
--> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20
|
LL | let x = "Hello world!".to_string();
| - move occurs because `x` has type `String`, which does not implement the `Copy` trait
LL | thread::spawn(move || {
| ------- value moved into closure here
LL | println!("{}", x);
| - variable moved due to use in closure
LL | });
LL | println!("{}", x);
| ^ value borrowed here after move
|
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value before moving it into the closure
|
LL ~ let value = x.clone();
LL ~ thread::spawn(move || {
LL ~ println!("{}", value);
|
```
Fix rust-lang/rust#104232.
|
|
|
|
|
|
|
|
r=fee1-dead,WaffleLapkin
Add edition checks for some tests that had divergent output
In order to expose edition dependent divergences in some tests in the test suite, add explicit `edition` annotations. Some of these tests might require additional work to *avoid* the divergences, as they might have been unintentional. These are not exhaustive changes, purely opportunistic while I was looking at something else.
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
|
|
|
|
Convert some ABI tests to use `extern "rust-invalid"`
|
|
Check CoerceUnsized impl validity before coercing
Self-explanatory from the title.
Fixes rust-lang/rust#126982
Fixes rust-lang/rust#131048
Fixes rust-lang/rust#134217
Fixes rust-lang/rust#126269
Fixes rust-lang/rust#138265
|
|
`tests/ui`: A New Order [8/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
|
|
|
|
|
|
In order to expose edition dependent divergences in some tests in the test suite, add explicit `edition` annotations. Some of these tests might require additional work to *avoid* the divergences, as they might have been unintentional. These are not exhaustive changes, purely opportunistic while looking at something else.
|
|
If we ever start testing every edition, using a new keyword unnecessarily will cause divergent output, so pre-emptively change `gen` into `generator`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The cross-build megatest gets extremely conflict-prone, so
start cutting it into smaller pieces.
|
