| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
The panic_abort crate must be compiled with panic=abort, but cargo
doesn't allow setting the panic strategy for a single crate the usual
way using panic="abort", but luckily per-package rustflags do allow
this. Bootstrap previously handled this in its rustc wrapper, but for
example the build systems of cg_clif and cg_gcc don't use the rustc
wrapper, so they would either need to add one, patch the standard
library or be unable to build a sysroot suitable for both panic=abort
and panic=unwind (as is currently the case).
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#138291 (rewrite `optimize` attribute to use new attribute parsing infrastructure)
- rust-lang/rust#140920 (Extract some shared code from codegen backend target feature handling)
- rust-lang/rust#141990 (Implement send_signal for unix child processes)
- rust-lang/rust#142668 (vec_deque/fmt/vec tests: remove static mut)
- rust-lang/rust#142687 (Reduce uses of `hir_crate`.)
- rust-lang/rust#142699 (Update books)
- rust-lang/rust#142714 (add comment to `src/bootstrap/build.rs`)
- rust-lang/rust#142753 (Update library dependencies)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add `fn parent(self, db) -> GenericDef` to `hir::TypeParam`
|
|
|
|
add comment to `src/bootstrap/build.rs`
I attempted to remove this build script but it's apparently needed. Add a comment for why.
|
|
Update books
## rust-lang/book
1 commits in 4433c9f0cad8460bee05ede040587f8a1fa3f1de..8a6d44e45b7b564eeb6bae30507e1fbac439d72d
2025-06-18 17:06:36 UTC to 2025-06-18 17:06:36 UTC
- Chapter 12 from tech review (rust-lang/book#4410)
## rust-lang/reference
6 commits in d4c66b346f4b72d29e70390a3fa3ea7d4e064db1..50fc1628f36563958399123829c73755fa7a8421
2025-06-19 02:02:39 UTC to 2025-06-17 21:18:46 UTC
- Document inferred const args (`feature(generic_arg_infer)`) (rust-lang/reference#1835)
- const_eval: we allow references to statics and promoteds (rust-lang/reference#1858)
- Fix missing rule on destructors (rust-lang/reference#1861)
- Fix inconsistent heading depth (rust-lang/reference#1860)
- Fix recursive root-accessible grammar check (rust-lang/reference#1852)
- Fix grammar links (rust-lang/reference#1851)
## rust-lang/rust-by-example
1 commits in 9baa9e863116cb9524a177d5a5c475baac18928a..05c7d8bae65f23a1837430c5a19be129d414f5ec
2025-06-18 13:15:17 UTC to 2025-06-18 13:15:17 UTC
- Revert "introduce new ````@media```` query to set a higher content width on ultra wide screens" (rust-lang/rust-by-example#1939)
|
|
Reduce uses of `hir_crate`.
I tried rebasing my old incremental-HIR branch. This is a by-product, which is required if we want to get rid of `hir_crate` entirely.
The second commit is a drive-by cleanup. It can be pulled into its own PR.
r? ````@oli-obk````
|
|
r=nnethercote,WaffleLapkin
Extract some shared code from codegen backend target feature handling
There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`.
The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features` does not? The second commit also cleans up a bunch of unneeded complexity added in https://github.com/rust-lang/rust/pull/135927.
The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes:
- Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes rust-lang/rust#134792.
- The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that...
- Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway.
The fourth commit increases consistency of the GCC backend with the LLVM backend.
The last commit does some further cleanup:
- Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes https://github.com/rust-lang/rust/issues/142412.
- Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this).
- Move fixed_x18 handling together with retpoline handling.
- Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag.
``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :)
Cc ``@workingjubilee``
|
|
rewrite `optimize` attribute to use new attribute parsing infrastructure
r? ```@oli-obk```
I'm afraid we'll get quite a few of these PRs in the future. If we get a lot of trivial changes I'll start merging multiple into one PR. They should be easy to review :)
Waiting on #138165 first
|
|
Use jemalloc for Clippy
The tool macros are annoying, we should IMO just get rid of them, create separate steps for each tool and (re)use some builders in them to share the build code.
r? `@ghost`
|
|
|
|
|
|
|
|
"{{root}}" is an internal-only name, and cannot appear in Rust code
being formatted.
|
|
- `Ident::from_str_and_span` -> `Ident::new` when the string is
pre-interned.
- `Ident::from_str` -> `Ident::with_dummy_span` when the string is
pre-interned.
- `_d` and `_e` are unused.
|
|
isolated_alloc: directly use mmap for allocations
|
|
Add --color=always to test explorer command
|
|
|
|
We only called it it one place, which isn't generic and can be replaced
with a field access.
|
|
Allow storing `format_args!()` in variable
Fixes https://github.com/rust-lang/rust/issues/92698
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
Tracking issue for format_args: https://github.com/rust-lang/rust/issues/99012
This change allows:
```rust
let name = "world";
let f = format_args!("hello {name}!"); // New: Store format_args!() for later!
println!("{f}");
```
This will need an FCP.
This implementation makes use of `super let`, which is unstable and might not exist in the future in its current form. However, it is entirely reasonable to assume future Rust will always have _a_ way of expressing temporary lifetimes like this, since the (stable) `pin!()` macro needs this too. (This was also the motivation for merging https://github.com/rust-lang/rust/pull/139114.)
(This is a second version of https://github.com/rust-lang/rust/pull/139135)
|
|
|
|
|
|
|
|
|
|
|
|
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
Update src/alloc/isolated_alloc.rs
Co-authored-by: Ralf Jung <post@ralfj.de>
address review
Apply suggestions from code review
Co-authored-by: Ralf Jung <post@ralfj.de>
fix comment
fix position thing
dumb mistake
Apply suggestions from code review
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
it should not suggest just `#[align]`
|
|
ci: split x86_64-gnu-tools job
try-job: x86_64-gnu-tools
try-job: x86_64-gnu-miri
try-job: aarch64-gnu
|
|
|
|
|
|
|
|
|
|
Allow building Miri with --features from miri-script
|
|
This updates the rustc book to clearly document how conflicting lint configurations are resolved across different sources, including command-line flags, crate-level attributes, in-line attributes, and `--cap-lints`.
It also explains the special behavior of `forbid` and `force_warn`.
|
|
Otherwise there was no way to pass e.g. `--features tracing` just to the `cargo` commands issued on the root repository:
CARGO_EXTRA_FLAGS applies the flags to the "cargo-miri" crate, too, which does not make sense for crate-specific features.
Fix install_to_sysroot doing path concatenation twice. Since the second concatenation was against an absolute path, it didn't do anything. This also makes the interface of install_to_sysroot() similar to that of cargo_cmd().
Implement --features for clippy, also fix not passing features to one of the cargo invocations for test
|
|
fix: Temporarily disable `+` typing handler as it moves the cursor position
|
|
|
|
Enable automatic cross-compilation in run-make tests
Supersedes rust-lang/rust#138066.
Blocker for rust-lang/rust#141856.
Based on rust-lang/rust#138066 plus `rustdoc()` cross-compile changes.
### Summary
This PR automatically specifies `--target` to `rustc()` and `rustdoc()` to have `rustc`/`rustdoc` produce cross-compiled artifacts in run-make tests by default, unless:
- `//@ ignore-cross-compile` is used, or
- `bare_{rustc,rustdoc}` are used, or
- Explicit `.target()` is specified, which overrides the default cross-compile target.
Some tests are necessarily modified:
- Tests that have `.target(target())` have that incantation removed (since this is now automatically the default).
- Some tests have `//@ needs-target-std`, but are a necessary-but-insufficient condition, and are changed to `//@ ignore-cross-compile` instead as host-only tests.
- A few tests received `//@ ignore-musl` that fail against `x86_64-unknown-linux-musl` because of inability to find `-lunwind`. AFAICT, they don't *need* to test cross-compiled artifacts.
- Some tests are constrained to host-only for now, because the effort to make them pass on cross-compile does not seem worth the complexity, and it's not really *meaningfully* improving test coverage.
try-job: dist-various-1
|
|
Revert "Turn `BlockId` into a `#[salsa::tracked]`"
|
|
This reverts commit 8643a858dbaf12b37e90b603cdee64434576c229.
|
|
|
|
|
|
|
|
|
|
|
|
fix: Closure capturing for let exprs
|
