| Age | Commit message (Collapse) | Author | Lines |
|---|
|
miri std tests: skip all of sys::
Matches https://github.com/rust-lang/miri-test-libstd/pull/104
|
|
Fix `bump-stage0` build failure, and check-build `bump-stage0` in CI
This PR bumps the `toml` dependency of the `bump-stage0` tool to `0.8.23`, which AFAICT is the highest `toml` version that's present in the r-l/r workspace's `Cargo.lock` already (so we don't introduce _another_ `toml 0.x.*` series). I added some byte-buffer-to-string intermediary to workaround `toml 0.8.*` not having the `toml 0.9.*` `toml::from_slice` API.
To catch obvious build failures of the `src/tools/bump-stage0` tool early, before we find out it can't even build when we really need it to work.
Contexts:
- https://github.com/rust-lang/rust/pull/146250#issue-3388327410
- [#t-release > Bump stage0 rustfmt separately ("one-off") @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release/topic/Bump.20stage0.20rustfmt.20separately.20.28.22one-off.22.29/near/537916615)
Fixes rust-lang/rust#146252.
|
|
|
|
To catch obvious build failures of the `src/tools/bump-stage0` early,
before we find out it can't even build when we really need it to work.
|
|
|
|
- We pick the higest common `toml` version used in the r-l/r workspace
to avoid introducing Yet Another `toml` `0.x` version, which happens
to be `0.8.23` as of the time of writing.
- We introduce a byte-buffer-to-string workaround for the `toml 0.8.*`
series that do not have the `toml 0.9.*` series's `toml::from_slice`
API yet. Not efficient, but this is not perf-critical so it's fine.
|
|
Optimize Cargo with LTO
This optimization was "lost" when Cargo was switched away from a `ToolRustcPrivate` to a `ToolTarget` tool.
r? `@jieyouxu`
|
|
|
|
|
|
https://blog.zulip.com/2024/07/25/zulip-9-0-released
|
|
Document Cargo with in-tree rustdoc
Fixes https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/nightly.20rust.20doc.20seem.20corrupted.
r? `@jieyouxu`
try-job: dist-x86_64-linux-alt
|
|
Bump stage0 rustfmt
Unblocks rust-lang/rust#146071, cc `@npmccallum.`
Steps to reproduce:
1. Temporarily upgrade `src/tools/bump-stage0`'s `toml` dependency from 0.7 to 0.9 to fix build error (see Zulip topic)
2. Execute `./x run src/tools/bump-stage0`
3. Manually revert changes unrelated to nightly `rustfmt`+`rustc` (the latter needs to be bumped, too, for the driver ([via](https://github.com/rust-lang/rust/pull/146250#discussion_r2325742775)))
r? `@Mark-Simulacrum` as discussed in [#t-release > Bump stage0 rustfmt separately ("one-off")](https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release/topic/Bump.20stage0.20rustfmt.20separately.20.28.22one-off.22.29/with/537916615)
|
|
change file-is-generated doc comment to inner
Alternatively this could perhaps be better as a normal comment...
|
|
tidy: --bless now makes escheck run with --fix
this mirrors how other extra-check tools work.
unsure if this also needs to be done for tsc and es-check.
|
|
r=joshtriplett
style-guide: Document absence of trailing whitespace
We didn't previously have a blanket prohibition on trailing whitespace. Adding
one, inspired by discussion in https://github.com/rust-lang/rust/pull/145617 .
|
|
r=rcvalle
unstable book: in a sanitizer example, check the code
Use some `#` directives to make sure the code checks on x86_64, and does not produce errors on other platforms. This example still used an older version of `#[naked]`, and because the snippet was ignored that was missed before.
I'm not sure when this gets built on CI exactly, so it might be worthwhile to try and build it for a non-x86_64 architecture to make sure that works. I'm not sure how to verify locally that e.g. on aarch64 this code works without errors/warnings.
try-job: aarch64-apple
try-job: x86_64-msvc-2
|
|
Start documenting tests/rustdoc-json
|
|
|
|
|
|
|
|
|
|
Adds Windows resources with the rust version information to rustc-main.exe and rustc_driver.dll
Sets the product description to "Rust Compiler" or "Rust Compiler (channel)" for non-stable channels
|
|
|
|
|
|
fix: Filter suggestion parts that match existing code
While testing my changes to make `rustc` use `annotate-snippets`, I encountered a new `clippy` test failure stemming from [two](https://github.com/rust-lang/rust/pull/145273/files#diff-6e8403e31463539666afbc00479cb416dc767a518f562b6e2960630953ee7da2R275-R278) [suggestion](https://github.com/rust-lang/rust/pull/145273/files#diff-6e8403e31463539666afbc00479cb416dc767a518f562b6e2960630953ee7da2R289-R292) output changes in rust-lang/rust#145273. The new output in these two cases feels like a regression as it is not as clear as the old output, and adds unnecessary information.
Before rust-lang/rust#145273 (`Diff` style)
After rust-lang/rust#145273 ("multi-line" style)
The reason for the change was that a new suggestion part (which matches existing code) was added on a different line than the existing parts, causing the suggestion style to change from `Diff` to "multi-line". Since this new part matches existing code, no code changes show up in the output for it, but it still makes the suggestion style "multi-line" when it doesn't need to be.
To get the old output back, I made it so that suggestion parts that perfectly match existing code get filtered out.
try-job: aarch64-apple
|
|
|
|
This was first renamed to `get_region_var_origins` in
https://github.com/rust-lang/rust/pull/109753, and then to
`get_region_var_infos` in
https://github.com/rust-lang/rust/commit/b0fc1d47d5dcffb5d516059d4a5af3b6843132d5
|
|
|
|
|
|
|
|
Moved into `ObligationCtxt` in https://github.com/rust-lang/rust/commit/a19adefa0e5aca0aabca2430530577ee140e4efa
|
|
|
|
|
|
For the ones that explicitly picks which test suite to run.
|
|
|
|
- `run-make` test suite will now no longer receive a `cargo`.
- NOTE: the user could technically still write
`Command::new("cargo")` which might find *a* cargo from the
environment, but that is not a supported case.
- `run-make-cargo` will receive a built in-tree `cargo`.
|
|
So that contributors who don't need to run `run-make` tests that require
in-tree `cargo` can run the non-cargo `run-make` tests without having to
wait for `cargo` (which would require rebuilding as the build cache
would be invalidated by compiler modifications without some kind of
`--keep-stage-cargo`).
|
|
|
|
|
|
|
|
|
|
Clippy subtree update
r? `@Manishearth`
|
|
|
|
clippy-subtree-update
|
|
rustdoc-search: yet another stringdex optimization attempt
This one's uses a different tactic. It shouldn't significantly increase the amount of downloaded index data, but still reduces the amount of disk usage.
This one works by changing the suffix-only node representation to omit some data that's needed for checking. Since those nodes make up the bulk of the tree, it reduces the data they store, but also requires validating the match by fetching the name itself (but the names list is pretty small, and when I tried it with wordnet "indexing" it was about the same).
r? `@GuillaumeGomez`
|
|
|
|
fixes auto-run js checks in tidy
Modified is_non_auto_or_matches function in src/tools/tidy/src/extra_checks/mod.rs so that .ts extension is considered.
Tested locally with
`./x.py test tidy --extra-checks=auto:js`
|
|
Add bootstrap.toml option to control debug breaking on ICEs on windows
When rustc ICEs during bootstrap on Windows, it will call `DebugBreak`. This is intended to trigger a Windows Error Reporting dialog that can launch a debugger. However on some setups (mine for one) this will just abort the process, hiding any ICEs on other threads as well. I also would not want to see this dialog even if it did work for me.
This PR adds a new option to bootstrap.toml `rust.break-on-ice` to configure this behavior. By default, it is enabled, matching the existing behavior.
|
|
|
|
Signed-off-by: Emmet Horgan <emmet.horgan@analog.com>
|
