This ensures that the failure cases for finding the codegen backend and
for finding the rustc binary are essentially the same, and since we
almost always will load the codegen backend, this is essentially meaning
that the rustc change is not a regression.
Ensure edition lints and internal lints are enabled with deny-warnings=false
Previously we only passed the deny command line flags if deny-warnings was enabled, but now we either pass -W... or -D... for each of the flags as appropriate.
This is also a breaking change to x.py as it changes `--warnings=allow` to `--warnings=warn` which is what that flag actually did; we don't have an allow warnings mode.
Include compiler-rt in the source tarball
In #60981 we switched to using src/llvm-project/compiler-rt inside
compiler-builtins rather than a separate copy of it.
In order to have the "c" feature turn on in builds from the source
tarball, we need to include that path in its creation.
fixes#64239
In #60981 we switched to using src/llvm-project/compiler-rt inside
compiler-builtins rather than a separate copy of it.
In order to have the "c" feature turn on in builds from the source
tarball, we need to include that path in its creation.
fixes#64239
Better way of conditioning the sanitizer builds
Previously the build would take the presence of the LLVM_CONFIG envvar to
mean that the sanitizers should be built, but this is a common envvar that
could be set for reasons unrelated to the rustc sanitizers.
This commit adds a new envvar RUSTC_BUILD_SANITIZERS and uses it instead.
This PR or similar will be necessary in order to work correctly with https://github.com/rust-lang-nursery/compiler-builtins/pull/296
Previously the build would take the presence of the LLVM_CONFIG envvar to
mean that the sanitizers should be built, but this is a common envvar that
could be set for reasons unrelated to the rustc sanitizers.
This commit adds a new envvar RUSTC_BUILD_SANITIZERS and uses it instead.
Rustbuild usually writes the LLVM submodule commit in a stamp file, so
we can avoid rebuilding it unnecessarily. However, for builds from a
source tarball (non-git), we were assuming a rebuild is always needed.
This can cause a lot of extra work if any environment like `CFLAGS`
changed between steps like build and install, which are often separate
in distro builds.
Now we also write an empty stamp file if the git commit is unknown, and
its presence is trusted to indicate that no rebuild is needed. An info
message reports that this is happening, along with the stamp file path
that can be deleted to force a rebuild anyway.
Fix build failure in case file doesn't exist
It fixes the following issue:
```bash
$ ./x.py test src/tools/linkchecker ./build/x86_64-apple-darwin/doc/ --stage 1
Updating only changed submodules
Submodules updated in 0.05 seconds
Finished dev [unoptimized] target(s) in 0.15s
thread 'main' panicked at 'source "/Users/imperio/rust/rust/build/x86_64-apple-darwin/doc/version_info.html" failed to get metadata: No such file or directory (os error 2)', src/build_helper/lib.rs:179:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
failed to run: /Users/imperio/rust/rust/build/bootstrap/debug/bootstrap test src/tools/linkchecker ./build/x86_64-apple-darwin/doc/ --stage 1
Build completed unsuccessfully in 0:00:01
```
If the file doesn't exist, it makes sense anyway to just run the command in order to generate it.
r? @Mark-Simulacrum
use the code generation parameter -Clinker (same parameter as rustc)
to control what linker to use for building the rustdoc test executables.
closes: #63816
std: Remove the `wasm_syscall` feature
This commit removes the `wasm_syscall` feature from the
wasm32-unknown-unknown build of the standard library. This feature was
originally intended to allow an opt-in way to interact with the
operating system in a posix-like way but it was never stabilized.
Nowadays with the advent of the `wasm32-wasi` target that should
entirely replace the intentions of the `wasm_syscall` feature.
This commit removes the `wasm_syscall` feature from the
wasm32-unknown-unknown build of the standard library. This feature was
originally intended to allow an opt-in way to interact with the
operating system in a posix-like way but it was never stabilized.
Nowadays with the advent of the `wasm32-wasi` target that should
entirely replace the intentions of the `wasm_syscall` feature.
When deny-warnings is not specified or set to true, the behaviour is the same as before.
When deny-warnings is set to false, warnings are now allowed
Fixes#63911
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
Run Clippy without json-rendered flag
Removed in https://github.com/rust-lang/rust/pull/62766
Replacing it with `--json=diagnostic-rendered-ansi` fails:
```
error: using `--json` requires also using `--error-format=json`
```
Running `./x.py clippy src/libstd` locally works fine (with colors) on Linux so I don't know if there is something to fix.
Do not emit JSON dumps of diagnostic codes
This decouples the error index generator from libsyntax for the most part (though it still depends on librustdoc for the markdown parsing and generation).
Fixes#34588
This is no longer used by the index generator and was always an unstable
compiler detail, so strip it out.
This also leaves in RUSTC_ERROR_METADATA_DST since the stage0 compiler
still needs it to be set.
This patch supports less behavior than before, since specifiying stage 1
vs stage 2 is no longer possible, but that is presumably a somewhat rare
use case anyway, so not supporting it seems acceptable (and it can be
readded easily if desired).
Opaque builtin derive macros
* Buiilt-in derives are now opaque macros
* This required limiting the visibility of some previously unexposed functions in `core`.
* This also required the change to `Ident` serialization.
* All gensyms are replaced with hygienic identifiers
* Use hygiene to avoid most other name-resolution issues with buiilt-in derives.
* As far as I know the only remaining case that breaks is an ADT that has the same name as one of its parameters. Fixing this completely seemed to be more effort than it's worth.
* Remove gensym in `Ident::decode`, which lead to linker errors due to `inline` being gensymmed.
* `Ident`now panics if incremental compilation tries to serialize it (it currently doesn't).
* `Ident` no longer uses `gensym` to emulate cross-crate hygiene. It only applied to reexports.
* `SyntaxContext` is no longer serializable.
* The long-term fix for this is to properly implement cross-crate hygiene, but this seemed to be acceptable for now.
* Move type/const parameter shadowing checks to `resolve`
* This was previously split between resolve and type checking. The type checking pass compared `InternedString`s, not Identifiers.
* Removed the `SyntaxContext` from `{ast, hir}::{InlineAsm, GlobalAsm}`
cc #60869
r? @petrochenkov
Modify librustc_llvm to pass -DNDEBUG while compiling.
Currently, librustc_llvm builds are not reproducible because the LLVM files it compiles use the debug version of llvm_unreachable, which uses __FILE__. To fix this, we propagate NDEBUG from bootstrap if applicable and use it when compiling librustc_llvm.
r? @alexcrichton
Rename overflowing_{add,sub,mul} intrinsics to wrapping_{add,sub,mul}.
These confused @Gankra, and then, also me, especially since `overflowing_*` *methods* also exist, but they map to `*_with_overflow` intrinsics!
r? @oli-obk / @nikomatsakis cc @Mark-Simulacrum (on the rustbuild workaround)
Remap paths for proc-macro crates.
The remap-debuginfo config option remaps paths in most crates, but it does not apply to proc-macros, so they are still non-reproducible. This patch fixes that.
I'm not completely sure if this is the best way to do this, but to get reproducible builds we need librustc_macros to be built with --remap-path-prefix. I was previously modifying Cargo to pass that argument to all child crates, so this seems simpler and more correct.
I did not add a test since there do not seem to be any existing tests for RUSTC_DEBUGINFO_MAP.
r? @alexcrichton
Rollup of 10 pull requests
Successful merges:
- #60492 (Add custom nth_back for Chain)
- #61780 (Finalize the error type for `try_reserve`)
- #63495 ( Remove redundant `ty` fields from `mir::Constant` and `hair::pattern::PatternRange`.)
- #63525 (Make sure that all file loading happens via SourceMap)
- #63595 (add sparc64-unknown-openbsd target)
- #63604 (Some update for vxWorks)
- #63613 (Hygienize use of built-in macros in the standard library)
- #63632 (A couple of comment fixes.)
- #63634 (ci: properly set the job name in CPU stats)
- #63636 (ci: move linkcheck from mingw-2 to mingw-1)
Failed merges:
r? @ghost
ci: move linkcheck from mingw-2 to mingw-1
Running UI tests now takes a huge amount of time on mingw builders
(between 40 and 50 minutes), with mingw-1 builders taking even an hour
less to finish than mingw-2. This PR moves linkcheck from mingw-2 to
mingw-1, removing between 10 and 20 minutes of runtime on the -2
builders.
r? @alexcrichton
Some update for vxWorks
1. support crt-static
2. change armv7_wrs_vxworks to armv7_wrs_vxworks_eabihf.
3. change vx-cxx to wr-c++, vx-ar to wr-ar and vx-run to wr-run.
4. code cleanup
r? @alexcrichton
Running UI tests now takes a huge amount of time on mingw builders
(between 40 and 50 minutes), with mingw-1 builders taking even an hour
less to finish than mingw-2. This PR moves linkcheck from mingw-2 to
mingw-1, removing between 10 and 20 minutes of runtime on the -2
builders.
Utilize -Zbinary-dep-depinfo in rustbuild
We no longer utilize stamp-file mtimes at all inside rustbuild, and a future PR may be able to entirely eliminate them by eagerly copying to the appropriate sysroot. The only mtime-based dependency tracking left is for documentation because we lie to Cargo about the rustdoc binary, so Cargo does not track changes to the real binary, and codegen-backends because binary-dep-depinfo does not emit that information into the depfiles.
Both of these are fixable in the longer term but this existing patch gives us the following benefits:
* We no longer delete Cargo target directories manually within a stage. Cross-stage, changes to codegen backends will still clear out target directories. This means that incremental state persists across individual steps (e.g., rebuilding libstd does not clear out librustc incremental state). Fixes#54712.
* Dependency tracking across steps within a given stage is now fully precise. We will not clear out all codegen backend dependencies due to changes in librustc_driver, for example, only deleting the final librustc_codegen_llvm crate. Fixes#54008, fixes#50481.
* We properly track codegen backends as a dependency (equivalent to rustc) across changes. Fixes#53284, and fixes#52719.
* Cross-stage dependency tracking of crates is also much more accurate and reliable. Most likely fixes#49979 (but no reproduction steps in that issue). Fixes#59105.
cc #63012
Currently, librustc_llvm builds are not reproducible because the LLVM
files it compiles use the debug version of llvm_unreachable, which
uses __FILE__. To fix this, we propagate NDEBUG from bootstrap if
applicable and use it when compiling librustc_llvm.
The remap-debuginfo config option remaps paths in most crates, but it
does not apply to proc-macros, so they are still non-reproducible.
This patch fixes that.
