| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 5 pull requests
Successful merges:
- #133156 (typo in config.example.toml)
- #133157 (stability: remove skip_stability_check_due_to_privacy)
- #133163 (remove pointless cold_path impl in interpreter)
- #133169 (Update autolabels for T-compiler and T-bootstrap)
- #133171 (Add the missing quotation mark in comment)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add the missing quotation mark in comment
|
|
Update autolabels for T-compiler and T-bootstrap
- Tag more test suite changes with `T-compiler`.
- Tag `src/build_helper` with `T-bootstrap`.
|
|
remove pointless cold_path impl in interpreter
This has a fallback impl so the interpreter impl is not needed.
r? ``@saethlin``
|
|
r=compiler-errors
stability: remove skip_stability_check_due_to_privacy
This was added in https://github.com/rust-lang/rust/pull/38689 to deal with https://github.com/rust-lang/rust/issues/38412. However, even after removing the check, the relevant tests still pass. Let's see if CI finds any other tests that rely on this. If not, it seems like logic elsewhere in the compiler changed so this is not required any more.
|
|
typo in config.example.toml
|
|
Rollup of 4 pull requests
Successful merges:
- #132934 (Overhaul the `-l` option parser (for linking to native libs))
- #133142 (rename rustc_const_stable_intrinsic -> rustc_intrinsic_const_stable_indirect)
- #133145 (Document alternatives to `static mut`)
- #133158 (Subtree update of `rust-analyzer`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Signed-off-by: binchengqu <bincheng@before.tech>
|
|
|
|
|
|
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
Document alternatives to `static mut`
In #133143 I've noticed alternatives to `static mut` aren't documented anywhere.
|
|
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.
|
|
Rwlock downgrade
Tracking Issue: #128203
This PR adds a `downgrade` method for `RwLock` / `RwLockWriteGuard` on all currently supported platforms.
Outstanding questions:
- [x] ~~Does the `futex.rs` change affect performance at all? It doesn't seem like it will but we can't be certain until we bench it...~~
- [x] ~~Should the SOLID platform implementation [be ported over](https://github.com/rust-lang/rust/pull/128219#discussion_r1693470090) to the `queue.rs` implementation to allow it to support downgrades?~~
|
|
|
|
|
|
|
|
|
|
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`
|
|
|
|
|
