don't apply temporary lifetime extension rules to non-extended `super let`
Reference PR: rust-lang/reference#1980
This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in https://github.com/rust-lang/rust/issues/145784#issuecomment-3218658335, making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).
Closesrust-lang/rust#145784
This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang/rust#145784). Since this affects stable macros, it probably would need a crater run.
Nominating for discussion alongside rust-lang/rust#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated
Tracking issue for `super let`: rust-lang/rust#139076
initial implementation of the darwin_objc unstable feature
Tracking issue: https://github.com/rust-lang/rust/issues/145496
This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time.
r? ```@tmandry```
try-job: `*apple*`
try-job: `x86_64-gnu-nopt`
remove FIXME block from `has_significant_drop`, it never encounters inference variables
The `FIXME` block in `Ty::has_significant_drop` is outdated as related queries can now handle type inference.
321a89bec5/compiler/rustc_middle/src/ty/util.rs (L1378-L1389)Closesrust-lang/rust#86868 (other places mentioned in the issue have been resolved, or moved to other issues)
r? types
Update the minimum external LLVM to 20
With this change, we'll have stable support for LLVM 20 and 21.
For reference, the previous increase to LLVM 19 was rust-lang/rust#139275.
cc ```@rust-lang/wg-llvm```
r? nikic
Stabilize `btree_entry_insert` feature
This stabilises `btree_map::VacantEntry::insert_entry` and `btree_map::Entry::insert_entry`, following the FCP in [tracking issue](https://github.com/rust-lang/rust/issues/65225).
New stable API:
```rust
impl<'a, K: Ord, V, A: Allocator + Clone> Entry<'a, K, V, A> {
pub fn insert_entry(self, value: V) -> OccupiedEntry<'a, K, V, A>;
}
impl<'a, K: Ord, V, A: Allocator + Clone> VacantEntry<'a, K, V, A> {
pub fn insert_entry(mut self, value: V) -> OccupiedEntry<'a, K, V, A>;
}
```
(FCP ended almost a year ago, so if it's needed for process we could rerun it)
Closes: https://github.com/rust-lang/rust/issues/65225
libtest: expose --fail-fast as an unstable command-line option
This exposes the `fail_fast` option added in rust-lang/rust#105153 on the test harness command line, so that workflows that only want to know if any test fails can find out without waiting for everything to run. For example, cargo-mutants just needs to know if any tests fails. It only works with `-Zunstable-options`.
Tracking issue: rust-lang/rust#142859
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146442 (Display ?Sized, const, and lifetime parameters in trait item suggestions across a crate boundary)
- rust-lang/rust#146474 (Improve `core::ascii` coverage)
- rust-lang/rust#146605 (Bump rustfix 0.8.1 -> 0.8.7)
- rust-lang/rust#146611 (bootstrap: emit hint if a config key is used in the wrong section)
- rust-lang/rust#146618 (Do not run ui test if options specific to LLVM are used when another codegen backend is used)
r? `@ghost`
`@rustbot` modify labels: rollup
Keep space if arg does not follow punctuation when lint unused parens
Fixesrust-lang/rust#138234
If the arg follows punctuation, still pass `left_pos` with `None` and no space will be added, else then pass `left_pos` with `Some(arg.span.lo())`, so that we can add the space as expected.
And `emit_unused_delims` can make sure no more space will be added if the expr follows space.
---
Edited:
Directly use the `value_span` to check whether the expr removed parens will follow identifier or be followed by identifier.
Do not run ui test if options specific to LLVM are used when another codegen backend is used
Based on errors in https://github.com/rust-lang/rust/pull/146414, some tests with LLVM-specific options are run when another codegen is actually the one used.
This PR ignores these tests in such cases now to prevent this situation.
r? `@kobzol`
bootstrap: emit hint if a config key is used in the wrong section
based on discussion on rust-lang/rust#146591
now, if the user puts `build.download-rustc` in `bootstrap.toml`, they'll get a diagnostic:
``hint: try moving `download-rustc` to the `rust` section``
and if they nest things too much (`rust.rust.download-rustc`):
``hint: section name `rust` used as a key within a section``
if they specify a top-level key within a section (`rust.profile`):
``hint: try using `profile` as a top level key``
r? `@Kobzol`
Bump rustfix 0.8.1 -> 0.8.7
This commit can be replicated by running `cargo update -p rustfix --precise 0.8.7 && x test ui --bless`.
---
The reasons this affects UI tests is as follows:
- The UI test suite runs rustc with `-Z deduplicate-diagnostics=no --error-format=json`, which means that rustc emits multiple errors containing identical suggestions. That caused the weird-looking code that had multiple `X: Copy` suggestions.
- Those suggestions are interpreted not by rustc itself, but by the `rustfix` library, maintained by cargo but published as a separate crates.io library and used by compiletest.
- Sometime between rustfix 0.8.1 and 0.8.7 (probably in rust-lang/cargo#14747, but it's hard to tell because rustfix's versioning doesn't match cargo's), rustfix got smarter and stopped applying duplicate suggestions.
Update rustfix to match cargo's behavior. Ideally, we would always share a version of rustfix between cargo and rustc (perhaps with a path dependency?), to make sure we are testing the behavior we ship. But for now, just manually update it to match.
Note that the latest version of rustfix published to crates.io is 0.9.1, not 0.8.7. But 0.9.1 is not the version used in cargo, which is 0.9.3. Rather than trying to match versions exactly, I just updated rustfix to the latest in the 0.8 branch.
Display ?Sized, const, and lifetime parameters in trait item suggestions across a crate boundary
context: rust-lang/rust#145929
This fixes the MetaSized issue and adds const generics and early bound lifetimes. Late bound lifetimes are harder because they aren't returned by `generics_of`. I'm going to look into it, but there's no guarantee I'll be successful.
Fixes https://github.com/rust-lang/rust/issues/146404.
r? `@BoxyUwu`
bootstrap: lower verbosity of cargo to one less than bootstrap's
the main thing this does is eliminate the "Fresh ..." output when `--verbose` is only passed once.
r? `@Kobzol`
improve internal bootstrap docs
Mainly focused on making it easier to figure out how tools get built without having to read the `bootstrap_tool!` macro, but also added some subdirs of `build/` to the readme.
compiletest: Make `./x test --test-args ...` work again
It accidentally broke with https://github.com/rust-lang/rust/pull/146501. The intention of that PR was to keep existing behavior if `--exact` is not used, but it had a bug. This PR fixes that bug.
compiletest: Enable new-output-capture by default
The new output-capture implementation was added in rust-lang/rust#146119, but was disabled by default and required opt-in.
Since then, I haven't encountered any problems in my own testing/usage, and I haven't heard any problem reports from other contributors who might have opted in.
It's unlikely that more opt-in testing will help, so the next step is to enable new-output-capture by default and see if anyone complains. (Hopefully nobody!)
If needed, the new default can be overridden (for now) by setting environment variable `COMPILETEST_NEW_OUTPUT_CAPTURE=off`. Please file an issue (or let me know) if anyone finds a reason to do this.
r? jieyouxu
llvm-wrapper: other cleanup
Cleanup few things around llvm-wrapper:
First commit removes unused macro, added back in https://github.com/rust-lang/rust/pull/31709 it was used in `LLVMRustHasFeature`; second removes unused function, third one removes `jsbackend` llvm component - this is looks like remnants of some removed backend?
interpret: fix overlapping aggregate initialization
This fixes the problem pointed out by ````@saethlin```` in https://github.com/rust-lang/rust/issues/146383#issuecomment-3273224645.
Also clarify when exactly current de-facto MIR semantics allow overlap of the LHS and RHS in an assignment.
Migrate `UnsizedConstParamTy` to unstable impl of `ConstParamTy_`
Now that we have ``#[unstable_feature_bound]``, we can remove ``UnsizedConstParamTy`` that was meant to be an unstable impl of stable type and ``ConstParamTy_`` trait.
r? `@BoxyUwU`
bootstrap.py: disable incremental build for bootstrap in CI
locally this seems to save a quarter of a second per build of bootstrap, presumably mainly because it avoids writing 280MB to disk. unsure if this is worth two extra lines of python, i'll let t-bootstrap decide.
On FreeBSD, use readdir instead of readdir_r
readdir_r has the same problems on FreeBSD as it does on other platforms: it assumes a fixed NAME_MAX. And readdir has the same thread-safety guarantee as it does on other platforms: it's safe as long as only one thread tries to read from the directory stream at a given time.
Furthermore, readdir_r is likely to be removed for FreeBSD 16, so we should stop using it now.
Note some previous attempts to change the Default impl for `[T; 0]`
Recently, rust-lang/rust#145457 experimented with changing the Default impl for `[T; 0]`.
Subsequently, rust-lang/rust#146531 also aimed to perform a similar experiment.
It seems like a good idea to add some links to the relevant source code, so that the historical context of this tricky topic is easier to find.
rustc_codegen_llvm: Adjust RISC-V inline assembly's clobber list
Despite that the `fflags` register (representing floating point exception flags) is stated as a flag register [in the reference](https://doc.rust-lang.org/reference/inline-assembly.html#r-asm.rules.preserved-registers), it's not
in the default clobber list of the RISC-V inline assembly and it would be better to fix it.
tests/codegen-llvm: Make rust-abi-arch-specific-adjustment portable
This test currently only runs on RISC-V and loongarch hosts, but assumes that the host target is the -gnu target. By using minicore, we can run this test on all host targets, regardless of architecture, as long as the LLVM components are built.
This also fixes this test on musl hosts of these architectures (though I've only tested on loongarch64-unknown-linux-musl).
This commit can be replicated by running
`cargo update -p rustfix --precise 0.8.7 && x test ui --bless`.
---
The reasons this affects UI tests is as follows:
- The UI test suite runs rustc with
`-Z deduplicate-diagnostics=no --error-format=json`,
which means that rustc emits multiple errors containing identical
suggestions. That caused the weird-looking code that had multiple `X: Copy` suggestions.
- Those suggestions are interpreted not by rustc itself, but by the
`rustfix` library, maintained by cargo but published as a separate
crates.io library and used by compiletest.
- Sometime between rustfix 0.8.1 and 0.8.7 (probably in cargo 14747, but
it's hard to tell because rustfix's versioning doesn't match cargo's),
rustfix got smarter and stopped applying duplicate suggestions.
Update rustfix to match cargo's behavior. Ideally, we would always share
a version of rustfix between cargo and rustc (perhaps with a path
dependency?), to make sure we are testing the behavior we ship. But for
now, just manually update it to match.
Note that the latest version of rustfix published to crates.io is 0.9.1,
not 0.8.7. But 0.9.1 is not the version used in cargo, which is 0.9.3.
Rather than trying to match versions exactly, I just updated rustfix to
the latest in the 0.8 branch.
It accidentally broke with a48c8e337d1. The intention of that commit was
to keep existing behavior if `--exact` is not used, but it had a bug.
This commit fixes that bug.
