| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
This commit disables building documentation on cross-compiled compilers, for
example ARM/MIPS/PowerPC/etc. Currently I believe we're not getting much use out
of these documentation artifacts and they often take 10-15 minutes total to
build as it requires building rustdoc/rustbook and then also generating all the
documentation, especially for the reference and the book itself.
In an effort to cut down on the amount of work that we're doing on dist CI
builders in light of recent timeouts this was some relatively low hanging fruit
to cut which in theory won't have much impact on the ecosystem in the hopes that
the documentation isn't used too heavily anyway.
While initial analysis in #48827 showed only shaving 5 minutes off local builds
the same 5 minute conclusion was drawn from #48826 which ended up having nearly
a half-hour impact on the bots. In that sense I'm hoping that we can land this
and test out what happens on CI to see how it affects timing.
Note that all tier 1 platforms, Windows, Mac, and Linux, will continue to
generate documentation.
|
|
appveyor: Move run-pass-fulldeps to extra builders
We've made headway towards splitting the test suite across two appveyor builders
and this moves one more tests suite between builders. The last [failed
build][fail] had its longest running test suite and I've moved that to the
secondary builder.
cc #48844
[fail]: https://ci.appveyor.com/project/rust-lang/rust/build/1.0.6782
|
|
We've made headway towards splitting the test suite across two appveyor builders
and this moves one more tests suite between builders. The last [failed
build][fail] had its longest running test suite and I've moved that to the
secondary builder.
cc #48844
[fail]: https://ci.appveyor.com/project/rust-lang/rust/build/1.0.6782
|
|
Allow installing rustfmt without config.extended
This assertion was preventing `./x.py install rustfmt` if attempted
without an "extended" build configuration, but it actually builds and
installs just fine.
|
|
Host compiler documentation
Fixes #29893. Rust Central Station PR: rust-lang/rust-central-station#40
r? @alexcrichton
|
|
Add a CI job for parallel rustc using x.py check
r? @alexcrichton
|
|
rustbuild: Tweak where timing information goes
This commit tweaks where timing and step information is printed out as part of
the build, ensuring that we do it as close to the location where work happens as
possible. In rustbuild various functions may perform long blocking work as
dependencies are assembled, so if we print out timing information early on we
may accidentally time more than just the step we were intending to time!
|
|
r=Mark-Simulacrum
Use the same RUSTFLAGS for building and testing `bootstrap`
This avoids recompiling the whole dependency graph twice for every `./x.py test` run.
Fixes #49215
|
|
Fixes #49215
|
|
This assertion was preventing `./x.py install rustfmt` if attempted
without an "extended" build configuration, but it actually builds and
installs just fine.
|
|
|
|
This commit is an implementation of adding custom sections to wasm artifacts in
rustc. The intention here is to expose the ability of the wasm binary format to
contain custom sections with arbitrary user-defined data. Currently neither our
version of LLVM nor LLD supports this so the implementation is currently custom
to rustc itself.
The implementation here is to attach a `#[wasm_custom_section = "foo"]`
attribute to any `const` which has a type like `[u8; N]`. Other types of
constants aren't supported yet but may be added one day! This should hopefully
be enough to get off the ground with *some* custom section support.
The current semantics are that any constant tagged with `#[wasm_custom_section]`
section will be *appended* to the corresponding section in the final output wasm
artifact (and this affects dependencies linked in as well, not just the final
crate). This means that whatever is interpreting the contents must be able to
interpret binary-concatenated sections (or each constant needs to be in its own
custom section).
To test this change the existing `run-make` test suite was moved to a
`run-make-fulldeps` folder and a new `run-make` test suite was added which
applies to all targets by default. This test suite currently only has one test
which only runs for the wasm target (using a node.js script to use `WebAssembly`
in JS to parse the wasm output).
|
|
|
|
Rollup of 23 pull requests
- Successful merges: #48374, #48596, #48759, #48939, #49029, #49069, #49093, #49109, #49117, #49140, #49158, #49188, #49189, #49209, #49211, #49216, #49225, #49231, #49234, #49242, #49244, #49105, #49038
- Failed merges:
|
