- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links`
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests
Otherwise, all `rustdoc::` lints would be ignored.
- Register all existing lints as removed
This unfortunately doesn't work with `register_renamed` because tool
lints have not yet been registered when rustc is running. For similar
reasons, `check_backwards_compat` doesn't work either. Call
`register_removed` directly instead.
- Fix fallout
+ Rustdoc lints for compiler/
+ Rustdoc lints for library/
Note that this does *not* suggest `rustdoc::broken_intra_doc_links` for
`rustdoc::intra_doc_link_resolution_failure`, since there was no time
when the latter was valid.
Clarify that SyncOnceCell::set blocks.
Reading the discussion of this feature, I gained the mistaken impression that neither `set` nor `get` blocked, and thus calling `get` immediately after `set` was not guaranteed to succeed. It turns out that `set` *does* block, guaranteeing that the cell contains a value once `set` returns. This change updates the documentation to state that explicitly.
Happy to adjust the wording as desired.
Apply lint restrictions from renamed lints
Previously, if you denied the old name of a renamed lint, it would warn
about using the new name, but otherwise do nothing. Now, it will behave
the same as if you'd used the new name.
Fixes https://github.com/rust-lang/rust/issues/82615.
r? `@ehuss`
Remove `ENABLE_DOWNLOAD_RUSTC` constant
`ENABLE_DOWNLOAD_RUSTC` was introduced as part of the MVP for `download-rustc` as a way not to rebuild artifacts that have already been downloaded. Unfortunately, it doesn't work very well:
- Steps are ignored by default, which makes it easy to leave out a step
that should be built. For example, the MVP forgot to enable any tests,
so it was only possible to *build* locally.
- It didn't work correctly even when it was enabled: calling
`builder.ensure()` would completely ignore the constant and rebuild the
step anyway. This has no obvious fix since `ensure()` has to return a
`Step::Output`.
Instead, this handles `download-rustc` in `impl Step for Rustc` and
`impl Step for Std`, which to my knowledge are the only build steps that
don't first go through `impl Step for Sysroot` (`Rustc` is used for
the `rustc-dev` component).
See https://github.com/rust-lang/rust/pull/79540#discussion_r563350075 and https://github.com/rust-lang/rust/issues/81930 for further context.
Here are some example runs with these changes and `download-rustc`
enabled:
```
$ x.py build src/tools/clippy
Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 1m 09s
Building stage1 tool cargo-clippy (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.11s
$ x.py test src/tools/clippy
Finished dev [unoptimized + debuginfo] target(s) in 0.09s
Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.09s
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.28s
Finished release [optimized] target(s) in 15.26s
Running build/x86_64-unknown-linux-gnu/stage1-tools/x86_64-unknown-linux-gnu/release/deps/clippy_driver-8b407b140e0aa91c
test result: ok. 592 passed; 0 failed; 3 ignored; 0 measured; 0 filtered out
$ x.py build src/tools/rustdoc
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 41.28s
Build completed successfully in 0:00:41
$ x.py test src/test/rustdoc-ui
Building stage0 tool compiletest (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.12s
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.10s
test result: ok. 105 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 8.15s
$ x.py build compiler/rustc
Finished dev [unoptimized + debuginfo] target(s) in 0.09s
Build completed successfully in 0:00:00
```
Note a few things:
- Clippy depends on stage1 rustc-dev artifacts, but rustc didn't have to
be recompiled. Instead, the artifacts were copied automatically.
- All steps are always enabled. There is no danger of forgetting a step,
since only the entrypoints have to handle `download-rustc`.
- Building the compiler (`compiler/rustc`) automatically does no work.
Helps with https://github.com/rust-lang/rust/issues/81930.
r? `@Mark-Simulacrum`
config.toml parsing error improvements
Improve error messages for musl-libdir and wasi-root keys. Previously
the parser would panic with `unwrap()`. Now it prints
Target "wasm32-wasi" does not have a "wasi-root" key
(and similar for the `musl-libdir` field, which is used in target that
use musl)
Also update comments around wasi-root field to make it clear that the
field is only valid in wasm32-wasi target and needs to be moved to a
`[target.wasm32-wasi]` section to be valid.
Fixes#82317
---
r? `@Mark-Simulacrum`
make x86_64-pc-solaris the default target for x86-64 Solaris
This change makes `x86_64-pc-solaris` the default compilation target for x86-64 Solaris/Illumos (based on [this exchange](https://github.com/rust-lang/rust/issues/68214#issuecomment-748042054) with `@varkor).`
I tried several ways of doing this (leveraging the alias support added with #61761 and improved/fixed with #80073) and found out that cross-compilation to the new one is by far the simplest way of doing this. It can be achieved by adding the following arguments: `--build x86_64-sun-solaris --host x86_64-pc-solaris --target x86_64-pc-solaris` and enabling the cross compilation with `PKG_CONFIG_ALLOW_CROSS=1` environment variable.
I also removed alias support altogether - `x86_64-pc-solaris` and `x86_64-sun-solaris` are now two separate targets. The problem with aliases is that even if rust internally knows that two are the same, other tools building with rust don't know that, resulting in build issues like the one with firefox mentioned [here](https://github.com/rust-lang/rust/issues/68214#issuecomment-746144229). I think that once the dust settles and `x86_64-pc-solaris` becomes the default, `x86_64-sun-solaris` can be removed.
If you agree with the above, I have two subsequent questions:
1. Is there a preferred way to display deprecation warnings when `x86_64-sun-solaris` is passed into the compiler as an argument? I am not sure whether target deprecation was done before.
2. Where would be the best way to document this change for those using rust on Solaris? Without the cross-compilation arguments (used once to build a new version), the build won't work. Should I add it into [RELEASES.md](https://github.com/rust-lang/rust/blob/master/RELEASES.md)?
Thanks!
Remove storage markers if they won't be used during code generation
The storage markers constitute a substantial portion of all MIR
statements. At the same time, for builds without any optimizations,
the storage markers have no further use during and after MIR
optimization phase.
If storage markers are not necessary for code generation, remove them.
Rollup of 10 pull requests
Successful merges:
- #82309 (Propagate RUSTDOCFLAGS in the environment when documenting)
- #82403 (rustbuild: print out env vars on verbose rustc invocations)
- #82507 (Rename the `tidy` binary to `rust-tidy`)
- #82531 (Add GUI tests)
- #82532 (Add `build.print_step_rusage` to config.toml)
- #82543 (fix env var name in CI)
- #82622 (Propagate `--test-args` for `x.py test src/tools/cargo`)
- #82628 (Try to clarify GlobalAlloc::realloc documentation comment.)
- #82630 (Fix a typo in the `find_anon_type` doc)
- #82643 (Add more proc-macro attribute tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Improve error messages for musl-libdir and wasi-root keys. Previously
the parser would panic with `unwrap()`. Now it prints
Target "wasm32-wasi" does not have a "wasi-root" key
(and similar for the `musl-libdir` field, which is used in target that
use musl)
Also update comments around wasi-root field to make it clear that the
field is only valid in wasm32-wasi target and needs to be moved to a
`[target.wasm32-wasi]` section to be valid.
Fixes#82317
Try to clarify GlobalAlloc::realloc documentation comment.
This PR tries to improve the documentation of [GlobalAlloc::realloc](https://doc.rust-lang.org/alloc/alloc/trait.GlobalAlloc.html#method.realloc) with two aspects:
1. Explicitly mention that `realloc` preserves the contents of the original memory block.
2. Explicitly mention which layout should be used to deallocate the reallocated block.
Add GUI tests
The start of a lot more of GUI tests! \o/
One test is to ensure that the search input can always be selected in all rustdoc "modes" (mobile, tablet mostly) whereas the second checks the shortcuts.
r? `@jyn514`
Rename the `tidy` binary to `rust-tidy`
This avoids naming collisions, particularly on Windows where the
dynamic library variable is PATH and setting it causes the in-tree
`tidy` to take precedence over the HTML tidy used by compiletest.
This doesn't change the x.py interface in any way, it still accepts `x.py test tidy` and prints error messages about `tidy`. It only changes the name of the file on disk.
Fixes https://github.com/rust-lang/rust/issues/82501.
Propagate RUSTDOCFLAGS in the environment when documenting
Previously, RUSTDOCFLAGS would get overriden when bootstrap set
`RUSTDOCFLAGS` itself. Propagate the flag manually, using the same logic
as `RUSTFLAGS`.
Fixes https://github.com/rust-lang/rust/issues/75256.
BTree: no longer define impossible casts
Casts to leaf to internal only make sense when the original has a chance of being the thing it's cast to.
r? `@Mark-Simulacrum`
BTreeMap: split up range_search into two stages
`range_search` expects the caller to pass the same root twice and starts searching a node for both bounds of a range. It's not very clear that in the early iterations, it searches twice in the same node. This PR splits that search up in an initial `find_leaf_edges_spanning_range` that postpones aliasing until the last second, and a second phase for continuing the search for the range in the each subtree independently (`find_lower_bound_edge` & `find_upper_bound_edge`), which greatly helps for use in #81075. It also moves those functions over to the search module.
r? `@Mark-Simulacrum`
Fixed support for macOS Catalyst on ARM64
When I initially added Arm64 Catalyst support in https://github.com/rust-lang/rust/pull/77484 I had access to a DTK. However, while waiting to merge the PR some other changes were merged which caused conflicts in the branch. When fixing those conflicts I had no access to the DTK anymore and didn't try out if the resulting binaries did indeed work on Apple Silicon. I finally have a M1 and I realized that some small changes were necessary to support Apple Silicon. This PR adds the required changes. I've been running binaries generated with this branch for some time now and they work without issues.
Reading the discussion of this feature, I gained the mistaken impression that neither `set` nor `get` blocked, and thus calling `get` immediately after `set` was not guaranteed to succeed. It turns out that `set` *does* block, guaranteeing that the cell contains a value once `set` returns. This change updates the documentation to state that explicitly.
Remove unnecessary `self_ty` parameter to `get_blanket_impls`
It can be calculated when necessary at the callsite, there's no need to
pass it separately.
This also renames `param_env_def_id` to `item_def_id`.
cc `@eddyb`
Add a chapter on the test harness.
There isn't really any online documentation on the test harness, so this adds a chapter to the rustc book which provides information on how the harness works and details on the command-line options.
Revert LLVM D81803 because it broke Windows 7
This submodule update reverts <https://reviews.llvm.org/D81803>.
While that change is meant to fix a real bug, [LLVM PR42623], it caused
new permission errors on Windows 7 that make it unable to build any
archives. This is probably the same root cause as [LLVM PR48378].
Fixes#81051. We'll file a new Rust issue to track the LLVM resolution.
[LLVM PR42623]: https://bugs.llvm.org/show_bug.cgi?id=42623
[LLVM PR48378]: https://bugs.llvm.org/show_bug.cgi?id=48378
Previously, if you denied the old name of a renamed lint, it would warn
about using the new name, but otherwise do nothing. Now, it will behave
the same as if you'd used the new name.
Remove the x86_64-rumprun-netbsd target
Herein we remove the target from the compiler and the code from libstd intended to support the now-defunct rumprun project.
Closes#81514
