| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Bring in some fixes for `cargo fix` notably
|
|
|
|
|
|
|
|
Previously when building the error index tool in stage 0 we would
attempt to use stage 0 libraries, but because it depends on rustdoc,
those don't exist: rustdoc is built against stage 1 libraries.
This patch aligns those two and passes the stage 1 libdir to the error
index.
|
|
|
|
|
|
|
|
Also makes sure we actually point to the local rls
|
|
Improve dependency deduplication diagnostics
r? @kennytm
this is obviously hard to test :laughing:
cc #52072
|
|
|
|
|
|
|
|
Run `cargo update` and let's see how far we can get!
|
|
This commit updates the stage0 build of tools to use the libraries of the stage0
compiler instead of the compiled libraries by the stage0 compiler. This should
enable us to avoid any stage0 hacks (like missing SIMD).
|
|
|
|
None of the tools in the list should need LLVM tools themselves as far as I can
tell; if this is incorrect, we can re-enable the tool building later.
The primary reason for doing this is that rust-central-station uses the
BuildManifest tool and building LLVM there is not cached: it takes ~1.5
hours on the 2 core machine. This commit should make nightlies and
stable releases much faster.
|
|
|
|
Conservatively only disable LLVM for rust-installer. This should shave
5 minutes from the x86_64-gnu-distcheck job by not building LLVM twice.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
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!
|
|
|
|
|
|
|
|
This reverts commit ab018c76e14b87f3c9e0b7384cc9b02d94779cd5.
This also adds the `ToolBuild::is_ext_tool` field to replace the previous
`ToolBuild::expectation` field, to indicate whether a build-failure of
certain tool is essential.
|
|
|
|
If build failed for these tools, they will be automatically skipped from
distribution, and will not fail the whole build.
Test failures are *not* ignored, nor build failure of other tools (e.g.
cargo). Therefore it should have no observable effect to the current CI
system.
This is step 1/8 of automatic management of broken tools #45861.
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
|
|
|
|
|
At stage 1 rustdoc is built at stage 0 so the error index generator should be as well.
This fixes `x.py --stage 1 doc` as rustdoc doesn't even build at stage 1.
|
|
This makes it mandatory for other steps to have to handle the potential
failure instead of failing in an odd way later down the road.
|
|
We copy built tool binaries into a dedicated directory to avoid deleting
them, stageN-tools-bin. These aren't ever cleared out by code, since
there should be no reason to do so, and we'll simply overwrite them as
necessary.
When clearing out the stageN-{std,rustc,tools} directories, make sure to
delete both Cargo directories -- per-target and build scripts. This
ensures that changing libstd doesn't cause problems due to build scripts
not being rebuilt, even though they should be.
|
|
|
