Implement unstable `new_range` feature
Switches `a..b`, `a..`, and `a..=b` to resolve to the new range types.
For rust-lang/rfcs#3550
Tracking issue #123741
also adds the re-export that was missed in the original implementation of `new_range_api`
Rollup of 6 pull requests
Successful merges:
- #134807 (fix(rustdoc): always use a channel when linking to doc.rust-lang.org)
- #134814 (Add `kl` and `widekl` target features, and the feature gate)
- #135836 (bootstrap: only build `crt{begin,end}.o` when compiling to MUSL)
- #136022 (Port ui/simd tests to use the intrinsic macro)
- #136309 (set rustc dylib on manually constructed rustc command)
- #136462 (mir_build: Simplify `lower_pattern_range_endpoint`)
r? `@ghost`
`@rustbot` modify labels: rollup
mir_build: Simplify `lower_pattern_range_endpoint`
By accumulating ascriptions and inline-consts in separate vectors, we can streamline some previously-tricky code for dealing with range patterns.
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
Notes on types/traits used for in-memory query caching
When the word "cache" appears in the context of the query system, it often isn't obvious whether that is referring to the in-memory query cache or the on-disk incremental cache.
For these types, we can assure the reader that they are for in-memory caching.
Use the type-level constant value `ty::Value` where needed
**Follow-up to #136180**
### Summary
This PR refactors functions to accept a single type-level constant value `ty::Value` instead of separate `ty::ValTree` and `ty::Ty` parameters:
- `valtree_to_const_value`: now takes `ty::Value`
- `pretty_print_const_valtree`: now takes `ty::Value`
- Uses `pretty_print_const_valtree` for formatting valtrees when `visit_const_operand`
- Moves `try_to_raw_bytes` from `ty::Valtree` to `ty::Value`
---
r? ``@lukas-code`` ``@oli-obk``
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`.
Rollup of 8 pull requests
Successful merges:
- #136356 (Docs for f16 and f128: correct a typo and add details)
- #136404 (Remove a footgun-y feature / relic of the past from the compiletest DSL)
- #136432 (LTA: Actually check where-clauses for well-formedness at the def site)
- #136438 (miri: improve error when offset_from preconditions are violated)
- #136441 ([`compiletest`-related cleanups 1/7] Cleanup `is_rustdoc` logic and remove a useless path join in rustdoc-json runtest logic)
- #136455 (Remove some `Clone` bounds and derives.)
- #136464 (Remove hook calling via `TyCtxtAt`.)
- #136467 (override default config profile on tarballs)
r? `@ghost`
`@rustbot` modify labels: rollup
Add a couple of missing `ensure_sufficient_stacks`
r? `@saethlin` I hope you didn't spend time on this already.
(I couldn't sleep, opened `check_tail_calls`, there was a single call where it could happen, might as well fix it)
This PR adds a couple of missing `ensure_sufficient_stack`s:
- one in `check_tail_calls` that prevented the #135709 backport on some targets.
- after that was fixed, the test still didn't pass starting at 4MB, so I also added one in `check_unsafety` and that made it pass.
I didn't add an `rmake` test purposefully limiting the min stack size on `issue-74564-if-expr-stack-overflow.rs`, but we could if we wanted to.
On `apple-aarch64-darwin`, this is enough to make `RUST_MIN_STACK=$((1024*1024*3)) ./x test tests/ui --test-args tests/ui/issues/issue-74564-if-expr-stack-overflow.rs` pass for me locally, and it does stack overflow otherwise.
When the word "cache" appears in the context of the query system, it often
isn't obvious whether that is referring to the in-memory query cache or the
on-disk incremental cache.
For these types, we can assure the reader that they are for in-memory caching.
Remove hook calling via `TyCtxtAt`.
All hooks receive a `TyCtxtAt` argument.
Currently hooks can be called through `TyCtxtAt` or `TyCtxt`. In the latter case, a `TyCtxtAt` is constructed with a dummy span and passed to the hook.
However, in practice hooks are never called through `TyCtxtAt`, and always receive a dummy span. (I confirmed this via code inspection, and double-checked it by temporarily making the `TyCtxtAt` code path panic and running all the tests.)
This commit removes all the `TyCtxtAt` machinery for hooks. All hooks now receive `TyCtxt` instead of `TyCtxtAt`. There are two existing hooks that use `TyCtxtAt::span`: `const_caller_location_provider` and `try_destructure_mir_constant_for_user_output`. For both hooks the span is always a dummy span, probably unintentionally. This dummy span use is now explicit. If a non-dummy span is needed for these two hooks it would be easy to add it as an extra argument because hooks are less constrained than queries.
r? `@oli-obk`
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
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.
All hooks receive a `TyCtxtAt` argument.
Currently hooks can be called through `TyCtxtAt` or `TyCtxt`. In the
latter case, a `TyCtxtAt` is constructed with a dummy span and passed to
the hook.
However, in practice hooks are never called through `TyCtxtAt`, and
always receive a dummy span. (I confirmed this via code inspection, and
double-checked it by temporarily making the `TyCtxtAt` code path panic
and running all the tests.)
This commit removes all the `TyCtxtAt` machinery for hooks. All hooks
now receive `TyCtxt` instead of `TyCtxtAt`. There are two existing hooks
that use `TyCtxtAt::span`: `const_caller_location_provider` and
`try_destructure_mir_constant_for_user_output`. For both hooks the span
is always a dummy span, probably unintentionally. This dummy span use is
now explicit. If a non-dummy span is needed for these two hooks it would
be easy to add it as an extra argument because hooks are less
constrained than queries.
Explain why we retroactively change a static initializer to have a different type
I keep getting confused about it and in turn confused `@GuillaumeGomez` while trying to explain it badly
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`
```
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
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.
Convert two `rustc_middle::lint` functions to `Span` methods.
`rustc_middle` is a huge crate and it's always good to move stuff out of it. There are lots of similar methods already on `Span`, so these two functions, `in_external_macro` and `is_from_async_await`, fit right in. The diff is big because `in_external_macro` is used a lot by clippy lints.
r? ``@Noratrieb``
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
Clean up MonoItem::instantiation_mode
More progress on cleaning up and documenting instantiation mode selection.
This should have no behavior changes at all, it just rearranges the code inside `MonoItem::instantiation_mode` to a more logical flow and I've tried to explain every choice the implementation is making.
