| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs)
- rust-lang/rust#142507 (use `#[align]` attribute for `fn_align`)
- rust-lang/rust#142524 (Weekly `cargo update`)
- rust-lang/rust#142606 (AsyncDrop trait without sync Drop generates an error)
- rust-lang/rust#142639 (Add a missing colon at the end of the panic location details in location-detail-unwrap-multiline.rs)
- rust-lang/rust#142654 (library: Increase timeout on mpmc test to reduce flakes)
- rust-lang/rust#142692 (Assorted bootstrap cleanups (step 3))
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
* Move `declare_clippy_lint` to it's own crate
* Move lint/group registration into the driver
* Make `dev update_lints` handle multiple lint crates
|
|
|
|
Assorted bootstrap cleanups (step 3)
I keep failing to unwrap the gordic knot of the logic of checking tools in bootstrap :confounded: So in the meantime I at least want to upstream some cleanups I did along the way.
Since some time ago, we have separate steps for Clippy, so it shouldn't ever happen again that the check steps would be invoked with `builder.kind == Clippy`.
r? `@jieyouxu`
|
|
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 31 packages to latest compatible versions
Updating adler2 v2.0.0 -> v2.0.1
Updating cfg-if v1.0.0 -> v1.0.1
Updating clap v4.5.39 -> v4.5.40
Updating clap_builder v4.5.39 -> v4.5.40
Updating clap_derive v4.5.32 -> v4.5.40
Updating clap_lex v0.7.4 -> v0.7.5
Updating getopts v0.2.21 -> v0.2.23
Updating hermit-abi v0.5.1 -> v0.5.2
Updating jiff v0.2.14 -> v0.2.15
Updating jiff-static v0.2.14 -> v0.2.15
Updating libc v0.2.172 -> v0.2.173
Updating memchr v2.7.4 -> v2.7.5
Updating minifier v0.3.5 -> v0.3.6
Updating miniz_oxide v0.8.8 -> v0.8.9
Updating object v0.37.0 -> v0.37.1
Updating redox_syscall v0.5.12 -> v0.5.13
Updating rustc-demangle v0.1.24 -> v0.1.25
Updating syn v2.0.101 -> v2.0.103
Updating thread_local v1.1.8 -> v1.1.9
Updating unicode-width v0.2.0 -> v0.2.1
Updating wasi v0.11.0+wasi-snapshot-preview1 -> v0.11.1+wasi-snapshot-preview1
Updating wasm-encoder v0.233.0 -> v0.235.0
Removing wasmparser v0.232.0
Removing wasmparser v0.233.0
Adding wasmparser v0.234.0
Adding wasmparser v0.235.0
Updating wast v233.0.0 -> v235.0.0
Updating wat v1.233.0 -> v1.235.0
Updating windows v0.61.1 -> v0.61.3
Updating windows-link v0.1.1 -> v0.1.3
Adding windows-sys v0.60.2
Updating windows-targets v0.53.0 -> v0.53.2
Updating winnow v0.7.10 -> v0.7.11
note: pass `--verbose` to see 39 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating libc v0.2.172 -> v0.2.173
note: pass `--verbose` to see 4 unchanged dependencies behind latest
rustbook dependencies:
Locking 19 packages to latest compatible versions
Updating adler2 v2.0.0 -> v2.0.1
Updating cc v1.2.26 -> v1.2.27
Updating cfg-if v1.0.0 -> v1.0.1
Updating clap v4.5.39 -> v4.5.40
Updating clap_builder v4.5.39 -> v4.5.40
Updating clap_complete v4.5.52 -> v4.5.54
Updating clap_derive v4.5.32 -> v4.5.40
Updating clap_lex v0.7.4 -> v0.7.5
Updating getopts v0.2.21 -> v0.2.23
Updating jiff v0.2.14 -> v0.2.15
Updating jiff-static v0.2.14 -> v0.2.15
Updating libc v0.2.172 -> v0.2.173
Updating memchr v2.7.4 -> v2.7.5
Updating miniz_oxide v0.8.8 -> v0.8.9
Updating redox_syscall v0.5.12 -> v0.5.13
Updating syn v2.0.101 -> v2.0.103
Removing unicode-width v0.1.14
Removing unicode-width v0.2.0
Adding unicode-width v0.2.1
Updating windows-link v0.1.1 -> v0.1.3
Updating winnow v0.7.10 -> v0.7.11
```
|
|
use `#[align]` attribute for `fn_align`
Tracking issue: https://github.com/rust-lang/rust/issues/82232
https://github.com/rust-lang/rfcs/pull/3806 decides to add the `#[align]` attribute for alignment of various items. Right now it's used for functions with `fn_align`, in the future it will get more uses (statics, struct fields, etc.)
(the RFC finishes FCP today)
r? `@ghost`
|
|
{aarch64,x86_64}-pc-windows-gnullvm: build host tools
This is a temporary single-release workflow to create stage0 for these targets.
I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable.
`--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory.
https://github.com/rust-lang/compiler-team/issues/877
|
|
That was intended to be a list.
Also, the order is not relevant.
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#135656 (Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused)
- rust-lang/rust#138237 (Get rid of `EscapeDebugInner`.)
- rust-lang/rust#141614 (lint direct use of rustc_type_ir )
- rust-lang/rust#142123 (Implement initial support for timing sections (`--json=timings`))
- rust-lang/rust#142377 (Try unremapping compiler sources)
- rust-lang/rust#142674 (remove duplicate crash test)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
We should always just use `Kind::Check` for the check steps, as Clippy now has an entirely separate set of steps.
|
|
It doesn't seem to be needed, we can just use `Kind::Check` explicitly.
|
|
Try unremapping compiler sources
See [#t-compiler/help > Span pointing to wrong file location (`rustc-dev` component)](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Span.20pointing.20to.20wrong.20file.20location.20.28.60rustc-dev.60.20component.29/with/521087083).
This PR is a follow-up to rust-lang/rust#141751 regarding the compiler side.
Specifically we now take into account the `CFG_VIRTUAL_RUSTC_DEV_SOURCE_BASE_DIR` env from rust-lang/rust#141751 when trying to unremap sources from `$sysroot/lib/rustlib/rustc-src/rust` (the `rustc-dev` component install directory).
Best reviewed commit by commit.
cc ``@samueltardieu``
r? ``@jieyouxu``
|
|
Implement initial support for timing sections (`--json=timings`)
This PR implements initial support for emitting high-level compilation section timings. The idea is to provide a very lightweight way of emitting durations of various compilation sections (frontend, backend, linker, or on a more granular level macro expansion, typeck, borrowck, etc.). The ultimate goal is to stabilize this output (in some form), make Cargo pass `--json=timings` and then display this information in the HTML output of `cargo build --timings`, to make it easier to quickly profile "what takes so long" during the compilation of a Cargo project. I would personally also like if Cargo printed some of this information in the interactive `cargo build` output, but the `build --timings` use-case is the main one.
Now, this information is already available with several other sources, but I don't think that we can just use them as they are, which is why I proposed a new way of outputting this data (`--json=timings`):
- This data is available under `-Zself-profile`, but that is very expensive and forever unstable. It's just a too big of a hammer to tell us the duration it took to run the linker.
- It could also be extracted with `-Ztime-passes`. That is pretty much "for free" in terms of performance, and it can be emitted in a structured form to JSON via `-Ztime-passes-format=json`. I guess that one alternative might be to stabilize this flag in some form, but that form might just be `--json=timings`? I guess what we could do in theory is take the already emitted time passes and reuse them for `--json=timings`. Happy to hear suggestions!
I'm sending this PR mostly for a vibeck, to see if the way I implemented it is passable. There are some things to figure out:
- How do we represent the sections? Originally I wanted to output `{ section, duration }`, but then I realized that it might be more useful to actually emit `start` and `end` events. Both because it enables to see the output incrementally (in case compilation takes a long time and you read the outputs directly, or Cargo decides to show this data in `cargo build` some day in the future), and because it makes it simpler to represent hierarchy (see below). The timestamps currently emit microseconds elapsed from a predetermined point in time (~start of rustc), but otherwise they are fully opaque, and should be only ever used to calculate the duration using `end - start`. We could also precompute the duration for the user in the `end` event, but that would require doing more work in rustc, which I would ideally like to avoid :P
- Do we want to have some form of hierarchy? I think that it would be nice to show some more granular sections rather than just frontend/backend/linker (e.g. macro expansion, typeck and borrowck as a part of the frontend). But for that we would need some way of representing hierarchy. A simple way would be something like `{ parent: "frontend" }`, but I realized that with start/end timestamps we get the hierarchy "for free", only the client will need to reconstruct it from the order of start/end events (e.g. `start A`, `start B` means that `B` is a child of `A`).
- What exactly do we want to stabilize? This is probably a question for later. I think that we should definitely stabilize the format of the emitted JSON objects, and *maybe* some specific section names (but we should also make it clear that they can be missing, e.g. you don't link everytime you invoke `rustc`).
The PR be tested e.g. with `rustc +stage1 src/main.rs --json=timings --error-format=json -Zunstable-options` on a crate without dependencies (it is not easy to use `--json` with stock Cargo, because it also passes this flag to `rustc`, so this will later need Cargo integration to be usable with it).
Zulip discussions: [#t-compiler > Outputting time spent in various compiler sections](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Outputting.20time.20spent.20in.20various.20compiler.20sections/with/518850162)
MCP: https://github.com/rust-lang/compiler-team/issues/873
r? ``@nnethercote``
|
|
Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused
This hint allows the compiler to optimize its operation based on this assumption, in order to compile faster. This is a hint, and does not guarantee any particular behavior.
This option can substantially speed up compilation if applied to a large dependency where the majority of the dependency does not get used. This flag may slow down compilation in other cases.
Currently, this option makes the compiler defer as much code generation as possible from functions in the crate, until later crates invoke those functions. Functions that never get invoked will never have code generated for them. For instance, if a crate provides thousands of functions, but only a few of them will get called, this flag will result in the compiler only doing code generation for the called functions. (This uses the same mechanisms as cross-crate inlining of functions.) This does not affect `extern` functions, or functions marked as `#[inline(never)]`.
This option has already existed in nightly as `-Zcross-crate-inline-threshold=always` for some time, and has gotten testing in that form. However, this option is still unstable, to give an opportunity for wider testing in this form.
Some performance numbers, based on a crate with many dependencies having just *one* large dependency set to `-Z hint-mostly-unused` (using Cargo's `profile-rustflags` option):
A release build went from 4m07s to 2m04s.
A non-release build went from 2m26s to 1m28s.
|
|
|
|
Clarify bootstrap tools description
The existence of `stage0-bootstrap-tools` suggests the possiblity of `stage1/N-bootstrap-tools`, but that's not really a thing. Also it doesn't fit the new bootstrap model, where `stageN` essentially means that it was built with a `stageN-1` compiler (except for std).
r? ``@jieyouxu``
|
|
Skip tidy triagebot linkcheck if `triagebot.toml` doesn't exist
Since distribution tarballs won't include `triagebot.toml`.
I think it's sufficiently obvious if `triagebot.toml` gets deleted entirely in PRs.
r? Kobzol
|
|
Add `StepMetadata` to describe steps
This is used to replace the previous downcasting of executed steps, which wasn't very scalable. In addition to tests, we could also use the metadata e.g. for tracing.
r? ```@jieyouxu```
|
|
Actually take `--build` into account in bootstrap
I went back 20 *stable* versions of Rust and I couldn't find this flag actually being used. Despite some of our CI workflows actually set this flag (!).
I added destructuring of the flags to make sure that this doesn't happen again. It found one more duplicated CLI flag.
r? ```@jieyouxu```
|
|
apply clippy::or_fun_call
Applies https://rust-lang.github.io/rust-clippy/master/index.html?groups=nursery#or_fun_call to reduce needless allocs.
|
|
r=Kobzol
Add spawn APIs for BootstrapCommand to support deferred command execution
This PR adds new deferred command support in the ExecutionContext and provides APIs to spawn commands and wait for their completion. This structure enables moving away from the start_process helper functions towards a more unified and reusable command execution flow.
r? ````@Kobzol````
|
