| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rename rustc_const_stable_intrinsic -> rustc_intrinsic_const_stable_indirect
In https://github.com/rust-lang/rust/pull/120370 this name caused confusion as the author thought the intrinsic was stable. So let's try a different name...
If we can land this before the beta cutoff we can avoid needing `cfg(bootstrap)` for this. ;)
Cc `@compiler-errors` `@saethlin`
|
|
Overhaul the `-l` option parser (for linking to native libs)
The current parser for `-l` options has accumulated over time, making it hard to follow. This PR tries to clean it up in several ways.
Key changes:
- This code now gets its own submodule, to slightly reduce clutter in `rustc_session::config`.
- Cleaner division between iterating over multiple `-l` options, and processing each individual one.
- Separate “split” step that breaks up the value string into `[KIND[:MODIFIERS]=]NAME[:NEW_NAME]`, but leaves parsing/validating those parts to later steps.
- This step also gets its own (disposable) unit test, to make sure it works as expected.
- A context struct reduces the burden of parameter passing, and makes it easier to write error messages that adapt to nightly/stable compilers.
- Fewer calls to `nightly_options` helper functions, because at this point we can get the same information from `UnstableOptions` and `UnstableFeatures` (which are downstream of earlier calls to those helper functions).
There should be no overall change in compiler behaviour.
|
|
|
|
|
|
No functional change (yet).
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #132795 (Check `use<..>` in RPITIT for refinement)
- #132944 (add parentheses when unboxing suggestion needed)
- #132993 (Make rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1`)
- #133130 (`suggest_borrow_generic_arg`: instantiate clauses properly)
- #133133 (rustdoc-search: add standalone trailing `::` test)
- #133143 (Diagnostics for let mut in item context)
- #133147 (Fixup some test directives)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fixup some test directives
- A random comment had somehow been turned into an `//`@`` directive.
- More dubiously I also removed leading spaces from directives in 3 UI tests for consistency. These are the only rustc tests that use that formatting.
r? `@jieyouxu`
|
|
Diagnostics for let mut in item context
The diagnostics for `let` at the top level did not account for `let mut`, which [made the error unclear](https://users.rust-lang.org/t/create-a-vector-of-constants-outside-main/121251/1).
I've made the diagnostic always display a link to valid items. I've added dedicated help for `let mut` case that suggests using a `Mutex` (to steer novice users away from the `static mut` trap). Unfortunately, neither the Rust book, nor libstd docs have dedicated section listing all other types for interior-mutable `static`s.
|
|
rustdoc-search: add standalone trailing `::` test
Follow up for #132569
r? `@GuillaumeGomez`
|
|
`suggest_borrow_generic_arg`: instantiate clauses properly
This simplifies and fixes the way `suggest_borrow_generic_arg` instantiates callees' predicates when testing them to see if a moved argument can instead be borrowed. Previously, it would ICE if the moved argument's type included a region variable, since it was getting passed to a call of `EarlyBinder::instantiate`. This makes the instantiation much more straightforward, which also fixes the ICE.
Fixes #133118
This also modifies `tests/ui/moves/moved-value-on-as-ref-arg.rs` to have more useful bounds on the tests for suggestions to borrow `Borrow` and `BorrowMut` arguments. With its old tautological `T: BorrowMut<T>` bound, this fix would make it suggest a shared borrow for that argument.
|
|
Make rustc consider itself a stable compiler when `RUSTC_BOOTSTRAP=-1`
Addresses https://github.com/rust-lang/rust/issues/123404 to allow test writers to specify `//@ rustc-env:RUSTC_BOOTSTRAP=-1` to have a given rustc consider itself a stable rustc. This is only intended for testing usages.
I did not use `RUSTC_BOOTSTRAP=0` because that can be confusing, i.e. one might think that means "not bootstrapping", but "forcing a given rustc to consider itself a stable compiler" is a different use case.
I also added a specific test to check `RUSTC_BOOTSTRAP`'s various values and how that interacts with rustc's stability story w.r.t. features and cli flags.
Noticed when trying to write a test for enabling ICE file dumping on stable.
Dunno if this needs a compiler FCP or MCP, but I can file an MCP or ask someone to start an FCP if needed. Note that `RUSTC_BOOTSTRAP` is a perma-unstable env var and has no stability guarantees (heh) whatsoever. This does not affect bootstrapping because bootstrap never sets `RUSTC_BOOTSTRAP=-1`. If someone does set that when bootstrapping, it is considered PEBKAC.
Accompanying dev-guide PR: https://github.com/rust-lang/rustc-dev-guide/pull/2136
cc `@estebank` and `@rust-lang/wg-diagnostics` for FYI
|
|
r=chenyukang
add parentheses when unboxing suggestion needed
This PR tried to `add parentheses when unboxing suggestion needed`
Fixes #132924
|
|
Check `use<..>` in RPITIT for refinement
`#![feature(precise_capturing_in_traits)]` allows users to write `+ use<>` bounds on RPITITs to control what lifetimes are captured by the RPITIT.
Since RPITITs currently also warn for refinement in implementations, this PR extends that refinement check for cases where we *undercapture* in an implementation, since that may be indirectly "promising" a more relaxed outlives bound than the impl author intended.
For an opaque to be refining, we need to capture *fewer* parameters than those mentioned in the captured params of the trait. For example:
```
trait TypeParam<T> {
fn test() -> impl Sized;
}
// Indirectly capturing a lifetime param through a type param substitution.
impl<'a> TypeParam<&'a ()> for i32 {
fn test() -> impl Sized + use<> {}
//~^ WARN impl trait in impl method captures fewer lifetimes than in trait
}
```
Since the opaque in the method (implicitly) captures `use<Self, T>`, and `Self = i32, T = &'a ()` in the impl, we must mention `'a` in our `use<..>` on the impl.
Tracking:
* https://github.com/rust-lang/rust/issues/130044
|
|
|
|
Fixes issue 133118.
This also modifies `tests/ui/moves/moved-value-on-as-ref-arg.rs` to have more
useful bounds on the tests for suggestions to borrow `Borrow` and `BorrowMut`
arguments. With its old tautological `T: BorrowMut<T>` bound, this fix would
make it suggest a shared borrow for that argument.
|
|
|
|
Likely unlikely fix
RFC 1131 ( https://github.com/rust-lang/rust/issues/26179 ) added likely/unlikely intrinsics, but they have been broken for a while: https://github.com/rust-lang/rust/issues/96276 , https://github.com/rust-lang/rust/issues/96275 , https://github.com/rust-lang/rust/issues/88767 . This PR tries to fix them.
Changes:
- added a new `cold_path()` intrinsic
- `likely()` and `unlikely()` changed to regular functions implemented using `cold_path()`
|
|
|
|
|
|
Liberate `aarch64-gnu-debug` from the shackles of `--test-args=clang`
### Changes
- Drop `--test-args=clang` from `aarch64-gnu-debug` so run-make tests that are `//@ needs-force-clang-based-tests` no longer only run if their test name contains `clang` (which is a very cool footgun).
- Reorganize run-make-suport library slightly to accommodate a raw gcc invocation.
- Fix `tests/run-make/mte-ffi/rmake.rs` to use `gcc` instead of *a* c compiler.
try-job: aarch64-gnu
try-job: aarch64-gnu-debug
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #133029 (ABI checks: add support for some tier3 arches, warn on others.)
- #133051 (Increase accuracy of `if` condition misparse suggestion)
- #133060 (Trim whitespace in RemoveLet primary span)
- #133093 (Let chains tests)
- #133116 (stabilize const_ptr_is_null)
- #133126 (alloc: fix `String`'s doc)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
alloc: fix `String`'s doc
Just a minor fix for `String` struct.
|
|
stabilize const_ptr_is_null
FCP passed in https://github.com/rust-lang/rust/issues/74939.
The second commit cleans up const stability around UB checks a bit, now that everything they need (except for `const_eval_select`) is stable.
Fixes https://github.com/rust-lang/rust/issues/74939
|
|
Let chains tests
Filing this as this marks off two of the open issues in #132833:
* extending the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's (one implementation could for example search for the first `let` and then terminate).
* An instance where a temporary lives shorter than with nested ifs, breaking compilation: #103476. This was fixed in the end by the if let rescoping work.
Closes #103476
|
|
Trim whitespace in RemoveLet primary span
Separate `RemoveLet` span into primary span for `let` and removal suggestion span for `let `, so that primary span does not include whitespace.
Fixes: #133031
|
|
Increase accuracy of `if` condition misparse suggestion
Fix #132656.
Look at the expression that was parsed when trying to recover from a bad `if` condition to determine what was likely intended by the user beyond "maybe this was meant to be an `else` body".
```
error: expected `{`, found `map`
--> $DIR/missing-dot-on-if-condition-expression-fixable.rs:4:30
|
LL | for _ in [1, 2, 3].iter()map(|x| x) {}
| ^^^ expected `{`
|
help: you might have meant to write a method call
|
LL | for _ in [1, 2, 3].iter().map(|x| x) {}
| +
```
If a macro statement has been parsed after `else`, suggest a missing `if`:
```
error: expected `{`, found `falsy`
--> $DIR/else-no-if.rs:47:12
|
LL | } else falsy! {} {
| ---- ^^^^^
| |
| expected an `if` or a block after this `else`
|
help: add an `if` if this is the condition of a chained `else if` statement
|
LL | } else if falsy! {} {
| ++
```
|
|
ABI checks: add support for some tier3 arches, warn on others.
Followup to
- https://github.com/rust-lang/rust/pull/132842
- https://github.com/rust-lang/rust/pull/132173
- https://github.com/rust-lang/rust/issues/131800
r? ``@workingjubilee``
|
|
Follow up for #132569
|
|
Revert "tidy: validate LLVM component names in tests"
This reverts #125472.
This has already caused a [bit](https://github.com/rust-lang/rust/pull/125702) of [trouble](https://github.com/rust-lang/rust/pull/125710), and I was mistaken about the original motivation--incorrect component names [_will_](https://github.com/rust-lang/rust/pull/125702#issuecomment-2137030731) be detected by a full CI run.
I no longer think it pulls its weight.
r? `@workingjubilee`
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #131717 (Stabilize `const_atomic_from_ptr`)
- #132134 (Remove `ResultsVisitable`)
- #132449 (mark is_val_statically_known intrinsic as stably const-callable)
- #132569 (rustdoc search: allow queries to end in an empty path segment)
- #132787 (Unify FnKind between AST visitors and make WalkItemKind more straight forward)
- #132832 (Deny capturing late-bound ty/const params in nested opaques)
- #133097 (Opt out TaKO8Ki from review rotation for now)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Querify MonoItem collection
Factored out of https://github.com/rust-lang/rust/pull/131650. These changes are required for post-mono MIR opts, because the previous implementation would load the MIR for every Instance that we traverse (as well as invoke queries on it). The cost of that would grow massively with post-mono MIR opts because we'll need to load new MIR for every Instance, instead of re-using the `optimized_mir` for every Instance with the same DefId.
So the approach here is to add two new queries, `items_of_instance` and `size_estimate`, which contain the specific information about an Instance's MIR that MirUsedCollector and CGU partitioning need, respectively. Caching these significantly increases the size of the query cache, but that's justified by our improved incrementality (I'm sure walking all the MIR for a huge crate scales quite poorly).
This also changes `MonoItems` into a type that will retain the traversal order (otherwise we perturb a bunch of diagnostics), and will also eliminate duplicate findings. Eliminating duplicates removes about a quarter of the query cache size growth.
The perf improvements in this PR are inflated because rustc-perf uses `-Zincremental-verify-ich`, which makes loading MIR a lot slower because MIR contains a lot of Spans and computing the stable hash of a Span is slow. And the primary goal of this PR is to load less MIR. Some squinting at `collector profile_local perf-record +stage1` runs suggests the magnitude of the improvements in this PR would be decreased by between a third and a half if that flag weren't being used. Though this effect may apply to the regressions too since most are incr-full and this change also causes such builds to encode more Spans.
|
|
|
|
Update cargo
15 commits in 4a2d8dc636445b276288543882e076f254b3ae95..69e595908e2c420e7f0d1be34e6c5b984c8cfb84
2024-11-09 19:10:33 +0000 to 2024-11-16 01:26:11 +0000
- refactor(fingerprint): Track the intent for each use of `UnitHash` (rust-lang/cargo#14826)
- fix(toml): Update frontmatter parser for RFC 3503 (rust-lang/cargo#14792)
- docs(unstable): Move -Zwarnings from stable to unstable section (rust-lang/cargo#14827)
- Simplify English used in guide (rust-lang/cargo#14825)
- feat(resolver): Stabilize resolver v3 (rust-lang/cargo#14754)
- docs: Clean up doc comments (rust-lang/cargo#14823)
- fix(remove): On error, suggest other dependencies (rust-lang/cargo#14818)
- Always include Cargo.lock in published crates (rust-lang/cargo#14815)
- fix(build-rs)!: Updates from an audit (rust-lang/cargo#14817)
- feat(rustdoc): diplay env vars in extra verbose mode (rust-lang/cargo#14812)
- Migrate build-rs to the Cargo repo (rust-lang/cargo#14786)
- chore(ci): Check for clippy `correctness` (rust-lang/cargo#14796)
- git: do not validate submodules of fresh checkouts (rust-lang/cargo#14605)
- refactor: clone-on-write when needed for InternedString (rust-lang/cargo#14808)
- fix(docs): typo in cargo-fmt.md (rust-lang/cargo#14805)
|
|
|
|
|
|
Update cdb annotations for some debuginfo tests with cdb `10.0.26100.2161`
GitHub CI runners [recently updated to Windows Server 2022 (20241113)](https://github.com/actions/runner-images/releases/tag/win22%2F20241113.3) which included Windows Software Development Kit version `10.1.26100.1742`, which transitively shipped a `cdb` version `10.0.26100.2161`.
This changed some cdb output, causing 3 debuginfo tests to fail (see #133107, https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/msvc.20update.20causing.20debuginfo.20failures):
```
tests\debuginfo\numeric-types.rs
tests\debuginfo\range-types.rs
tests\debuginfo\unit-type.rs
```
I updated cdb annotations for these 3 tests locally with a matching `cdb` version. However, I am not by any means a cdb expert nor debuginfo expert, I just reblessed the tests to match whatever the new cdb version produces to unblock the tree. It is certainly possible that debuginfo improved/regressed/both with the newer cdb version.
try-job: x86_64-msvc
|
|
This is to unblock the tree, a proper fix will need to be investigated.
I think the debuginfo test suite supports revisions, however debugger
directives do not respect such revisions, which is problematic.
It's that 32-bit and 64-bit msvc of course have different integer widths
for `isize` and `usize`, meaning their underlying integer is different
and thus printed differently.
|
|
Opt out TaKO8Ki from review rotation for now
Hi `@TaKO8Ki,` I'm opting you out from compiler/diagnostics review rotation for now because I *think* you're very busy recently. Please feel free to re-add yourself (or close this PR) whenever you have more time / feel like it.
|
|
Deny capturing late-bound ty/const params in nested opaques
First, this reverts a7f609504c92c9912b61025ae26a5404d3ee4311. I can't exactly remember why I approved this specific bit of https://github.com/rust-lang/rust/pull/132466; specifically, I don't know that the purpose of that commit is, and afaict we will never have an opaque that captures late-bound params through a const because opaques can't be used inside of anon consts. Am I missing something `@cjgillot?` Since I can't see a case where this matters, and no tests seem to fail.
The second commit adds a `deny_late_regions: bool` to distinguish `Scope::LateBoundary` which should deny *any* late-bound params or just ty/consts. Then, when resolving opaques we wrap ourselves in a `Scope::LateBoundary { deny_late_regions: false }` so that we deny late-bound ty/const, which fixes a bunch of ICEs that all vaguely look like `impl for<T> Trait<Assoc = impl OtherTrait<T>>`.
I guess this could be achieved other ways; for example, with a different scope kind, or maybe we could just reuse `Scope::Opaque`. But this seems a bit more verbose. I'm open to feedback anyways.
Fixes #131535
Fixes #131637
Fixes #132530
I opted to remove those crashes tests ^ without adding them as regular tests, since they're basically triggering uninteresting late-bound ICEs far off in the trait solver, and the reason that existing tests such as `tests/ui/type-alias-impl-trait/non-lifetime-binder-in-constraint.rs` don't ICE are kinda just coincidental (i.e. due to a missing impl block). I don't really feel motivated to add random permutations to tests just to exercise non-lifetime binders.
r? cjgillot
|
|
Unify FnKind between AST visitors and make WalkItemKind more straight forward
Unifying `FnKind` requires a bunch of changes to `WalkItemKind::walk` signature so I'll change them in one go
related to #128974
r? `@petrochenkov`
|
|
r=notriddle
rustdoc search: allow queries to end in an empty path segment
fixes https://github.com/rust-lang/rust/issues/129707
this can be used to show all items in a module,
or all associated items for a type.
currently sufferes slightly due to case insensitivity, so `Option::` will also show items in the `option::` module.
it disables the checking of the last path element, otherwise only items with short names will be shown
r? `@notriddle`
|
|
mark is_val_statically_known intrinsic as stably const-callable
The intrinsic doesn't actually "do" anything in terms of language semantics, and we are already using it in stable const fn. So let's just properly mark it as stably const-callable to avoid needing `rustc_allow_const_fn_unstable` (and thus reducing noise and keeping the remaining `rustc_allow_const_fn_unstable` as a more clear signal).
Cc `@rust-lang/lang` usually you have to approve exposing intrinsics in const, but this intrinsic is basically just a compiler implementation detail. So FCP doesn't seem necessary.
Cc `@rust-lang/wg-const-eval`
|
|
Remove `ResultsVisitable`
`ResultsVisitable` has annoyed me for a while. This PR removes it. Details in the individual commits.
r? `@cjgillot.`
|
|
Stabilize `const_atomic_from_ptr`
The API is already stable since https://github.com/rust-lang/rust/pull/115719, but const stability was blocked on `const_mut_refs`. Since that was recently stabilized, const stabilize the following:
```rust
// core::atomic
impl AtomicBool { pub const unsafe fn from_ptr<'a>(ptr: *mut bool) -> &'a AtomicBool; }
impl<T> AtomicPtr<T> { pub const unsafe fn from_ptr<'a>(ptr: *mut *mut T) -> &'a AtomicPtr<T>; }
impl AtomicU8 { pub const unsafe fn from_ptr<'a>(ptr: *mut u8) -> &'a AtomicU8; }
impl AtomicU16 { pub const unsafe fn from_ptr<'a>(ptr: *mut u16) -> &'a AtomicU16; }
impl AtomicU32 { pub const unsafe fn from_ptr<'a>(ptr: *mut u32) -> &'a AtomicU32; }
impl AtomicU64 { pub const unsafe fn from_ptr<'a>(ptr: *mut u64) -> &'a AtomicU64; }
impl AtomicUsize { pub const unsafe fn from_ptr<'a>(ptr: *mut usize) -> &'a AtomicUsize; }
impl AtomicI8 { pub const unsafe fn from_ptr<'a>(ptr: *mut i8) -> &'a AtomicI8; }
impl AtomicI16 { pub const unsafe fn from_ptr<'a>(ptr: *mut i16) -> &'a AtomicI16; }
impl AtomicI32 { pub const unsafe fn from_ptr<'a>(ptr: *mut i32) -> &'a AtomicI32; }
impl AtomicI64 { pub const unsafe fn from_ptr<'a>(ptr: *mut i64) -> &'a AtomicI64; }
impl AtomicIsize { pub const unsafe fn from_ptr<'a>(ptr: *mut isize) -> &'a AtomicIsize; }
```
|
|
|
|
|
