compiler: Allow `extern "interrupt" fn() -> !`
While reviewing rust-lang/rust#142633 I overlooked a few details because I was kind of excited.
- Fixesrust-lang/rust#143072
Implement autodiff using intrinsics
This PR aims to move autodiff logic to `autodiff` intrinsic. Allowing us to delete a great part of our frontend code and overall, simplify the compilation pipeline of autodiff functions.
Change the desugaring of `assert!` for better error output
In the desugaring of `assert!`, we now expand to a `match` expression instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
Now `assert!(val)` desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix#122159.
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`
Add infrastructure to apply a derive macro to arguments, consuming and
returning a `TokenTree` only.
Handle `SyntaxExtensionKind::MacroRules` when expanding a derive, if the
macro's kinds support derive.
Add tests covering various cases of `macro_rules` derives.
Note that due to a pre-existing FIXME in `expand.rs`, derives are
re-queued and some errors get emitted twice. Duplicate diagnostic
suppression makes them not visible, but the FIXME should still get
fixed.
Use `default_field_values` in `Resolver`
Change `Resolver` to use `feature(default_field_values)`. This change is non-exhaustive, as fields may have been added since I made this commit, and `Fx(Index/Hash)(Map/Set)` types would need to have a `const` constructable to change the majority of the fields left over.
Using default field values should make it easier to review when we add or remove fields to `Resolver` in the future, and highlight which fields are run-time dependent in `Resolver::new`.
r? ``@petrochenkov``
cfg_select: Support unbraced expressions
Tracking issue for `cfg_select`: rust-lang/rust#115585
When operating on expressions, `cfg_select!` can now handle expressions
without braces. (It still requires braces for other things, such as
items.)
Expand the test coverage and documentation accordingly.
---
I'm not sure whether deciding to extend `cfg_select!` in this way is T-lang or T-libs-api. I've labeled for both, with the request that both teams don't block on each other. :)
Include whitespace in "remove |" suggestion and make it hidden
Tweak error rendering of patterns with an extra `|` on either end.
Built on #137409. Only last commit is relevant.
? ``@compiler-errors``
Rework target checking for built-in attributes
This is a refactoring of target checking for built-in attributes.
This PR has the following goals:
- Only refactor the 80% of the attributes that are simple to target check. More complicated ones like `#[repr]` will be in a future PR. Tho I have written the code in such a way that this will be possible to add in the future.
- No breaking changes.
- This part of the codebase is not very well tested though, we can do a crater run if we want to be sure.
- I've spotted quite a few weird situations (like I don't think an impl block should be deprecated?). We can propose fixing these to in a future PR
Fixes https://github.com/rust-lang/rust/issues/143780
Fixes https://github.com/rust-lang/rust/issues/138510
I've split it in commits and left a description on some of the commits to help review.
r? `@jdonszelmann`
- Added a few more variants which are needed for various attributes
- Previously a trait method with default block had the same target representation as a method in a `impl trait for` block, this has been changed (See `MethodKind`)
- Added `plural_name` for more precision on the form of the name
Stabilize `sse4a` and `tbm` target features
This PR stabilizes the feature flag `sse4a_target_feature` and `tbm_target_feature` (tracking issue rust-lang/rust#44839).
# Public API
The 2 `x86` target features `sse4a` and `tbm`
Also, these were added in LLVM2.6 and LLVM3.4-rc1, respectively, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now. The intrinsics were stabilized *long* ago, in 1.27.0
Reference PR:
- https://github.com/rust-lang/reference/pull/1949
cc `@rust-lang/lang`
`@rustbot` label I-lang-nominated
r? lang
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.
Suppress wrapper suggestion when expected and actual ty are the same adt and the variant is unresolved
Fixesrust-lang/rust#145294
I initially tried the desired suggestion in this issue, but since that suggestion occurs in the expected type, it is inappropriate to suggest for expected expressions (see other suggest methods in the same file). I believe that suppressing the incorrect suggestion is the more appropriate choice here.
I opted for a slightly more general approach: when the expected type and actual type are the same ADT (e.g., both are Result in this example), we assume that code tend to compare the internal generic parameters(i.e. `Option<&str>` vs `Option<String>`, instead of `E = _` vs `Result<Option<String>>>`). When `E` is an unresolved infer type in the expected type (`_` in this example), we should not wrapp the actual type.
Two commits show the difference.
r? compiler
Add tracing to resolve-related functions
Resolve-related functions are not called often but still make up for ~3% of execution time for non-repetitive programs (as seen in the first table below, obtained from running the rust snippet at the bottom with `n=1`). On the other hand, for repetitive programs they become less relevant (I tested the same snippet but with `n=100` and got ~1.5%), and it appears that only `try_resolve` is called more often (see the last two tables).
The first table was obtained by opening the trace file in https://ui.perfetto.dev and running the following query:
```sql
select "TOTAL PROGRAM DURATION" as name, count(*), max(ts + dur) as "sum(dur)", 100.0 as "%", null as "min(dur)", null as "max(dur)", null as "avg(dur)", null as "stddev(dur)" from slices union select "TOTAL OVER ALL SPANS (excluding events)" as name, count(*), sum(dur), cast(cast(sum(dur) as float) / (select max(ts + dur) from slices) * 1000 as int) / 10.0 as "%", min(dur), max(dur), cast(avg(dur) as int) as "avg(dur)", cast(sqrt(avg(dur*dur)-avg(dur)*avg(dur)) as int) as "stddev(dur)" from slices where parent_id is null and name != "frame" and name != "step" and dur > 0 union select name, count(*), sum(dur), cast(cast(sum(dur) as float) / (select max(ts + dur) from slices) * 1000 as int) / 10.0 as "%", min(dur), max(dur), cast(avg(dur) as int) as "avg(dur)", cast(sqrt(avg(dur*dur)-avg(dur)*avg(dur)) as int) as "stddev(dur)" from slices where parent_id is null and name != "frame" and name != "step" group by name order by sum(dur) desc, count(*) desc
```
<img width="1687" height="242" alt="image" src="https://github.com/user-attachments/assets/4d4bd890-869b-40f3-a473-8e4c42b02da4" />
The following two tables show how many `resolve` spans there per subname/subcategory, and how much time is spent in each. The first is for `n=1` and the second for `n=100`. The query that was used is:
```sql
select args.string_value as name, count(*), max(dur), avg(dur), sum(dur) from slices inner join args USING (arg_set_id) where args.key = "args." || slices.name and name = "resolve" group by args.string_value
```
<img width="1688" height="159" alt="image" src="https://github.com/user-attachments/assets/a8749856-c099-492e-a86e-6d67b146af9c" />
<img width="1688" height="159" alt="image" src="https://github.com/user-attachments/assets/ce3ac1b5-5c06-47d9-85a6-9b921aea348e" />
The snippet I tested with Miri to obtain the above traces is:
```rust
fn main() {
let n: usize = std::env::args().nth(1).unwrap().parse().unwrap();
let mut v = (0..n).into_iter().collect::<Vec<_>>();
for i in &mut v {
*i += 1;
}
}
```
