Add cg_clif as optional codegen backend
Rustc_codegen_cranelift is an alternative codegen backend for rustc based on Cranelift. It has the potential to improve compilation times in debug mode. In my experience the compile time improvements over debug mode LLVM for a clean build are about 20-30% in most cases.
This PR adds cg_clif as optional codegen backend. By default it is only enabled for `./x.py check`. It can be enabled for `./x.py build` too by adding `cranelift` to the `rust.codegen-backends` array in `config.toml`.
MCP: https://github.com/rust-lang/compiler-team/issues/270
r? `@Mark-Simulacrum`
Sync LLVM submodule if it has been initialized
Since having enabled the download-ci-llvm option,
and having rebased on top of #76864,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.
This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.
An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.
Haiku: explicitly set CMAKE_SYSTEM_NAME when cross-compiling
This resolves issues where the cross-build of LLVM fails because it tries to
link to the host's system libraries instead of the target's system libraries.
Since having enabled the download-ci-llvm option,
and having rebased on top of f05b47ccdf,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.
This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.
An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.
Modify executable checking to be more universal
This uses a dummy file to check if the filesystem being used supports the executable bit in general.
Supersedes #74753.
This resolves issues where the cross-build of LLVM fails because it tries to
link to the host's system libraries instead of the target's system libraries.
Detect configuration for LLVM during setup
This is a first draft to address #77579, setting `download-ci-llvm` to true on Linux, but I could also implement the `if-available` setting mentioned in the issue.
On other platforms I was thinking about using [the which crate](https://crates.io/crates/which), if adding a dependency on it is considered okay of course, to detect the presence of `llvm-config` in the path, and use it if found. Still a work in progress of course.
We need a fresh input buffer each time, or we reuse the previous
data (since `read_line` appends).
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Put all()'s otuput in the order we want to print things in, and add a
comment about why they are in this order. Provide purpose() and
all_for_help(). Use these things everywhere.
Move all the abbrev character ("a", "b", etc.) processing into
interactive_path.
No functional change.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
bootstrap: only use compiler-builtins-c if they exist
The assignment of `features` above was added in rust-lang#60981, but
never used. Presumably the intent was to replace the string literal here
with it.
While I'm in the area, `compiler_builtins_c_feature` doesn't need to be
a `String`.
I'm not entirely sure of a great way to locally test this -- `./x.py test`
passed on my machine, but 🤷♂️.
r? @alexcrichton
bootstrap: set correct path for the build-manifest binary
This changes the path of the binary inside the tarball to be:
```
build-manifest-{release}-{target}/build-manifest/bin/build-manifest
```
...instead of:
```
build-manifest-{release}-{target}/build-manifest/bin/build-manifest/build-manifest
```
r? @Mark-Simulacrum
Include `llvm-dis`, `llc` and `opt` in `llvm-tools-preview` component
Fixes#55890
It's useful to have `llc` and `opt` available when debugging an LLVM
miscompilation,.
Mention rustdoc in `x.py setup`
This lets new contributors know which option they should pick; previously it wasn't clear 'compiler' also included rustdoc.
Unresolved questions: should this say 'compiler and tools' instead? I don't know of any tools that are modified in-tree other than rustdoc, though.
r? @Mark-Simulacrum
Give an error when running `x.py test --stage 0 src/test/ui`
The error can be overridden with `COMPILETEST_FORCE_STAGE0=1`. In practice I don't know why anyone would do this.
r? @Mark-Simulacrum
Closes https://github.com/rust-lang/rust/issues/77711
Dist build manifest
This PR makes two changes that should remove a significant chunk of the time spent in our release process: cloning the `rust-lang/rust` monorepo, all its submodules, and building `bootstrap` to then invoke `build-manifest`:
* `build-manifest` doesn't rely on a clone of the monorepo being present anymore. The only remaining bit of information it fetched from it (the Rust version) is instead bundled in the binary.
* A new "component" is added, `build-manifest`. That component includes a prebuilt version of the tool, and it's *not* included in the Rustup manifest. This will allow `promote-release` to directly invoke the tool without interacting with our build system.
* The Linux x86_64 CI is changed to also build the component mentioned above. It's the only CI builder tasked to do so, and to cleanly support this a new `--include-default-paths` flag was added to `./x.py`.
* The `BUILD_MANIFEST_NUM_THREADS` environment variable is added to configure the number of threads at runtime.
This PR is best reviewed commit-by-commit.
r? `@Mark-Simulacrum`
This commit changes the way build-manifest is invoked, to let it accept
the Rust version directly instead of requiring the path of the Rust
monorepo and letting build-manifest figure out the path on its own.
This allows to run build-manifest without a clone of the monorepo.
More print statementsstatements lol
Solved the basic case of eliminating check_version ifk_version if subcommand = setup
Finished v1
checking out old bootstrap.py
checked out old irrelevant files
fixed tidy
Moved VERSION from bin/main.rs to lib.rs
Fixed semicolon return issue
x.py fmt
The assignment of `features` above was added in rust-lang#60981, but
never used. Presumably the intent was to replace the string literal here
with it.
While I'm in the area, `compiler_builtins_c_feature` doesn't need to be
a `String`.
The format of the tarballs produced by CI is roughly the following:
{component}-{release}-{target}.{ext}
While on the beta and nightly channels `{release}` is just the channel
name, on the stable channel is either the Rust version or the version of
the component we're shipping:
cargo-0.47.0-x86_64-unknown-linux-gnu.tar.xz
clippy-0.0.212-x86_64-unknown-linux-gnu.tar.xz
llvm-tools-1.46.0-x86_64-unknown-linux-gnu.tar.xz
miri-0.1.0-x86_64-unknown-linux-gnu.tar.xz
rls-1.41.0-x86_64-unknown-linux-gnu.tar.xz
rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz
...
This makes it really hard to get the package URL without having access
to the manifest (and there is no manifest on ci-artifacts.rlo), as there
is no consistent version number to use.
This commit addresses the problem by always using the Rust version
number as `{release}` for the stable channel, regardless of the version
number of the component we're shipping. I chose that instead of "stable"
to avoid breaking the URL scheme *that* much.
Rustup should not be affected by this change, as it fetches the URLs
from the manifest. Unfortunately we don't have a way to test other
clients before making a stable release, as this change only affects the
stable channel.
