Add `kl` and `widekl` target features, and the feature gate
This is an effort towards #134813. This PR adds the target-features and the feature gate to `rustc`
<!--
```@rustbot``` label O-x86_64 O-x86_32 A-target-feature
r? compiler
-->
Rollup of 8 pull requests
Successful merges:
- #136289 (OnceCell & OnceLock docs: Using (un)initialized consistently)
- #136299 (Ignore NLL boring locals in polonius diagnostics)
- #136411 (Omit argument names from function pointers that do not have argument names)
- #136430 (Use the type-level constant value `ty::Value` where needed)
- #136476 (Remove generic `//@ ignore-{wasm,wasm32,emscripten}` in tests)
- #136484 (Notes on types/traits used for in-memory query caching)
- #136493 (platform-support: document CPU baseline for x86-32 targets)
- #136498 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
This has now been approved as a language feature and no longer needs
a `rustc_` prefix.
Also change the `contracts` feature to be marked as incomplete and
`contracts_internals` as internal.
1. Document the new intrinsics.
2. Make the intrinsics actually check the contract if enabled, and
remove `contract::check_requires` function.
3. Use panic with no unwind in case contract is using to check for
safety, we probably don't want to unwind. Following the same
reasoning as UB checks.
Instead of parsing the different components of a function signature,
eagerly look for either the `where` keyword or the function body.
- Also address feedback to use `From` instead of `TryFrom` in cranelift
contract and ubcheck codegen.
The extended syntax for function signature that includes contract clauses
should never be user exposed versus the interface we want to ship
externally eventually.
includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures.
includes post-developed commit: removed tabs that creeped in into rustfmt tool source code.
includes post-developed commit, placating rustfmt self dogfooding.
includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/
includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures).
Rebase Conflicts:
- compiler/rustc_parse/src/parser/diagnostics.rs
- compiler/rustc_parse/src/parser/item.rs
- compiler/rustc_span/src/hygiene.rs
Remove contracts keywords from diagnostic messages
Ignore NLL boring locals in polonius diagnostics
Another easy one ``@jackh726`` (the diff is inflated by blessed test expectations don't worry :)
NLLs don't compute liveness for boring locals, and therefore cannot find them in causes explaining borrows. In polonius, we don't have this liveness optimization (we may be able to do something partially similar in the future, e.g. for function parameters and the like), so we do encounter these in diagnostics even though we don't want to. This PR:
- restructures the polonius context into per-phase data, in spirit as you requested in an earlier review
- stores the locals NLLs would consider boring into the errors/diagnostics data
- ignores these if a boring local is found when trying to explain borrows
This PR fixes around 80 cases of diagnostics differences between `-Zpolonius=next` and NLLs. I've also added explicit revisions to a few polonius tests (both for the in-tree implementation as well as the datalog implementation -- even if we'll eventually remove them). I didn't do this for all the "dead" expectations that were removed from #136112 for that same reason, it's fine. I'll soon/eventually add explicit revisions where they're needed: there's only a handful of tests left to fix.
r? ``@jackh726``
Explicitly choose x86 softfloat/hardfloat ABI
Part of https://github.com/rust-lang/rust/pull/135408:
Instead of choosing this based on the target features listed in the target spec, make that choice explicit.
All built-in targets are being updated here; custom (JSON-defined) x86 (32bit and 64bit) softfloat targets need to explicitly set `rustc-abi` to `x86-softfloat`.
When we suggest specifying a type for an expression or pattern, like in a `let` binding, we previously would print the entire type as the type system knew it. We now look at the params that have *no* inference variables, so they are fully known to the type system which means that they don't need to be specified.
This helps in suggestions for types that are really long, because we can usually skip most of the type params and make the annotation as short as possible:
```
error[E0282]: type annotations needed for `Result<_, ((..., ..., ..., ...), ..., ..., ...)>`
--> $DIR/really-long-type-in-let-binding-without-sufficient-type-info.rs:7:9
|
LL | let y = Err(x);
| ^ ------ type must be known at this point
|
help: consider giving `y` an explicit type, where the type for type parameter `T` is specified
|
LL | let y: Result<T, _> = Err(x);
| ++++++++++++++
```
- duplicates of crateresolve1 are used in a couple error-codes tests
- also fix the note in crateresolve1 to link to these other duplicates,
now that E0523 has been merged into E0464
This removes support for attributes on struct field rest patterns (the `..`) from the parser.
Previously they were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
LTA: Actually check where-clauses for well-formedness at the def site
All of the added tests used to wrongfully pass.
r? oli-obk or types/compiler or reassign
This aligns the main error message a bit more with the phrasing in the
Edition Guide and provides a bit more information on the labels to
(hopefully!) aid in understanding.
Target modifiers (special marked options) are recorded in metainfo
Target modifiers (special marked options) are recorded in metainfo and compared to be equal in different linked crates.
PR for this RFC: https://github.com/rust-lang/rfcs/pull/3716
Option may be marked as `TARGET_MODIFIER`, example: `regparm: Option<u32> = (None, parse_opt_number, [TRACKED TARGET_MODIFIER]`.
If an TARGET_MODIFIER-marked option has non-default value, it will be recorded in crate metainfo as a `Vec<TargetModifier>`:
```
pub struct TargetModifier {
pub opt: OptionsTargetModifiers,
pub value_name: String,
}
```
OptionsTargetModifiers is a macro-generated enum.
Option value code (for comparison) is generated using `Debug` trait.
Error example:
```
error: mixing `-Zregparm` will cause an ABI mismatch in crate `incompatible_regparm`
--> $DIR/incompatible_regparm.rs:10:1
|
LL | #![crate_type = "lib"]
| ^
|
= help: the `-Zregparm` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
= note: `-Zregparm=1` in this crate is incompatible with `-Zregparm=2` in dependency `wrong_regparm`
= help: set `-Zregparm=2` in this crate or `-Zregparm=1` in `wrong_regparm`
= help: if you are sure this will not cause problems, use `-Cunsafe-allow-abi-mismatch=regparm` to silence this error
error: aborting due to 1 previous error
```
`-Cunsafe-allow-abi-mismatch=regparm,reg-struct-return` to disable list of flags.
Shorten error message for callable with wrong return type
```
error: expected `{closure@...}` to return `Ret`, but it returns `Other`
```
instead of
```
error: expected `{closure@...}` to be a closure that returns `Ret`, but it returns `Other`
```
Fix malformed error annotations in a UI test
The compiletest DSL still features a historical remnant from the time when its directives were merely prefixed with `//` instead of `//`@`` when unknown directive names weren't rejected since they could just as well be part of prose:
As an "optimization", it stops looking for directives once it stumbles upon a line which starts with either `fn` or `mod`. This allowed a malformed error annotation of the form `//`@[…]~^^^`` to go undetected & unexercised (as it's placed below `fn main() {`).
Obviously a character other than ``@`` would've mangled the error annotation, too (but it might've caught the reviewer's eye). I specifically found this file because I ran `rg '^(fn|mod)[\s\S]*?//`@'` tests/ui --multiline -trust` to check how footgun-y that "special feature" of compiletest is.
Test validity of pattern types
r? `@RalfJung`
pulled out of #136006 so we don't have to rely on libcore types excercising this code path
There's nothing to fix. `rustc_layout_scalar_valid_range_start` structs just failed their validation on their value instead of their fields' value, causing a diff where moving to pattern types adds an additional `.0` field access to the validation error
```
error[E0369]: cannot add `((..., ..., ..., ...), ..., ..., ...)` to `((..., ..., ..., ...), ..., ..., ...)`
--> $DIR/binop.rs:9:7
|
LL | x + x;
| - ^ - ((..., ..., ..., ...), ..., ..., ...)
| |
| ((..., ..., ..., ...), ..., ..., ...)
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
```
error[E0600]: cannot apply unary operator `!` to type `(..., ..., ..., ...)`
--> $DIR/binop.rs:14:5
|
LL | !x;
| ^^ cannot apply unary operator `!`
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
CC #135919.
rustc_allowed_through_unstable_modules: require deprecation message
This changes the `#[rustc_allowed_through_unstable_modules]` attribute so that a deprecation message (ideally directing people towards the stable path) is required.
Highlight clarifying information in "expected/found" error
When the expected and found types have the same textual representation, we add clarifying in parentheses. We now visually highlight it in the output.
Detect a corner case where the clarifying information would be the same for both types and skip it, as it doesn't add anything useful.
diagnostics: fix borrowck suggestions for if/while let conditionals
This code detects the case where one of the borrows is inside the let init expr while the other end is not. If that happens, we don't want to suggest adding a semicolon, because it won't work.
Fixes#133941
