| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Debugging information for the extended tools is currently disabled for
concerns about the size. This patch adds `--enable-debuginfo-tools` to
let one opt into having that debuginfo.
This is useful for debugging the tools in distro packages. We always
strip debuginfo into separate packages anyway, so the extra size is not
a concern in regular use.
|
|
|
|
|
|
|
|
Stop emitting color codes on TERM=dumb
These terminals generally don't support color.
Fixes #49191
cc @nikomatsakis
r? @alexcrichton
|
|
Move deny(warnings) into rustbuild
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
|
|
These terminals generally don't support color.
Fixes #49191
|
|
rustbuild: canonicalize prefix `install_sh`
Testing:
```
$ git diff
diff --git a/config.toml.example b/config.toml.example
index 9dd3002506..b47bc490cd 100644
--- a/config.toml.example
+++ b/config.toml.example
@@ -196,7 +196,7 @@
[install]
# Instead of installing to /usr/local, install to this path instead.
-#prefix = "/usr/local"
+prefix = "install-prefix"
# Where to install system configuration files
# If this is a relative path, it will get installed in `prefix` above
$ mkdir install-prefix
$ ./x.py install -i --stage 0 --config config.toml.example
...
$ ls install-prefix/
bin lib share
```
Closes #36989.
r? @Mark-Simulacrum
|
|
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
Testing:
```
$ git diff
diff --git a/config.toml.example b/config.toml.example
index 9dd3002506..b47bc490cd 100644
--- a/config.toml.example
+++ b/config.toml.example
@@ -196,7 +196,7 @@
[install]
# Instead of installing to /usr/local, install to this path instead.
-#prefix = "/usr/local"
+prefix = "install-prefix"
# Where to install system configuration files
# If this is a relative path, it will get installed in `prefix` above
$ mkdir install-prefix
$ ./x.py install -i --stage 0 --config config.toml.example
...
$ ls install-prefix/
bin lib share
```
Closes #36989.
|
|
configure.py --tools should set a list instead of a string
Currently the --tools option does not work because it is setting a string value
for 'build.tools'. It should be a list of strings instead.
|
|
Don't default to stage 1 with incremental
Closes #43177.
r? @Mark-Simulacrum
|
|
rustbuild: Fix setting initial cargo
Fixes #49741
r? @Mark-Simulacrum
|
|
Currently the --tools option does not work because it is setting a string value
for 'build.tools'. It should be a list of strings instead.
|
|
Closes #43177.
|
|
|
|
Bump the bootstrap compiler to 1.26.0 beta
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
This is rarely noticed, but when you have old submodules, not updating them will cause you run into https://github.com/rust-lang/cargo/issues/4678.
|
|
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
Host compiler documentation: Include private items
Fixes #29893. Now that compiler documentation is being hosted, including private items seems sensible as these types are going to be being used by contributors working on the compiler.
However, including this means that doc comments that contain codeblocks with invalid Rust and can fail the documenting of a given crate (as evidenced by the changes in the second commit included in this PR). We'd need some way of ensuring that this cannot happen so that these failures don't cause documenting to fail. I'm unsure whether this change to documentation steps will cause this to happen already or if something new will be required.
r? @alexcrichton
|
|
add a dist builder to build rust-std components for the THUMB targets
the rust-std component only contains the core and compiler-builtins (+c +mem) crates
cc #49382
- I'm not entirely sure if this PR alone will produce rust-std components installable by rustup or if something else needs to be changed
- I could have done the THUMB builds in an existing builder / image; I wasn't sure if that was a good idea so I added a new image
- I could build other crates like alloc into the rust-std component but, AFAICT, that would require calling Cargo a second time (one for alloc and one for compiler-builtins), or have alloc depend on compiler-builtins (#49503 will perform that change) *and* have alloc resurface the "c" and "mem" Cargo features.
r? @alexcrichton
|
|
|
|
This reverts commit 14768f9b636ef345320ded41da5e9f3da7af3a81.
|
|
the goal is to build, in a single Cargo invocation, several no-std crates that we want to put in the
rust-std component of no-std targets. The nostd crate builds these crates:
- core
- compiler-builtin (with the "c" and "mem" features enabled)
- alloc
- std_unicode
|
|
|
|
This is too likely to cause spurious bounces on CI; what we run may be
dependent on what ran successfully before hand (e.g. RLS features with
Clippy), which makes this not tenable. There's no good way to ignore
specifically these problematic steps so we'll just ignore everything for
the time being. We still test that a dry run worked though so largely
this is the same from a ensure-that-tests-work perspective.
Eventually we'll want to undo this commit, though, to make our tests
more accurate.
|
|
|
|
|
|
This ensures that each build will support the testing design of "dry
running" builds. It's also checked that a dry run build is equivalent
step-wise to a "wet" run build; the graphs we generate when running are
directly compared node/node and edge/edge, both for order and contents.
|
|
|
|
|
|
In order to run tests, previous commits have cfg'd out various parts of
rustbuild. Generally speaking, these are filesystem-related operations
and process-spawning related parts. Then, rustbuild is run "as normal"
and the various steps that where run are retrieved from the cache and
checked against the expected results.
Note that this means that the current implementation primarily tests
"what" we build, but doesn't actually test that what we build *will*
build. In other words, it doesn't do any form of dependency verification
for any crate. This is possible to implement, but is considered future
work.
This implementation strives to cfg out as little code as possible; it
also does not currently test anywhere near all of rustbuild. The current
tests are also not checked for "correctness," rather, they simply
represent what we do as of this commit, which may be wrong.
Test cases are drawn from the old implementation of rustbuild, though
the expected results may vary.
|
|
Will permit creating Config in tests without having to parse a toml
file.
|
|
Ensures that test cases will be somewhat easier to write.
|
|
|
|
|
|
|
|
This ensures that the working directory of rustbuild has no effect on
it's run; since tests will run with a different cwd this is required for
consistent behavior.
|
|
|
|
Also update some `Cargo.lock` dependencies, finishing up some final steps of our
[release process]!
This doesn't update the bootstrap compiler just yet but that will come in a
follow-up PR.
[release process]: https://forge.rust-lang.org/release-process.html
|
|
the rust-std component only contains the core and compiler-builtins (+c +mem) crates
cc #49382
|
|
Remove filetime dep from build_helper
r? @alexcrichton
|
|
|
|
Only include space in RUSTFLAGS extra flags if not empty
When the RUSTFLAGS_STAGE_{1,2} is not set, including a space means
the string will always be non-empty and RUSTFLAGS will be always be
reset which breaks other ways of setting these such as through config
in CARGO_HOME.
|
|
When the RUSTFLAGS_STAGE_{1,2} is not set, including a space means
the string will always be non-empty and RUSTFLAGS will be always be
reset which breaks other ways of setting these such as through config
in CARGO_HOME.
|
|
This option was introduced in 72cb109bec8, but it uses two different
spellings (fast-submodule vs fast-submodules) and isn't handled by
Rust bootstrap which means that any attempt to set this flag fails.
|
|
If the compiler docs aren't going to include the test crate then it may as well be included with std.
|
|
This fixes building the compiler docs because stage1-rustc\x86_64-pc-windows-msvc\doc is used twice which
doesn't work if we still have a handle from the first time.
|
|
This commit updates the `ToolBuild` step to stream Cargo's JSON messages, parse
them, and record all libraries built. If we build anything twice (aka Cargo)
it'll most likely happen due to dependencies being recompiled which is caught by
this check.
|
