| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Cargo ignores RUSTFLAGS when building proc macro crates. However,
sometimes rustc_macro needs to have conditional compilation when there
are breaking changes to the `libproc_macro` API (see for example
tell the difference between stage 0 and stage 1.
Another alternative is to unconditionally build rustc_macros with the
master libstd instead of the beta one (i.e. use `--sysroot
stage0-sysroot`), but that led to strange and maddening errors:
```
error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5
|
90 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib
```
|
|
This bug was only visible on mac. Also, print_step_rusage is a relatively new
internal feature, that is not heavily used, and has no tests. All of these
factors contributed to how this went uncaught this long. Thanks to Josh Triplett
for pointing it out!
|
|
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`
|
|
|
|
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.)
|
|
|
|
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.)
|
|
|
|
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
[...]
```
|
|
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.
|
|
Fix issue 38686.
(update: placated tidy.)
|
|
|
|
These are quite long, usually, and in most cases not interesting. On smaller
terminals they can take up more than a full page of output, hiding the error
diagnostics emitted.
|
|
|
|
|
|
justification
|
|
|
|
exec never returns, it replaces the current process. so anything after it is
unreachable. that's not how exec_cmd() is used in the surrounding code
|
|
|
|
This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.
|
|
|
|
Add an option to use LLD to link the compiler on Windows platforms
Based on https://github.com/rust-lang/rust/pull/68609.
Using LLD is good way to improve compile times on Windows since `link.exe` is quite slow. The time for `x.py build --stage 1 src/libtest` goes from 0:12:00 to 0:08:29. Compile time for `rustc_driver` goes from 226.34s to 18.5s. `rustc_macros` goes from 28.69s to 7.7s. The size of `rustc_driver` is also reduced from 83.3 MB to 78.7 MB.
r? @Mark-Simulacrum
|
|
|
|
|
|
|
|
|
|
This logic is *super* old and can be tweaked and moved into `builder.rs`
|
|
Instead let's do this via `RUSTFLAGS` in `builder.rs`. Currently
requires a submodule update of `stdarch` to fix a problem with previous
compilers.
|
|
No longer needs to live in `rustc.rs`
|
|
No longer any need for them to live in `rustc.rs`!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cargo has a native enviroment variable for this.
|
|
|
|
No need for this to be in `rustc.rs`
|
|
This is always set, so let's just always set it elsewhere to reduce the
need for our `rustc.rs` shim.
|
|
This is already handled by `__CARGO_DEFAULT_LIB_METADATA` so there's no
need to doubly do it.
|
|
|
|
When deny-warnings is not specified or set to true, the behaviour is the same as before.
When deny-warnings is set to false, warnings are now allowed
Fixes #63911
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
|
|
Rename overflowing_{add,sub,mul} intrinsics to wrapping_{add,sub,mul}.
These confused @Gankra, and then, also me, especially since `overflowing_*` *methods* also exist, but they map to `*_with_overflow` intrinsics!
r? @oli-obk / @nikomatsakis cc @Mark-Simulacrum (on the rustbuild workaround)
|
|
Remap paths for proc-macro crates.
The remap-debuginfo config option remaps paths in most crates, but it does not apply to proc-macros, so they are still non-reproducible. This patch fixes that.
I'm not completely sure if this is the best way to do this, but to get reproducible builds we need librustc_macros to be built with --remap-path-prefix. I was previously modifying Cargo to pass that argument to all child crates, so this seems simpler and more correct.
I did not add a test since there do not seem to be any existing tests for RUSTC_DEBUGINFO_MAP.
r? @alexcrichton
|
|
|
