| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix bootstrap tests on beta
Forward-porting a fix from the beta branch, which led to test failure on beta.
r? ``@pietroalbini``
|
|
|
|
|
|
When bumping the bootstrap version, the name of the generated LLVM
shared object file is changed, even though it's the same contents as
before. If bootstrap tries to use an older version, it will get linking
errors:
```
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Compiling rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" ... lots of args ...
= note: /usr/bin/ld: cannot find -lLLVM-12-rust-1.53.0-nightly
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: could not compile `rustdoc-tool`
```
|
|
Attempt to gather similar stats as rusage on Windows
A follow up to #82532. This is a bit hacked in because I think we need to discuss this before merging, but this is an attempt to gather similar metrics as `libc::rusage` on Windows.
Some comments on differences:
* Currently, we're passing `RUSAGE_CHILDREN` to `rusage` which collects statistics on all children that have been waited on and terminated. I believe this is currently just the invocation of the real `rustc` that the shim is wrapping. Does `rustc` itself spawn children processes? The windows version gets the child processes handle when spawning it, and uses that to collect the statistics. For maxrss, `rusage` will return "the resident set size of the largest child, not the maximum resident set size of the process tree.", the Windows version will only collect statistics on the wrapped `rustc` child process directly even if some theoretical sub process has a larger memory footprint.
* There might be subtle differences between `rusage`'s "resident set" and Window's "working set". The "working set" and "resident set" should both be the number of pages that are in memory and which would not cause a page fault when accessed.
* I'm not yet sure how best to get the same information that `ru_minflt`, `ru_inblock`, `ru_oublock`, `ru_nivcsw ` and `ru_nvcsw` provide.
r? `@pnkfelix`
|
|
checkout without other mods.
To be clear, by default running `x.py test` on a checkout of the beta branch
currently fails, and with this change will continue to fail, because `x.py
tests` runs `x.py test src/tools/tidy` which tries to run `rustfmt` and that
will fail because the `rustfmt` binary is pinned to the current nighlty and we
do not attempt to distribute one for the beta builds.
This change gives a better error message than the current message, which is just
"./x.py fmt is not supported on this channel" without providing any hint about
what one might do about that problem.
(update: placated tidy.)
|
|
|
|
This way, you can debug rustdoc's JavaScript and CSS file
with normal F12 Dev Tools and you'll have useful line numbers
to work with.
|
|
|
|
WASI: Switch to crt1-command.o to enable support for new-style commands
This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.
See here for more information on new-style commands:
- https://github.com/WebAssembly/wasi-libc/pull/203
- https://reviews.llvm.org/D81689
r? ```@alexcrichton```
|
|
Build rustdoc for run-make tests, not just run-make-fulldeps
Rustdoc almost never needs a full stage 2 compiler, and requiring
rustdoc tests to be in run-make-fulldeps adds a lot of compile time for
no reason.
This is the same change from https://github.com/rust-lang/rust/pull/81197, but separated into its own PR. I ran into this again today while working on https://github.com/rust-lang/docs.rs/issues/1302.
r? ```@Mark-Simulacrum```
|
|
This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.
See here for more information on new-style commands:
- https://github.com/WebAssembly/wasi-libc/pull/203
- https://reviews.llvm.org/D81689
|
|
|
|
unconditionally.
1. I added `--test` based on review feedback from simulacrum: I decided I would
rather include such extra context than get confused later on by its absence.
(However, I chose to encode it differently than how `[RUSTC-TIMING]` does... I
don't have much basis for doing so, other than `--test` to me more directly
reflects what it came from.)
2. I also decided to include `[RUSTC-SHIM]` at start of all of these lines
driven by the verbosity level, to make to clear where these lines of text
originate from. (Basically, I skimmed over the output and realized that a casual
observer might not be able to tell where this huge set of new lines were coming
from.)
|
|
Rustdoc almost never needs a full stage 2 compiler, and requiring
rustdoc tests to be in run-make-fulldeps adds a lot of compile time for
no reason.
|
|
|
|
This change is mainly motivated by an issue with the environment
printing I added in PR 82403: multiple rustc invocations progress
in parallel, and the environment output, spanning multiple lines,
gets interleaved in ways make it difficult to extra the enviroment settings.
(This aforementioned difficulty is more of a hiccup than an outright
show-stopper, because the environment variables tend to be the same for all of
the rustc invocations, so it doesn't matter too much if one mixes up which lines
one is looking at. But still: Better to fix it.)
|
|
Upgrade to LLVM 12
This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far.
r? `@cuviper`
|
|
Fix commit detected when using `download-rustc`
On reflection on the issue in https://github.com/rust-lang/rust/pull/79540#discussion_r572572280, I think the bug was actually using the `compiler/` filter, not using `--author=bors`. https://github.com/rust-lang/rust/commit/9a1d6174c925f54c923599e29b09d6855e6b3a78 has no CI artifacts because it was merged as part of a rollup:
```
$ curl -I https://ci-artifacts.rust-lang.org/rustc-builds/96e843ce6ae42e0aa519ba45e148269de347fd84/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz
HTTP/2 404
```
So 9a1d6174c925f54c923599e29b09d6855e6b3a78 is the correct commit to download, and that's what `--author=bors` does:
$ git log --author=bors 4aec8a5da5547d6e1c24e99dad0003b7cac107f5
commit 9a1d6174c925f54c923599e29b09d6855e6b3a78
Ideally it would look for "the most recent bors commit not followed by a change to `compiler/`", which would exclude things like documentation changes and avoid redownloading more than necessary, but
- Redownloading isn't the end of the world,
- That metric is hard to implement, and
- Documentation-only or library-only changes are very rare anyway since they're usually rolled up with changes to the compiler.
Helps with https://github.com/rust-lang/rust/issues/81930.
r? `@Mark-Simulacrum`
|
|
|
|
On reflection on the issue in https://github.com/rust-lang/rust/pull/79540#discussion_r572572280, I think the bug was actually using the `compiler/` filter, not using `--author=bors`. https://github.com/rust-lang/rust/commit/9a1d6174c925f54c923599e29b09d6855e6b3a78 has no CI artifacts because it was merged as part of a rollup:
```
$ curl -I https://ci-artifacts.rust-lang.org/rustc-builds/96e843ce6ae42e0aa519ba45e148269de347fd84/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz
HTTP/2 404
```
So 9a1d6174c925f54c923599e29b09d6855e6b3a78 is the correct commit to download, and that's what `--author=bors` does:
$ git log --author=bors 4aec8a5da5547d6e1c24e99dad0003b7cac107f5
commit 9a1d6174c925f54c923599e29b09d6855e6b3a78
Ideally it would look for "the most recent bors commit not followed by a change to `compiler/`", which would exclude things like documentation changes and avoid redownloading more than necessary, but
- Redownloading isn't the end of the world,
- That metric is hard to implement, and
- Documentation-only or library-only changes are very rare anyway since they're usually rolled up with changes to the compiler.
|
|
- 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.
|
|
When cross-compiling to solaris/illumos targets, set
CMAKE_SYSTEM_NAME to SunOS.
|
|
Rollup of 8 pull requests
Successful merges:
- #81210 (BTreeMap: correct node size test case for choices of B)
- #82360 (config.toml parsing error improvements)
- #82428 (Update mdbook)
- #82480 (Remove `ENABLE_DOWNLOAD_RUSTC` constant)
- #82578 (Add some diagnostic items for Clippy)
- #82620 (Apply lint restrictions from renamed lints)
- #82635 (Fix typos in rustc_infer::infer::nll_relate)
- #82645 (Clarify that SyncOnceCell::set blocks.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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`
|
|
|
|
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
|
|
Propagate `--test-args` for `x.py test src/tools/cargo`
Fixes https://github.com/rust-lang/rust/issues/82621.
|
|
Add `build.print_step_rusage` to config.toml
Adds `build.print_step_rusage` to config.toml, which is meant to be an easy way to let compiler developers get feedback on the terminal during bootstrap about resource usage during each step.
The output is piggy-backed on `[PRINT-STEP-TIMINGS]`, mostly because the functionality seemed to naturally fit there in the overall control-flow and output structure (even if very little is shared between the implementations themselves).
Some sample output (from my Linux box, where I believe the `max rss` output to be somewhat trust-worthy...):
```
[...]
Compiling regex v1.4.3
[RUSTC-TIMING] tempfile test:false 0.323 user: 1.418662 sys: 0.81767 max rss (kb): 182084 page reclaims: 26615 page faults: 0 fs block inputs: 0 fs block outputs: 2160 voluntary ctxt switches: 798 involuntary ctxt switches: 131
Completed tempfile v3.1.0 in 0.3s
[RUSTC-TIMING] chalk_ir test:false 1.890 user: 1.893603 sys: 0.99663 max rss (kb): 239432 page reclaims: 32107 page faults: 0 fs block inputs: 0 fs block outputs: 25008 voluntary ctxt switches: 108 involuntary ctxt switches: 183
Completed chalk-ir v0.55.0 in 1.9s
Compiling rustc_data_structures v0.0.0 (/home/pnkfelix/Dev/Rust/rust.git/compiler/rustc_data_structures)
[RUSTC-TIMING] chrono test:false 1.244 user: 3.333198 sys: 0.134963 max rss (kb): 246612 page reclaims: 44857 page faults: 0 fs block inputs: 0 fs block outputs: 11704 voluntary ctxt switches: 1043 involuntary ctxt switches: 326
Completed chrono v0.4.15 in 1.3s
[RUSTC-TIMING] rustc_rayon test:false 1.332 user: 1.763912 sys: 0.75996 max rss (kb): 239076 page reclaims: 35285 page faults: 0 fs block inputs: 0 fs block outputs: 19576 voluntary ctxt switches: 359 involuntary ctxt switches: 168
Completed rustc-rayon v0.3.0 in 1.3s
Compiling matchers v0.0.1
[RUSTC-TIMING] matchers test:false 0.100 user: 0.94495 sys: 0.15119 max rss (kb): 140076 page reclaims: 8200 page faults: 0 fs block inputs: 0 fs block outputs: 392 voluntary ctxt switches: 43 involuntary ctxt switches: 12
Completed matchers v0.0.1 in 0.1s
[...]
```
|
|
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.
|
|
pnkfelix:rustbuild-emit-env-vars-on-verbose-verbose, r=Mark-Simulacrum
rustbuild: print out env vars on verbose rustc invocations
Print out environment variables related to Rust on sufficiently verbose rustc invocations.
Output is filtered via heuristic of only printing environment variables whose keys start with "RUST" or "CARGO." This filtering is mostly motivated by my not caring to see e.g. "PATH" in my own output, though it is also motivated as a way to try to avoid printing out personal secrets like github keys that people might have stored in their environments for better or for worse, especially since build output is often pasted into bug reports or gists.
Fix #38686.
<details>
<summary>Click here to see sample output</summary>
Sample output looks like:
```
...
Fresh core v0.0.0 (/home/pnkfelix/Dev/Rust/rust.git/library/core)
rustc env[0]: "CARGO"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/cargo"
rustc env[1]: "CARGO_CRATE_NAME"="core"
rustc env[2]: "CARGO_INCREMENTAL"="0"
rustc env[3]: "CARGO_MAKEFLAGS"="--jobserver-fds=5,6 -j --jobserver-auth=5,6 -j"
rustc env[4]: "CARGO_MANIFEST_DIR"="/home/pnkfelix/Dev/Rust/rust.git/library/core"
rustc env[5]: "CARGO_PKG_AUTHORS"="The Rust Project Developers"
rustc env[6]: "CARGO_PKG_DESCRIPTION"=""
rustc env[7]: "CARGO_PKG_HOMEPAGE"=""
rustc env[8]: "CARGO_PKG_LICENSE"=""
rustc env[9]: "CARGO_PKG_LICENSE_FILE"=""
rustc env[10]: "CARGO_PKG_NAME"="core"
rustc env[11]: "CARGO_PKG_REPOSITORY"=""
rustc env[12]: "CARGO_PKG_VERSION"="0.0.0"
rustc env[13]: "CARGO_PKG_VERSION_MAJOR"="0"
rustc env[14]: "CARGO_PKG_VERSION_MINOR"="0"
rustc env[15]: "CARGO_PKG_VERSION_PATCH"="0"
rustc env[16]: "CARGO_PKG_VERSION_PRE"=""
rustc env[17]: "CARGO_PROFILE_RELEASE_CODEGEN_UNITS"="256"
rustc env[18]: "CARGO_PROFILE_RELEASE_DEBUG"="0"
rustc env[19]: "CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS"="false"
rustc env[20]: "CARGO_TARGET_DIR"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std"
rustc env[21]: "RUSTBUILD_NATIVE_DIR"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/native"
rustc env[22]: "RUSTC"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/bootstrap/debug/rustc"
rustc env[23]: "RUSTC_BOOTSTRAP"="1"
rustc env[24]: "RUSTC_BREAK_ON_ICE"="1"
rustc env[25]: "RUSTC_ERROR_METADATA_DST"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/tmp/extended-error-metadata"
rustc env[26]: "RUSTC_FORCE_UNSTABLE"="1"
rustc env[27]: "RUSTC_INSTALL_BINDIR"="bin"
rustc env[28]: "RUSTC_LIBDIR"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"
rustc env[29]: "RUSTC_LINT_FLAGS"="-Wrust_2018_idioms -Wunused_lifetimes -Dwarnings"
rustc env[30]: "RUSTC_PRINT_STEP_TIMINGS"="1"
rustc env[31]: "RUSTC_REAL"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"
rustc env[32]: "RUSTC_SNAPSHOT"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc"
rustc env[33]: "RUSTC_SNAPSHOT_LIBDIR"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib"
rustc env[34]: "RUSTC_STAGE"="0"
rustc env[35]: "RUSTC_SYSROOT"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-sysroot"
rustc env[36]: "RUSTC_VERBOSE"="2"
rustc env[37]: "RUSTDOC"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/bootstrap/debug/rustdoc"
rustc env[38]: "RUSTDOCFLAGS"="--cfg=bootstrap -Dwarnings -Winvalid_codeblock_attributes --crate-version 1.52.0-dev"
rustc env[39]: "RUSTDOC_REAL"="/path/to/nowhere/rustdoc/not/required"
rustc env[40]: "RUSTFLAGS"="--cfg=bootstrap -Zmacro-backtrace -Clink-args=-Wl,-rpath,$ORIGIN/../lib -Cprefer-dynamic"
rustc env[41]: "RUST_COMPILER_RT_ROOT"="/home/pnkfelix/Dev/Rust/rust.git/src/llvm-project/compiler-rt"
rustc env[42]: "RUST_TEST_THREADS"="128"
rustc working directory: /home/pnkfelix/Dev/Rust/rust.git
rustc command: "LD_LIBRARY_PATH"="/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib:/home/pnkfelix/Dev/Rust/rust.git/objdi\
r-default/build/x86_64-unknown-linux-gnu/stage0-std/release/deps:/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/lib" "/home\
/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--crate-name" "core" "--edition=2018" "library/core/src/lib.rs" "--er\
ror-format=json" "--json=diagnostic-rendered-ansi,artifacts" "--crate-type" "lib" "--emit=dep-info,metadata,link" "-C" "opt-level=3" "-C" "embed-bitcode=no" "-C" \
"codegen-units=256" "-C" "debuginfo=0" "-C" "metadata=6748933694d8be19" "-C" "extra-filename=-6748933694d8be19" "--out-dir" "/home/pnkfelix/Dev/Rust/rust.git/objd\
ir-default/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps" "--target" "x86_64-unknown-linux-gnu" "-L" "dependency=/home/pnkfelix/\
Dev/Rust/rust.git/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps" "-L" "dependency=/home/pnkfelix/Dev/Rust/rust.gi\
t/objdir-default/build/x86_64-unknown-linux-gnu/stage0-std/release/deps" "--cfg=bootstrap" "-Zmacro-backtrace" "-Clink-args=-Wl,-rpath,$ORIGIN/../lib" "-Cprefer-d\
ynamic" "-Z" "binary-dep-depinfo" "-Wrust_2018_idioms" "-Wunused_lifetimes" "-Dwarnings" "--sysroot" "/home/pnkfelix/Dev/Rust/rust.git/objdir-default/build/x86_64\
-unknown-linux-gnu/stage0-sysroot" "-Z" "force-unstable-if-unmarked"
...
```
|
|
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.
|
|
|
|
For some targets, rustc uses a "CRT fallback", where it links CRT
object files it ships instead of letting the host compiler link
them.
On musl, rustc currently links crt1, crti and crtn (provided by
libc), but does not link crtbegin and crtend (provided by libgcc).
In particular, crtend is responsible for terminating the .eh_frame
section. Lack of terminator may result in segfaults during
unwinding, as reported in #47551 and encountered by the LLVM 12
update in #81451.
This patch links crtbegin and crtend for musl as well, following
the table at the top of crt_objects.rs.
|
|
On non-unix platforms, does not try to call `getrusage` (and does not attempt to
implement its own shim; that could be follow-on work, though its probably best
to not invest too much effort there, versus using separate dedicated tooling).
On unix platforms, calls libc::rusage and attempts to emit the subset of fields
that are supported on Linux and Mac OS X. Omits groups of related stats which
appear to be unsupported on the platform (due to them all remaining zero).
Adjusts output to compensate for Mac using bytes instead of kb (a well known
discrepancy on Mac OS X). However, so far I observe a lot of strange values
(orders of magnitude wrong) reported on Mac OS X in some cases, so I would not
trust this in that context currently.
|
|
Intended to piggy-back on output from existing build.print_step_timings setting.
|
|
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 was introduced as part of the MVP for `download-rustc`.
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
Updating only changed submodules
Submodules updated in 0.01 seconds
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.
|
|
Update the bootstrap compiler
This updates the bootstrap compiler, notably leaving out a change to enable semicolon in macro expressions lint, because stdarch still depends on the old behavior.
|
|
Fix issue 38686.
(update: placated tidy.)
|
|
Rustdoc gui tests
This is a reopening of #70533.
For this first version, there will be no screenshot comparison. Also, a big change compared to the previous version: the tests are now hosted in the rust repository directly. Since there is no image, it's pretty lightweight to say the least.
So now, only remains the nodejs script to run the tests and the tests themselves. Just one thing is missing: where should I put the documentation for these tests? I'm not sure where would be the best place for that. The doc will contain important information like the documentation of the framework used and how to install it (`npm install browser-ui-test`, but still needs to be put somewhere so no one is lost).
We'd also need to install the package when running the CI too. For now, it runs as long as we have nodejs installed, but I think we don't it to run in all nodejs targets?
cc `@jyn514`
r? `@Mark-Simulacrum`
|
|
Previously, RUSTDOCFLAGS would get overriden when bootstrap set
`RUSTDOCFLAGS` itself. Propagate the flag manually, using the same logic
as `RUSTFLAGS`.
This also extracts the logic into a helper function to make sure it's
the same.
|
|
|
|
|
|
Do not delete bootstrap.exe on Windows during clean
Windows does not allow deleting currently running executables.
This an addition to ```@jyn514's``` change in https://github.com/rust-lang/rust/pull/80574.
|
|
parallelize x.py test tidy
Running tidy on individual commits when rewriting git history was somewhat of an annoyance, so I have parallelized it a bit.
running `time ./x.py test tidy` with warm IO caches:
old:
```
real 0m11.123s
user 0m14.495s
sys 0m5.227s
```
new:
```
real 0m1.834s
user 0m13.545s
sys 0m3.094s
```
There's further room for improvement (<0.9s should be feasible) but that would require bigger changes.
|
|
|
|
std_detect is still using this and as it's in a submodule updating it will be a
pain. We can catch this either after a stdarch submodule bump or just on the
next cycle.
|
|
Note this does not change `core::derive` since it was merged after the
beta bump.
|
