| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
Fix some fixmes that were waiting for let chains
Was inspired by looking at rust-lang/rust#143066 and spotting two fixmes that were missed, so... r? `@compiler-errors` đ
Yay, let chains!
|
|
Add `sym::macro_pin` diagnostic item for `core::pin::pin!()`
|
|
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``
|
|
Add note to `find_const_ty_from_env`
Add a note to `find_const_ty_from_env` to explain why it has an `unwrap` which "often" causes ICEs.
Also, uplift it into the new trait solver. This avoids needing to go through the interner to call this method which is otherwise an inherent method in the compiler. I can remove this part if desired.
r? `@boxyuwu`
|
|
[perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation
First compute hard errors without diagnostics, then ambiguities with diagnostics since we need to know if any of them overflowed.
|
|
Remove some glob imports from the type system
Namely, remove the glob imports for `BoundRegionConversionTime`, `RegionVariableOrigin`, `SubregionOrigin`, `TyOrConstInferVar`, `RegionResolutionError`, `SelectionError`, `ProjectionCandidate`, `ProjectionCandidateSet`, and some more specific scoped globs (like `Inserted` in the impl overlap graph construction.
These glob imports are IMO very low value, since they're not used nearly as often as other globs (like `TyKind`).
|
|
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
|
|
|
|
|
|
|
|
`evaluate_goal` avoid unnecessary step
based on rust-lang/rust#142617.
This does not mess with the debug logging for the trait solver and is a very nice cleanup for rust-lang/rust#142735. E.g. for
```rust
#[derive(Clone)]
struct Wrapper<T>(T);
#[derive(Clone)]
struct Nested; // using a separate type to avoid the fast paths
fn is_clone<T: Clone>() {}
fn main() {
is_clone::<Wrapper<Nested>>();
}
```
We get the following proof tree with `RUSTC_LOG=rustc_type_ir::search_graph=debug,rustc_next_trait_solver=debug`
```
rustc_next_trait_solver::solve::eval_ctxt::evaluate_root_goal goal=Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<Wrapper<Nested> as std::clone::Clone>, polarity:Positive), bound_vars: [] } }, generate_proof_tree=No, span=src/main.rs:7:5: 7:34 (#0), stalled_on=None
rustc_type_ir::search_graph::evaluate_goal input=CanonicalQueryInput { canonical: Canonical { value: QueryInput { goal: Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<Wrapper<Nested> as std::clone::Clone>, polarity:Positive), bound_vars: [] } }, predefined_opaques_in_body: PredefinedOpaques(PredefinedOpaquesData { opaque_types: [] }) }, max_universe: U0, variables: [] }, typing_mode: Analysis { defining_opaque_types_and_generators: [] } }, step_kind_from_parent=Unknown
rustc_next_trait_solver::solve::eval_ctxt::probe::enter source=Impl(DefId(0:10 ~ main[21d2]::{impl#0}))
rustc_next_trait_solver::solve::eval_ctxt::add_goal source=ImplWhereBound, goal=Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<_ as std::marker::Sized>, polarity:Positive), bound_vars: [] } }
rustc_next_trait_solver::solve::eval_ctxt::add_goal source=ImplWhereBound, goal=Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<_ as std::clone::Clone>, polarity:Positive), bound_vars: [] } }
rustc_type_ir::search_graph::evaluate_goal input=CanonicalQueryInput { canonical: Canonical { value: QueryInput { goal: Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<Nested as std::clone::Clone>, polarity:Positive), bound_vars: [] } }, predefined_opaques_in_body: PredefinedOpaques(PredefinedOpaquesData { opaque_types: [] }) }, max_universe: U0, variables: [] }, typing_mode: Analysis { defining_opaque_types_and_generators: [] } }, step_kind_from_parent=Unknown
0ms DEBUG rustc_type_ir::search_graph global cache hit, required_depth=0
0ms DEBUG rustc_type_ir::search_graph return=Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] })
rustc_next_trait_solver::solve::eval_ctxt::probe::enter source=BuiltinImpl(Misc)
rustc_next_trait_solver::solve::trait_goals::merge_trait_candidates candidates=[Candidate { source: Impl(DefId(0:10 ~ main[21d2]::{impl#0})), result: Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] } }]
0ms DEBUG rustc_next_trait_solver::solve::trait_goals return=Ok((Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] }, Some(Misc)))
0ms DEBUG rustc_type_ir::search_graph insert global cache, evaluation_result=EvaluationResult { encountered_overflow: false, required_depth: 1, heads: CycleHeads { heads: {} }, nested_goals: NestedGoals { nested_goals: {} }, result: Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] }) }
0ms DEBUG rustc_type_ir::search_graph return=Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] })
```
|
|
|
|
such constants as patterns
|
|
|
|
|
|
|
|
added ones
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
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``
|
|
StableMIR: Add method to retrieve body of coroutine
It would be handy if we can retrieve body of a coroutine in StableMIR.
|
|
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
|
|
r=lolbinarycat
[rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion
Fixes https://github.com/rust-lang/rust/issues/141553.
The problem was that we change the context for the attributes in some cases to get better error output, preventing us to detect if the attribute comes from expansion. Most of the changes are about keeping track of the "does this span comes from expansion" information.
r? ```@Manishearth```
|
|
make `tidy-alphabetical` use a natural sort
The idea here is that these lines should be correctly sorted, even though a naive string comparison would say they are not:
```
foo2
foo10
```
This is the ["natural sort order"](https://en.wikipedia.org/wiki/Natural_sort_order).
There is more discussion in [#t-compiler/help > tidy natural sort](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/tidy.20natural.20sort/with/519111079)
Unfortunately, no standard sorting tools are smart enough to to this automatically (casting some doubt on whether we should make this change). Here are some sort outputs:
```
> cat foo.txt | sort
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -n
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -V
foo
foo1
foo2
foo10
mp
mp1e2
np1e2",
np",
```
Disappointingly, "numeric" sort does not actually have the behavior we want. It only sorts by numeric value if the line starts with a number. The "version" sort looks promising, but does something very unintuitive if you look at the final 4 values. None of the other options seem to have the desired behavior in all cases:
```
-b, --ignore-leading-blanks ignore leading blanks
-d, --dictionary-order consider only blanks and alphanumeric characters
-f, --ignore-case fold lower case to upper case characters
-g, --general-numeric-sort compare according to general numerical value
-i, --ignore-nonprinting consider only printable characters
-M, --month-sort compare (unknown) < 'JAN' < ... < 'DEC'
-h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G)
-n, --numeric-sort compare according to string numerical value
-R, --random-sort shuffle, but group identical keys. See shuf(1)
--random-source=FILE get random bytes from FILE
-r, --reverse reverse the result of comparisons
--sort=WORD sort according to WORD:
general-numeric -g, human-numeric -h, month -M,
numeric -n, random -R, version -V
-V, --version-sort natural sort of (version) numbers within text
```
r? ```@Noratrieb``` (it sounded like you know this code?)
|
|
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.
|
|
|
|
The name of the parameter changed from `op` to `val` in cbdcbf0d6a586792c5e0a0b8965a3179bac56120
|
|
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#142146 (Withdraw the claim `extern "C-cmse-nonsecure-*"` always matches `extern "C"`)
- rust-lang/rust#142200 (`tests/ui`: A New Order [8/N])
- rust-lang/rust#142724 (Add runtime check to avoid overwrite arg in `Diag`)
- rust-lang/rust#142809 (Add PrintTAFn flag for targeted type analysis printing)
- rust-lang/rust#142976 (Check CoerceUnsized impl validity before coercing)
- rust-lang/rust#142992 (Convert some ABI tests to use `extern "rust-invalid"`)
- rust-lang/rust#143000 (Make `Sub`, `Mul`, `Div` and `Rem` `const_traits`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Encode hir attributes cross-crate properly
r? `@oli-obk`
This should return the lost perf in rust-lang/rust#138165
cc: `@therealprof`
|
|
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
|
|
Add PrintTAFn flag for targeted type analysis printing
## Summary
This PR adds a new `PrintTAFn` flag to the `-Z autodiff` option that allows printing type analysis information for a specific function, rather than all functions.
## Changes
### New Flag
- Added `PrintTAFn=<function_name>` option to `-Z autodiff`
- Usage: `-Z autodiff=Enable,PrintTAFn=my_function_name`
### Implementation Details
- **Rust side**: Added `PrintTAFn(String)` variant to `AutoDiff` enum
- **Parser**: Updated `parse_autodiff` to handle `PrintTAFn=<function_name>` syntax with proper error handling
- **FFI**: Added `set_print_type_fun` function to interface with Enzyme's `FunctionToAnalyze` command line option
- **Documentation**: Updated help text and documentation for the new flag
### Files Modified
- `compiler/rustc_session/src/config.rs`: Added `PrintTAFn(String)` variant
- `compiler/rustc_session/src/options.rs`: Updated parser and help text (now shows `PrintTAFn` in the list)
- `compiler/rustc_codegen_llvm/src/llvm/enzyme_ffi.rs`: Added FFI function and static variable
- `compiler/rustc_codegen_llvm/src/back/lto.rs`: Added handling for new flag
- `src/doc/rustc-dev-guide/src/autodiff/flags.md`: Updated documentation
- `src/doc/unstable-book/src/compiler-flags/autodiff.md`: Updated documentation
## Testing
The flag can be tested with:
```bash
rustc +enzyme -Z autodiff=Enable,PrintTAFn=square test.rs
```
This will print type analysis information only for the function named "square" instead of all functions.
## Error Handling
The parser includes proper error handling:
- Missing argument: `PrintTAFn` without `=<function_name>` will show an error
- Unknown options: Invalid autodiff options will be reported
r? ```@ZuseZ4```
|
|
Add runtime check to avoid overwrite arg in `Diag`
## Origin PR description
At first, I set up a `debug_assert` check for the arg method to make sure that `args` in `Diag` aren't easily overwritten, and I added the `remove_arg()` method, so that if you do need to overwrite an arg, then you can explicitly call `remove_arg()` to remove it first, then call `arg()` to overwrite it.
For the code before the rust-lang/rust#142015 change, it won't compile because it will report an error
```
arg `instance`already exists.
```
This PR also modifies all diagnostics that fail the check to pass the check. There are two cases of check failure:
1. ~~Between *the parent diagnostic and the subdiagnostic*, or *between the subdiagnostics* have the same field between them. In this case, I renamed the conflicting fields.~~
2. ~~For subdiagnostics stored in `Vec`, the rendering may iteratively write the same arg over and over again. In this case, I changed the auto-generation with `derive(SubDiagnostic)` to manually implementing `SubDiagnostic` and manually rendered it with `eagerly_translate()`, similar to https://github.com/rust-lang/rust/issues/142031#issuecomment-2984812090, and after rendering it I manually deleted useless arg with the newly added `remove_arg` method.~~
## Final Decision
After trying and discussing, we made a final decision.
For `#[derive(Subdiagnostic)]`, This PR made two changes:
1. After the subdiagnostic is rendered, remove all args of this subdiagnostic, which allows for usage like `Vec<Subdiag>`.
2. Store `diag.args` before setting arguments, so that you can restore the contents of the main diagnostic after deleting the arguments after subdiagnostic is rendered, to avoid deleting the main diagnostic's arg when they have the same name args.
|
|
workingjubilee:doubt-that-cmse-nonsecure-abis-always-match-c, r=compiler-errors
Withdraw the claim `extern "C-cmse-nonsecure-*"` always matches `extern "C"`
We currently claim that `extern "C-cmse-nonsecure-*"` ABIs will always match `extern "C"`, but that seems... **optimistic** when one considers that `extern "C"` is ambiguous enough to be redefined in ways we may not want the Cortex M Security Extensions ABIs to mirror. If some configuration, feature, or other platform quirk that applied to Arm CPUs with CMSE would modify the `extern "C"` ABI, it does not seem like we should guarantee that also applies to the `extern "cmse-nonsecure-*"` ABIs. Anything involving target modifiers that might affect register availability or usage could make us liars if, for instance, clang decides those apply to normal C functions but not ones with the CMSE attributes, but we still want to have interop with the C compiler.
We simply do not control enough of the factors involved to both force these ABIs to match and still provide useful interop, so we shouldn't implicitly promise they do. We should leave this judgement call to the decisions of platform experts who can afford to keep up with the latest news from Cambridge, instead of enshrining today's hopeful guess forever in Rust's permitted ABIs.
It's a bit weird anyways.
- The attributes are `__attribute__((cmse_nonsecure_call))` and `__attribute__((cmse_nonsecure_entry))`, so the obvious choice is `extern "cmse-nonsecure-call"` and `extern "cmse-nonsecure-entry"`.
- We do not prefix any other ABI that reflects (or even *is*) a C ABI with "C-", with the exception of the Rust-defined `extern "C-unwind`", e.g. we do not have `extern "C-aapcs"` or `extern "C-sysv64"`.
Tracking issues:
- rust-lang/rust#75835
- rust-lang/rust#81391
|
|
|
|
|
|
Remove dead instructions in terminate blocks
Terminate blocks look pretty in the IR I've looked at, so no actual perf delta from this. But it seems reasonable to note produce unused IR.
|
|
|
