On stage 0, rather than compiling std utilize the one from the stage0 sysroot
as stage 0 should represent the snapshot version not the compiled one.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
resolve stage0 sysroot from rustc
Similar to https://github.com/rust-lang/rust/pull/141729, instead of manually navigating directories based on stage0 rustc, use `--print sysroot` to get the sysroot directly. This also works when using the bootstrap `rustc` shim.
r? Kobzol
Refactor the two-phase check for impls and impl items
Refactor the two-phase dead code check to make the logic clearer and simpler:
1. adding assoc fn and impl into `unsolved_items` directly during the initial construction of the worklist
2. converge the logic of checking whether assoc fn and impl are used to `item_should_be_checked`, and the item is considered used only when its corresponding trait and Self adt are used
This PR only refactors as much as possible to avoid affecting the original functions. However, due to the adjustment of the order of checks, the test results are slightly different, but overall, there is no regression problem
Fixesrust-lang/rust#127911Fixesrust-lang/rust#128839
Extracted from https://github.com/rust-lang/rust/pull/128637.
r? petrochenkov
try-job: dist-aarch64-linux
Leaving stage0 target-libdir resolution to rustc. This should also fix the issue with
hard-coding `$sysroot/lib` which fails on systems that use `$sysroot/lib64` or `$sysroot/lib32`.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Instead of manually navigating directories based on stage0 rustc, use `--print sysroot`
to get the sysroot directly. This also works when using the bootstrap `rustc` shim.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Do not get proc_macro from the sysroot in rustc
With the stage0 refactor the proc_macro version found in the sysroot will no longer always match the proc_macro version that proc-macros get compiled with by the rustc executable that uses this proc_macro. This will cause problems as soon as the ABI of the bridge gets changed to implement new features or change the way existing features work.
To fix this, this commit changes rustc crates to depend directly on the local version of proc_macro which will also be used in the sysroot that rustc will build.
Building with _LIBUNWIND_IS_NATIVE_ONLY disables code for cross-architecture unwinding
it is disabled by default in LLVM [1], replicate the cmake behavior in bootstrap process
It also enables some additional code that handles PAC-specific unwind info
it helps compiling with the -mbranch-protection=pac or -mbranch-protection=standard flags
This fixes build with clang/musl on aarch64
[1] 85624c5de3
Signed-off-by: Khem Raj <raj.khem@gmail.com>
With the stage0 refactor the proc_macro version found in the sysroot
will no longer always match the proc_macro version that proc-macros get
compiled with by the rustc executable that uses this proc_macro. This
will cause problems as soon as the ABI of the bridge gets changed to
implement new features or change the way existing features work.
To fix this, this commit changes rustc crates to depend directly on the
local version of proc_macro which will also be used in the sysroot that
rustc will build.
dist: make sure llvm-project submodule is present
Zero-config `x install` fails when bootstrap tries to copy files from the LLVM submodule because it's not properly initialized/handled. This diff handles that.
Fixes https://github.com/rust-lang/rust/issues/141393
bootstrap: translate Windows paths in a way that works for both Cygwin and MSYS2
Cygwin defaults to rooting Windows paths in /cygdrive/X, while MSYS2 configures them to be /X. Regardless of configuration, drives are always accessible as /proc/cygdrive/X, so use that.
If there are other shells on Windows that are supported and use /X style paths, perhaps something more complicated needs to be done.
r? `@jieyouxu`
`@Berrysoft` `@mati865`
Cygwin defaults to rooting Windows paths in /cygdrive/X, while MSYS2
configures them to be /X. Regardless of configuration, drives are
always accessible as /proc/cygdrive/X, so use that.
This addresses issue 104200 by setting the TESTNAME environment
variable automatically based on the paths from run configs,
marking a selected set of UI tests to be run.
Note that this does not filter out other unit tests using #[test].
make shared_helpers exe function work for both cygwin and non-cygwin hosts
On Cygwin, it needs to not append .exe, because /proc/self/exe (and therefore `std::env::current_exe`) does not include the .exe extension, breaking bootstrap's rustc wrapper. On hosts other than Cygwin, it *does* need to append .exe because the file really does have a .exe extension, and non-Cygwin hosts won't be doing the same filename rewriting that Cygwin does when looking for a file X but finding only X.exe in its place.
Arising from discussion in https://github.com/rust-lang/rust/pull/140154#pullrequestreview-2855782812
``@mati865`` ``@Berrysoft``
Update IDEs to use rustfmt 2024, fix Zed settings
Update IDEs to use rustfmt 2024, fix Zed settings
- Update IDE `rust-analyzer` settings to use 2024 rather than 2021.
- Fix Zed settings by removing `${workspaceFolder}/` from paths.
On Cygwin, it needs to not append .exe, because /proc/self/exe (and
therefore std::env::current_exe) does not include the .exe extension,
breaking bootstrap's rustc wrapper. On hosts other than Cygwin, it
*does* need to append .exe because the file really does have a .exe
extension, and non-Cygwin hosts won't be doing the same filename
rewriting that Cygwin does when looking for a file X but finding only
X.exe in its place.
update llvm-tools logic for `dist` and `install` steps
First commit aligns `build_steps::compile` and `build_steps::dist` logics for copying llvm-tools, and the second commit adds the correct `should_run` condition for `LlvmTools` step as the previous one was clearly incorrect.
Fixes#140913
trim cache module in utils bootstrap
We don't use other variants of Interner in bootstrap, so this PR streamlines the bootstrap cache utils module.
r? `@onur-ozkan`
remove `RustfmtState` to reduce `initial_rustfmt` complexity
The current use of `RustfmtState` doesn't serve its main purpose as it never does the lazy evaulation since `Build::build` forces it to be ready on the early stage. If we want rustfmt to be ready on the early stage, we don't need to have `RustfmtState` complexity at all.
The current use of `RustfmtState` doesn't serve its main purpose as it
never does the lazy evaulation since `Build::build` forces it to be ready
on the early stage. If we want rustfmt to be ready on the early stage, we
don't need to have `RustfmtState` complexity at all.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
