| Age | Commit message (Collapse) | Author | Lines |
|---|
|
make is_tool inherent prop of mode
fix errors from rebase
resolve issues from review
|
|
|
|
|
|
|
|
|
|
|
|
This can often encounter errors after modifying rustc, so it's useful to include it in the steps that are checked.
|
|
|
|
|
|
This deduplicates the LLVM building functionality from compile.rs and check.rs.
|
|
|
|
|
|
|
|
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 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!
|
|
For LLD integration the path to `llvm-config` needed to change to inside the
build directory itself (for whatever reason) but the build directory is
different on MSBuild than it is on `ninja` for MSVC builds, so the path to
`llvm-config.exe` was actually wrong and not working!
This commit removes the `Build::llvm_config` function in favor of the source of
truth, the `Llvm` build step itself. The build step was then updated to find the
right build directory for MSBuild as well as `ninja` for where `llvm-config.exe`
is located.
Closes #48749
|
|
Previously, a Step would be able to tell on its own when it was invoked
"by-default" (that is, `./x.py test` was called instead of `./x.py test
some/path`). This commit replaces that functionality, invoking each Step
with each of the paths it has specified as "should be invoked by."
For example, if a step calls `path("src/tools/cargo")` and
`path("src/doc/cargo")` then it's make_run will be called twice, with
"src/tools/cargo" and "src/doc/cargo." This makes it so that default
handling logic is in builder, instead of spread across various Steps.
However, this meant that some Step specifications needed to be updated,
since for example `rustdoc` can be built by `./x.py build
src/librustdoc` or `./x.py build src/tools/rustdoc`. A `PathSet`
abstraction is added that handles this: now, each Step can not only list
`path(...)` but also `paths(&[a, b, ...])` which will make it so that we
don't invoke it with each of the individual paths, instead invoking it
with the first path in the list (though this shouldn't be depended on).
Future work likely consists of implementing a better/easier way for a
given Step to work with "any" crate in-tree, especially those that want
to run tests, build, or check crates in the std, test, or rustc crate
trees. Currently this is rather painful to do as most of the logic is
duplicated across should_run and make_run. It seems likely this can be
abstracted away into builder somehow.
|
|
|
|
Building on the work of # 45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement # 46819 where rustc
will have multiple backends available to it to load.
This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).
Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.
A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.
|
|
This currently only supports a limited subset of the full compilation,
but is likely 90% of what people will want and is possible without
building a full compiler (i.e., running LLVM). In theory, this means
that contributors who don't want to build LLVM now have an easy way to
compile locally, though running tests won't work.
|
|
|
|
Add rustc-args option to test runner
r? @nikomatsakis
|
|
Don't include DefIndex in proc-macro registrar function symbol.
There can only ever be one registrar function per plugin or proc-macro crate, so adding the `DefIndex` to the function's symbol name does not serve a real purpose. Remove the `DefIndex` from the symbol name makes it stable across incremental compilation sessions.
This should fix issue #47292.
|
|
|
|
Test rustdoc js
Add tests for the rustdoc search. It was heavily required because of all the recent breaking changes that happened while I went through improvements in doc search (add search in/for generic search for example).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These no longer work now that Cargo changes the cwd of rustc while it's running.
Instead use an absolute path that's set by rustbuild.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add Rustfmt
r? @alexcrichton
|
|
Previously it would use the librustc output directory which would cause rustdoc
to get entirely recompiled, whereas the intention is that it uses the
already-compiled artifacts from building rustdoc itself, using the tool output
directory
|
|
|
|
Doc tests are temporarily disabled until next release cycle, since
current beta Cargo errors on them. Upgrade should be smooth as the
relevant tests are already fixed in this commit.
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
Cleanup for "Support compiling rustc without LLVM (try 2)"
This includes a small patch to allow running tests without llvm. Also check if you are not trying to compile a dylib.
cc #42932
r? @alexcrichton
|
|
|
|
|
