| Age | Commit message (Collapse) | Author | Lines |
|---|
|
MVP for using rust-lld as part of cc
Will fix #71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using `echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa::back::link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl,-v` (thanks to bjorn3 on Zulip), I can see that lld is used, but I'm not sure how to inspect that output in a test.
|
|
Add the x86_64-gnu-stable builder
During the 1.52 release process we had to deal with some commits that passed the test suite on the nightly branch but failed on the beta or stable branch. In that case it was due to some UI tests including the channel name in the output, but other changes might also be dependent on the channel.
This commit adds a new CI job that runs the Linux x86_64 test suite with the stable branch, ensuring nightly changes also work as stable. To ensure the new job works the following other changes are present:
* The `ui-fulldeps/session-derive-errors.rs` test has been disabled on beta and stable, which required adding support for `// ignore-{channel}` and `// only-{channel}`.
* The `rustdoc/intra-doc/field.rs` has been fixed.
r? `@Mark-Simulacrum`
fixes https://github.com/rust-lang/release-team/issues/11
|
|
Don't pass -Z unstable-options by default for UI tests
Unconditionally passing -Z unstable-options makes it impossible to test whether an option requires unstable-options or not.
This uncovered quite a lot of bugs, I'll open issues for each. These don't strictly need to be fixed before this is merged, it just makes the diff much larger because of the changes to diagnostics.
- https://github.com/rust-lang/rust/issues/82636
- https://github.com/rust-lang/rust/issues/82637
- https://github.com/rust-lang/rust/issues/82638
|
|
ignore test if rust-lld not found
create ld -> rust-lld symlink at build time instead of run time
for testing in ci
copy instead of symlinking
remove linux check
test for linker, suggestions from bjorn3
fix overly restrictive lld matcher
use -Zgcc-ld flag instead of -Clinker-flavor
refactor code adding lld to gcc path
revert ci changes
suggestions from petrochenkov
rename gcc_ld to gcc-ld in dirs
|
|
|
|
The session-derive-errors test ensures the internal SessionDiagnostic
derive macro outputs the right error messages when misused.
The macro relies on the proc_macro2 crate though, which changes its span
behavior depending on whether the channel is nightly or not. This caused
test failures when bumping the channel from nightly to beta/stable.
Since SessionDiagnostic is internal-only we don't care about its
diagnostics quality outside of nightly, as the compiler itself is
developed on nightly. Thus the easiest solution is to ignore that test
on the beta and stable channels.
This also implements `// only-{channel}` and `// ignore-{channel}` in
compiletest to properly support the change.
|
|
Remove the install prefix from the rpath set when using -Crpath
It was broken anyway for rustup installs and nobody seems to have noticed.
Fixes https://github.com/rust-lang/rust/issues/82392
|
|
rustbuild: take changes to the standard library into account for `download-rustc`
Previously, changing the standard library with `download-rustc =
"if-unchanged"` would incorrectly reuse the cached compiler and standard
library from CI, which was confusing and led to incorrect test failures
or successes.
r? `@Mark-Simulacrum`
|
|
Don't run sanity checks for `x.py setup`
These requirements change as soon as the command finishes running, and
`setup` doesn't build anything, so the check doesn't make sense.
Previously, `x.py setup` would give hard errors if `ninja` and `cmake`
were not installed, even if the new profile didn't require them.
Fixes https://github.com/rust-lang/rust/issues/84938.
|
|
Pass --cfg=bootstrap for proc macros built by stage0
Cargo has a bug where it ignores RUSTFLAGS when building proc macro
crates (https://github.com/rust-lang/cargo/issues/4423).
However, sometimes rustc_macro needs to have conditional
compilation when there are breaking changes to the `libproc_macro` API
(see for example #83363). Previously, this wasn't possible, because the
crate couldn't tell the difference between stage 0 and stage 1.
Another alternative is to unconditionally build rustc_macros with the
master libstd instead of the beta one (i.e. use `--sysroot
stage0-sysroot`), but that led to strange and maddening errors:
```
error[E0460]: found possibly newer version of crate `std` which `synstructure` depends on
--> compiler/rustc_macros/src/lib.rs:5:5
|
5 | use synstructure::decl_derive;
| ^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `synstructure`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libsynstructure-74ee66863479e972.rmeta
error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5
|
90 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib
```
r? `@Mark-Simulacrum` cc `@jhpratt`
|
|
- Pass it explicitly where appropriate
- Update stderr files and warnings; it turns that unstable-options has
far-reaching effects on diagnostics.
|
|
BPF target support
This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.
I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
|
|
CFG_PREFIX is incorrect for rustup installed rustc versions. It also
causes unnecessary recompilation when changing the install prefix.
|
|
Cargo ignores RUSTFLAGS when building proc macro crates. However,
sometimes rustc_macro needs to have conditional compilation when there
are breaking changes to the `libproc_macro` API (see for example
tell the difference between stage 0 and stage 1.
Another alternative is to unconditionally build rustc_macros with the
master libstd instead of the beta one (i.e. use `--sysroot
stage0-sysroot`), but that led to strange and maddening errors:
```
error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5
|
90 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib
```
|
|
Note that `ninja = false` goes under `[llvm]`
Addresses https://github.com/rust-lang/rust/issues/84938#issuecomment-852448332 - `@kornelski` does this look good?
r? `@Mark-Simulacrum` cc `@joshtriplett`
|
|
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
|
|
`download-rustc`
Previously, changing the standard library with `download-rustc =
"if-unchanged"` would incorrectly reuse the cached compiler and standard
library from CI, which was confusing and led to incorrect test failures
or successes.
|
|
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
|
|
|
|
These requirements change as soon as the command finishes running, and
`setup` doesn't build anything, so the check doesn't make sense.
Previously, `x.py setup` would give hard errors if `ninja` and `cmake`
were not installed, even if the new profile didn't require them.
|
|
|
|
Build crtbegin.o/crtend.o from source code
Build crtbengin.o/crtend.o from source code instead of copying from gcc.
The crtbegin and crtend implementation from llvm don't need `crtbeginS.o` for PIC. `crtbegin{,S,T}.o` is unified into one generic `crtbegin.o`. See the comments in https://reviews.llvm.org/D28791#1419436 and https://reviews.llvm.org/D28791#1420914
fix: https://github.com/rust-lang/rust/issues/85310 , fix: https://github.com/rust-lang/rust/issues/47551 , fix: https://github.com/rust-lang/rust/issues/84033
|
|
|
|
Do not try to build LLVM with Zlib on Windows
Fixes https://github.com/rust-lang/rust/issues/85422
Fixes https://github.com/rust-lang/rust/issues/85624
We do not install Zlib on the CI but recent builds somehow started picking it's shared version.
To avoid relying on CI binaries so let's explicitly disable it.
|
|
r=Mark-Simulacrum
Enforce rustdoc-gui test-suite run
Part of https://github.com/rust-lang/rust/issues/84550
|
|
|
|
We do not install Zlib on the CI but recent builds somehow started picking it's shared version.
To avoid relying on CI binaries so let's explicitly disable it.
|
|
Update cc
Recent commits have improved `cc`'s finding of MSVC tools on Windows. In particular it should help to address these issues: #83043 and #43468
|
|
|
|
Revert "Move llvm submodule updates to rustbuild"
Reverts rust-lang/rust#81601
This updates LLVM a bit too eagerly -- and particularly on Windows, this can be slow. See discussion on [Zulip].
[Zulip]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/x.2Epy.20always.20updates.20LLVM.20submodule
|
|
Fix bootstrap using host exe suffix for cargo
When attempting to cross compile rustc (for example, from Linux to Windows) and tell it to build cargo/tools, the following error occurs:
```
thread 'main' panicked at 'src.symlink_metadata() failed with No such file or directory (os error 2)', src/bootstrap/lib.rs:1196:24
```
Relevant part of stack trace:
<details>
```
2: bootstrap::Build::copy
at ./src/bootstrap/lib.rs:1196:24
3: <bootstrap::tool::ToolBuild as bootstrap::builder::Step>::run
at ./src/bootstrap/tool.rs:220:13
```
</details>
If I add `-vvv` (which seemed to be the recommended course for debugging a similar issue according to [zulip logs](https://zulip-archive.rust-lang.org/182449tcompilerhelp/19655failedtobootstrap.html)), it shows:
```
Copy ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release/cargo" to ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools-bin/cargo"
```
and when taking a look at the contents of `build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release` it contains `cargo.exe`, but no `cargo`.
I tried to study the surrounding code to make sure this was the intended behavior and while I can't be 100% certain, it does seem that using the exe suffix for the `compiler.host` target instead of the `target` target won't have the desired behavior when cross-compiling to/from Windows.
|
|
Recent commits to cc have helped to address #83043 and #43468
|
|
|
|
|
|
This change adds the bpfel-unknown-none and bpfeb-unknown-none targets
which can be used to generate little endian and big endian BPF
|
|
Move llvm submodule updates to rustbuild
This enables better caching, since LLVM is only updated when needed, not
whenever x.py is run. Before, bootstrap.py had to use heuristics to
guess if LLVM would be needed, and updated the module more often than
necessary as a result.
This syncs the LLVM submodule only just before building the compiler, so
people working on the standard library never have to worry about it.
Example output:
```
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Updating submodule src/llvm-project
Submodule 'src/llvm-project' (https://github.com/rust-lang/llvm-project.git) registered for path 'src/llvm-project'
Submodule path 'src/llvm-project': checked out 'f9a8d70b6e0365ac2172ca6b7f1de0341297458d'
```
Implements https://github.com/rust-lang/rust/issues/76653#issuecomment-770265169. This could be easily extended to other submodules, like `rust-by-example` and `rustc-dev-guide`, which aren't needed for cargo's workspace resolution.
|
|
This enables better caching, since LLVM is only updated when needed, not
whenever x.py is run. Before, bootstrap.py had to use heuristics to
guess if LLVM would be needed, and updated the module more often than
necessary as a result.
This syncs the LLVM submodule only just before building the compiler, so
people working on the standard library never have to worry about it.
Example output:
```
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Updating submodule src/llvm-project
Submodule 'src/llvm-project' (https://github.com/rust-lang/llvm-project.git) registered for path 'src/llvm-project'
Submodule path 'src/llvm-project': checked out 'f9a8d70b6e0365ac2172ca6b7f1de0341297458d'
```
- Don't try to update the LLVM submodule when using system LLVM
Previously, this would try to update LLVM unconditionally. Now the
submodule is only initialized if `llvm-config` is not set.
- Don't update LLVM submodule in dry runs
This prevents the following test failures:
```
running 17 tests
fatal: invalid gitfile format: /checkout/src/llvm-project/.git
test builder::tests::defaults::build_cross_compile ... FAILED
---- builder::tests::defaults::build_default stdout ----
thread 'main' panicked at 'command did not execute successfully: "git" "rev-parse" "HEAD"
expected success, got: exit code: 128', src/build_helper/lib.rs:139:9
```
- Try running git without --progress if it fails the first time
This avoids having to do version detection to see if --progress is
supported or not.
- Don't try to update submodules when the source repository isn't managed by git
- Update LLVM submodules that have already been checked out
- Only check for whether the submodule should be updated in lib.rs; update
it unconditionally in native.rs
|
|
|
|
This bug was only visible on mac. Also, print_step_rusage is a relatively new
internal feature, that is not heavily used, and has no tests. All of these
factors contributed to how this went uncaught this long. Thanks to Josh Triplett
for pointing it out!
|
|
bootstrap: ensure host std when cross-compiling tools, fixes #85320
|
|
bootstrap: build cargo only if requested in tools
In Debian we'd like to build rustfmt and clippy alongside rustc, but we're still excluding cargo from the rustc build and doing that separately. This patch makes that possible.
|
|
Previously, setting `download-ci-llvm = true` when cmake wasn't
installed would give the following error:
```
failed to execute command: "cmake" "--help"
error: The system cannot find the file specified. (os error 2)
```
|
|
Rollup of 4 pull requests
Successful merges:
- #84751 (str::is_char_boundary - slight optimization)
- #85185 (Generate not more docs than necessary)
- #85324 (Warn about unused `pub` fields in non-`pub` structs)
- #85329 (fix version_str comment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
GuillaumeGomez:generate-not-more-docs-than-necessary, r=Mark-Simulacrum
Generate not more docs than necessary
This is something that `@Nemo157` was talking about: they wanted that when using `x.py doc std`, it only generated `std` (and the crates "before" it).
r? `@Mark-Simulacrum`
|
|
|
|
|
|
This fixes the following error:
```
error: found crates (`serde_derive` and `serde_derive`) with colliding StableCrateId values.
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/cargo_metadata-0.8.2/src/lib.rs:162:1
|
162 | extern crate serde_derive;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This is a bug in resolve (https://github.com/rust-lang/rust/issues/56935)
but it will be difficult to fix in the near future. This works around it
in the meantime by not copying serde_derive and other dependencies to
the sysroot when they're built for other tools. This rebuilds the
dependencies slightly more often than necessary, but avoids the crate
conflicts.
This can be reverted once #56935 is fixed.
|
|
- Add rustfmt to `x.py check`
- Update Cargo.lock
- Remove rustfmt from the toolstate list
- Make rustfmt an in-tree tool
- Give an error on `x.py test rustfmt` if rustfmt fails to build or if tests fail
- Don't call `save_toolstate` when testing rustfmt
|
|
|
|
Update cc crate
To pull in this fix: https://github.com/alexcrichton/cc-rs/commit/801a87bf2f31ad1ad8bd7e8fa4f5a52b0e2b4c00
|
