SmartPointer derive-macro
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Possibly replacing #123472 for continued upkeep of the proposal rust-lang/rfcs#3621 and implementation of the tracking issue #123430.
cc `@Darksonn` `@wedsonaf`
Deprecate no-op codegen option `-Cinline-threshold=...`
This deprecates `-Cinline-threshold` since using it has no effect. This has been the case since the new LLVM pass manager started being used, more than 2 years ago.
Recommend using `-Cllvm-args=--inline-threshold=...` instead.
Closes#89742 which is E-help-wanted.
Show notice about "never used" of Debug for enum
Close#123068
If an ADT implements `Debug` trait and it is not used, the compiler says a note that indicates intentionally ignored during dead code analysis as [this note](2207179a59/tests/ui/lint/dead-code/unused-variant.stderr (L9)).
However this node is not shown for variants that have fields in enum. This PR fixes to show the note.
Special case when a code line only has multiline span starts
Minimize multline span overlap when there are multiple of them starting on the same line:
```
3 | X0 Y0 Z0
| _____^ - -
| | _______| |
| || _________|
4 | ||| X1 Y1 Z1
5 | ||| X2 Y2 Z2
| |||____^__-__- `Z` label
| ||_____|__|
| |______| `Y` is a good letter too
| `X` is a good letter
```
Fix 32-bit Arm reg classes by hierarchically sorting them
We were rejecting legal `asm!` because we were asking for the "greatest" feature that includes a register class, instead of the "least" feature that includes a register class. This was only revealed on certain 32-bit Arm targets because not all have the same register limitations.
This is a somewhat hacky solution, but other solutions would require potentially rearchitecting how the internals of parsing or rejecting register classes work for all targets.
Fixes#126797
r? ``@Amanieu``
For [E0308]: mismatched types, when expr is in an arm's body, not add semicolon ';' at the end of it.
For [E0308]: mismatched types, when expr is in an arm's body, and it is the end expr without a semicolon of the block, not add semicolon ';' at the end of it.
fixes#126222
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Add hard error and migration lint for unsafe attrs
More implementation work for https://github.com/rust-lang/rust/issues/123757
This adds the migration lint for unsafe attributes, as well as making it a hard error in Rust 2024.
Replace `f16` and `f128` pattern matching stubs with real implementations
This section of code depends on `rustc_apfloat` rather than our internal types, so this is one potential ICE that we should be able to melt now.
r? `@Nadrieril`
This section of code depends on `rustc_apfloat` rather than our internal
types, so this is one potential ICE that we should be able to melt now.
This also fixes some missing range and match handling in `rustc_middle`.
Remove use of const traits (and `feature(effects)`) from stdlib
The current uses are already unsound because they are using non-const impls in const contexts. We can reintroduce them by reverting the commit in this PR, after #120639 lands.
Also, make `effects` an incomplete feature.
cc `@rust-lang/project-const-traits`
r? `@compiler-errors`
Fix `...` in multline code-skips in suggestions
When we have long code skips, we write `...` in the line number gutter.
For suggestions, we were "centering" the `...` with the line, but that was inconsistent with what we do in every other case *and* off-center.
Add a tidy rule to check that fluent messages and attrs don't end in `.`
This adds a new dependency on `fluent-parse` to `tidy` -- we already rely on it in rustc so I feel like it's not that big of a deal.
This PR also adjusts many error messages that currently end in `.`; not all of them since I added an `ALLOWLIST`, excluded `rustc_codegen_*` ftl files, and `.teach_note` attributes.
r? ``@estebank`` ``@oli-obk``
Fix another assertion failure for some Expect diagnostics.
Very similar to #126719. So much so that I added a new case to the test from that PR rather than creating a new one.
r? `@oli-obk`
Make edition dependent `:expr` macro fragment act like the edition-dependent `:pat` fragment does
Parse the `:expr` fragment as `:expr_2021` in editions <=2021, and as `:expr` in edition 2024. This is similar to how we parse `:pat` as `:pat_param` in edition <=2018 and `:pat_with_or` in >=2021, and means we can get rid of a span dependency from `nonterminal_may_begin_with`.
Specifically, this fixes a theoretical regression since the `expr_2021` macro fragment previously would allow `const {}` if the *caller* is edition 2024. This is inconsistent with the way that the `pat` macro fragment was upgraded, and also leads to surprising behavior when a macro *caller* crate upgrades to edtion 2024, since they may have parsing changes that they never asked for (with no way of opting out of it).
This PR also allows using `expr_2021` in all editions. Why was this was disallowed in the first place? It's purely additive, and also it's still feature gated?
r? ```@fmease``` ```@eholk``` cc ```@vincenzopalazzo```
cc #123865
Tracking:
- https://github.com/rust-lang/rust/issues/123742
Expand `avx512_target_feature` to include VEX variants
Added 5 new target features for x86:
- `AVX-IFMA`
- `AVX-NE-CONVERT`
- `AVX-VNNI`
- `AVX-VNNI_INT8`
- `AVX-VNNI_INT16`
Both LLVM and GCC already have support for these.
See also the [stdarch PR](https://github.com/rust-lang/stdarch/pull/1586)
Improve conflict marker recovery
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
closes#113826
r? ```@estebank``` since you reviewed #115413
cc: ```@rben01``` since you opened up the issue in the first place
Properly gate `safe` keyword in pre-expansion
This PR gates `safe` keyword in pre-expansion contexts. Should mitigate the fallout of https://github.com/rust-lang/rust/issues/126755, which is that `safe` is now usable on beta lol.
r? `@spastorino` or `@oli-obk`
cc #124482 tracking #123743
add `needs-unwind` to UI test
the `tail-expr-lock-poisoning` UI test uses the `panic::catch_unwind` API so it relies on unwinding being implemented. this test ought not to run on targets that do not support unwinding. add the `needs-unwind` attribute to signal this
collect attrs in const block expr
Fixes#126516Fixes#126647
It was forgotten to collect these attributes in the const block expression.
r? `@petrochenkov`
the `tail-expr-lock-poisoning` UI test uses the `panic::catch_unwind`
API so it relies on unwinding being implemented. this test ought not to
run on targets that do not support unwinding. add the `needs-unwind`
attribute to signal this
Add opaque type corner case test
r? ``@lcnr``
I can't make sense of the new solver tracing logs yet, so I just added the test without explanation.
The old solver does not yet figure out that `Foo == ()` from the where bounds. Unfortunately, even if we make it understand that, it will later try to prove `<X as Trait<'static>>::Out<Foo>: Sized` via the `is_sized_raw` query, which does not take a list of defineable opaque types, causing that check to fail with an ICE.
Thus I'm submitting this test case on its own just to ensure we handle it correctly in the future with any new solver or old solver changes.
Fix assertion failure for some `Expect` diagnostics.
In #120699 I moved some code dealing with `has_future_breakage` earlier in `emit_diagnostic`. Issue #126521 identified a case where that reordering was invalid (leading to an assertion failure) for some `Expect` diagnostics.
This commit partially undoes the change, by moving the handling of unstable `Expect` diagnostics earlier again. This makes `emit_diagnostic` a bit uglier, but is necessary to fix the problem.
Fixes#126521.
r? ``@oli-obk``
More status-quo tests for the `#[coverage(..)]` attribute
Follow-up to #126621, after I found even more weird corner-cases in the handling of the coverage attribute.
These tests reveal some inconsistencies that are tracked by #126658.
Stabilise `c_unwind`
Fix#74990Fix#115285 (that's also where FCP is happening)
Marking as draft PR for now due to `compiler_builtins` issues
r? `@Amanieu`
