| Age | Commit message (Collapse) | Author | Lines |
|
In `configure.py`, using the `o` function creates an enable/disable
boolean setting, and writes `true` or `false` in `config.toml`. However,
rustbuild is expecting to parse a `u32` debuginfo level. We can change
to the `v` function to have the options require a value.
|
|
|
|
Add `--pass $mode` to compiletest through `./x.py`
Adds a flag `--pass $mode` to compiletest, which is exposed through `./x.py`.
When `--pass $mode` is passed, `{check,build,compile,run}-pass` tests will be forced to run under the given `$mode` unless the directive `// ignore-pass` exists in the test file.
The modes are explained in https://github.com/rust-lang/rust/pull/61778:
- `check` has the same effect as `cargo check`
- `build` or `compile` have the same effect as `cargo build`
- `run` has the same effect as `cargo run`
On my machine, `./x.py -i test src/test/run-pass --stage 1 --pass check` takes 38 seconds whereas it takes 2 min 7 seconds without `--pass check`.
cc https://github.com/rust-lang/rust/issues/61712
r? @petrochenkov
|
|
rustbuild: detect cxx for all targets
Replaces #61544
Fixes #59917
We need CXX to build llvm-libunwind which can be enabled for alltargets.
As we needed it for all hosts anyways, just move the detection so that it is ran for all targets (which contains all hosts) instead.
|
|
Even if it's not in hosts
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
|
|
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
|
|
Make use of `ptr::null(_mut)` instead of casting zero
There are few places that I don't replace the zero casting pointer with `ptr::null`
or `ptr::null_mut`:
```bash
% git grep -E '[ ([{]0 as \*'
src/libcore/ptr/mod.rs:216:pub const fn null<T>() -> *const T { 0 as *const T }
src/libcore/ptr/mod.rs:231:pub const fn null_mut<T>() -> *mut T { 0 as *mut T }
src/test/run-pass/consts/const-cast-ptr-int.rs:12:static a: TestStruct = TestStruct{x: 0 as *const u8};
src/test/ui/issues/issue-45730.rs:5: let x: *const _ = 0 as *const _; //~ ERROR cannot cast
src/test/ui/issues/issue-45730.rs:8: let x = 0 as *const i32 as *const _ as *mut _; //~ ERROR cannot cast
src/test/ui/issues/issue-45730.stderr:14:LL | let x: *const _ = 0 as *const _;
src/test/ui/issues/issue-45730.stderr:24:LL | let x = 0 as *const i32 as *const _ as *mut _;
src/test/ui/lint/lint-forbid-internal-unsafe.rs:15: println!("{}", evil!(*(0 as *const u8)));
src/test/ui/order-dependent-cast-inference.rs:5: let mut y = 0 as *const _;
src/test/ui/order-dependent-cast-inference.stderr:4:LL | let mut y = 0 as *const _;
```
r? @sfackler
|
|
|
|
Add a RUSTC_TIME env var to time rust crates during bootstrap
Blocked on https://github.com/rust-lang/cargo/pull/6674
r? @michaelwoerister
Example for rustc with https://github.com/rust-lang/rust/pull/58507:
```
time: 0.460; rss: 94MB parsing
time: 0.000; rss: 94MB attributes injection
time: 0.000; rss: 94MB recursion limit
time: 0.000; rss: 94MB crate injection
time: 0.000; rss: 94MB plugin loading
time: 0.000; rss: 94MB plugin registration
time: 0.044; rss: 94MB pre ast expansion lint checks
time: 1.999; rss: 316MB expand crate
time: 0.000; rss: 316MB check unused macros
time: 2.000; rss: 316MB expansion
time: 0.000; rss: 316MB maybe building test harness
time: 0.053; rss: 316MB AST validation
time: 0.000; rss: 316MB maybe creating a macro crate
time: 1.515; rss: 397MB name resolution
time: 0.122; rss: 397MB complete gated feature checking
time: 0.655; rss: 546MB lowering ast -> hir
time: 0.136; rss: 550MB early lint checks
time: 0.117; rss: 540MB validate hir map
time: 0.606; rss: 540MB indexing hir
time: 0.000; rss: 480MB load query result cache
time: 0.000; rss: 478MB dep graph tcx init
time: 0.000; rss: 478MB looking for entry point
time: 0.001; rss: 478MB looking for plugin registrar
time: 0.001; rss: 478MB looking for derive registrar
time: 0.049; rss: 478MB loop checking
time: 0.064; rss: 479MB attribute checking
time: 0.166; rss: 484MB stability checking
time: 0.699; rss: 566MB type collecting
time: 0.006; rss: 566MB outlives testing
time: 0.018; rss: 568MB impl wf inference
time: 0.002; rss: 583MB unsafety checking
time: 0.005; rss: 583MB orphan checking
time: 0.227; rss: 583MB coherence checking
time: 0.006; rss: 583MB variance testing
time: 1.546; rss: 657MB wf checking
time: 0.389; rss: 665MB item-types checking
time: 13.999; rss: 837MB item-bodies checking
time: 1.692; rss: 883MB rvalue promotion
time: 0.067; rss: 883MB intrinsic checking
time: 0.624; rss: 887MB match checking
time: 0.246; rss: 889MB liveness checking
time: 2.629; rss: 889MB misc checking
time: 0.000; rss: 889MB borrow checking
time: 16.754; rss: 1242MB MIR borrow checking
time: 0.050; rss: 1242MB dumping chalk-like clauses
time: 0.010; rss: 1242MB MIR effect checking
time: 0.001; rss: 1242MB layout testing
time: 0.829; rss: 1244MB privacy checking
time: 0.183; rss: 1247MB death checking
time: 0.100; rss: 1248MB unused lib feature checking
time: 0.405; rss: 1250MB lint checking
time: 1.518; rss: 1250MB misc checking
time: 0.000; rss: 1250MB resolving dependency formats
time: 2.928; rss: 1332MB write metadata
time: 0.014; rss: 1332MB collecting roots
time: 7.621; rss: 1488MB collecting mono items
time: 7.635; rss: 1488MB monomorphization collection
time: 0.557; rss: 1567MB codegen unit partitioning
time: 27.971; rss: 2656MB codegen to LLVM IR
time: 0.056; rss: 2656MB assert dep graph
time: 0.000; rss: 2656MB serialize dep graph
time: 195.414; rss: 2656MB codegen
time: 0.000; rss: 329MB serialize work products
time: 1.664; rss: 331MB running linker
time: 1.965; rss: 331MB linking
[RUSTC-TIMING] rustc test:false 950.103
```
It doesn't really look like the times add up here.
|
|
|
|
rustbuild: include llvm-libunwind in dist tarball
Without this we cannot build with llvm-libunwind enabled from a release tarball.
Could it be backported in a beta rollup somehow so that this gets fixed before 1.36 is released?
|
|
Pass LLVM linker flags to librustc_llvm build
Some -L and -l flags may be needed even when building librustc_llvm,
for example when using static libc++ on Linux we may need to manually
specify the library search path and -ldl -lpthread as additional link
dependencies. We pass LLVM linker flags from config to librustc_llvm
build to make sure these cases are handled.
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
|
|
|
|
Removing the tool argument in the previous commit means it's no longer
restricted to just bootstrap tools despite being written as such.
Inlining it prevents accidental use.
|
|
|
|
There's no need to have it given it merely forwarded to RustbookSrc.
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
rustbuild: fix libtest_stamp
Looks like an obvious copy/paste typo
|
|
Fix x.py install
Make sure we look for save analysis in the right place. Fixes #61703.
r? @Mark-Simulacrum
cc @petrhosek @cramertj
|
|
|
|
Replaces #61544
Fixes #59917
We need CXX to build llvm-libunwind which can be enabled for all
targets.
As we needed it for all hosts anyways, just move the detection so that
it is ran for all targets (which contains all hosts) instead.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
Migrate rust-by-example to MdBook2
|
|
Pass cflags rather than cxxflags to LLVM as CMAKE_C_FLAGS
We mistakenly pass cxxflags from the configuration to LLVM build as
CMAKE_C_FLAGS.
|
|
Make sure we look for save analysis in the right place. Fixes #61703.
|
|
|
|
Some -L and -l flags may be needed even when building librustc_llvm,
for example when using static libc++ on Linux we may need to manually
specify the library search path and -ldl -lpthread as additional link
dependencies. We pass LLVM linker flags from config to librustc_llvm
build to make sure these cases are handled.
|
|
Use Build::read_dir instead of fs::read_dir in Build::cp_r
Build::read_dir does better error handling when the directory doesn't
exist; it actually prints the name of the directory rather than just
printing the underlying error "No such file or directory" which on
its own isn't very useful.
|
|
Build::read_dir does better error handling when the directory doesn't
exist; it actually prints the name of the directory rather than just
printing the underlying error "No such file or directory" which on
its own isn't very useful.
|
|
We mistakenly pass cxxflags from the configuration to LLVM build as
CMAKE_C_FLAGS.
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #61556 (librustc_errors: Rename AnnotateRs -> AnnotateSnippet)
- #61557 (rustbuild: Include `rustfmt` in deduplicated dependencies)
- #61571 (Escape HashMap with backticks in needs_drop docs)
- #61582 (submodules: update clippy from 20da8f45 to 71be6f62)
Failed merges:
r? @ghost
|
|
Also removes stage1, stage2 cfgs being passed to rustc to ensure that
stage1 and stage2 are only differentiated as a group (i.e., only through
not bootstrap).
|
|
Currently `rustfmt` is excluded from the "don't build dependencies
twice" check but it's currently building dependencies twice! Namely big
dependencies like `rustc-ap-syntax` are built once for rustfmt and once
for the RLS. This commit includes `rustfmt` in these checks and then
fixes the resulting feature mismatches for winapi.
|
|
Fixes #57669
|
|
|
|
|
|
|
|
ci: Attempt to skip a full rustc compile on dist*
Currently when we're preparing cross-compiled compilers it can take
quite some time because we have to build the compiler itself three
different times. The first is the normal bootstrap, the second is a
second build for the build platform, and the third is the actual target
architecture compiler. The second compiler was historically built
exclusively for procedural macros, and long ago we didn't actually need
it.
This commit tries out avoiding that second compiled compiler, meaning we
only compile rustc for the build platform only once. Some local testing
shows that this is promising, but bors is of course the ultimate test!
|
|
strip synstructure consts from compiler docs
Fixes #60150.
Unfortunately this PR depends on the use of the deprecated `--passes` flag in bootstrap to keep the `--strip-hidden` pass while still documenting private items. I've opened #60884 to track stabilization of a new flag that encapsulates this behavior.
r? @QuietMisdreavus
|
|
|
|
This extends a test in the previous commit to assert that we don't build
extra rustc compilers even when the "extended" option is set to true.
This involved some internal refactoring to have more judicious usage of
`compiler_for`, added in the previous commit, as well.
Various `dist::*` targets were refactored to be parameterized with a
`Compiler` instead of a `stage`/`host`, and then the various parameters
within the `Extended` target were tweaked to ensure that we don't ever
accidentally ask for a stage2 build compiler when we're distributing
something.
|
|
This commit furthers the previous one to ensure that we don't build an
extra stage of the compiler in CI. A test has been added to rustbuild to
ensure that this doesn't regress, and then in debugging this test it was
hunted down that the `dist::Std` target was the one erroneously pulling
in the wrong compiler.
The `dist::Std` step was updated to instead account for the "full
bootstrap" or not flag, ensuring that the correct compiler for compiling
the final standard library was used. This was another use of the
`force_use_stage1` function which was in theory supposed to be pretty
central, so existing users were all evaluated and a new function,
`Builder::compiler_for`, was introduced. All existing users of
`force_use_stage1` have been updated to use `compiler_for`, where the
semantics of `compiler_for` are similar to that of `compiler` except
that it doesn't guarantee the presence of a sysroot for the arguments
passed (as they may be modified).
Perhaps one day we can unify `compiler` and `compiler_for`, but the
usage of `Builder::compiler` is so ubiquitous it would take quite some
time to evaluate whether each one needs the sysroot or not, so it's
hoped that can be done in parallel.
|