ignore `llvm::Lld` if lld is not enabled
People are having trouble ([ref. zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/MSVC.20Runtime.20mismatch.20when.20building.20LLD)) when they don't want to build `lld` for their custom distribution tarballs even with `lld = false` in their config.toml. This is because it is not controlled by `lld_enabled` flag. This change ensures that `llvm:Lld` is controlled by lld configuration.
Additionally, `lld = true` is set by default for dist profile, because we have been building it all along and this maintains that behavior.
try-job: x86_64-mingw
Tighten `fn_decl_span` for async blocks
Tightens the span of `async {}` blocks in diagnostics, and subsequently async closures and async fns, by actually setting the `fn_decl_span` correctly. This is kinda a follow-up on #125078, but it fixes the problem in a more general way.
I think the diagnostics are significantly improved, since we no longer have a bunch of overlapping spans. I'll point out one caveat where I think the diagnostic may get a bit more confusing, but where I don't think it matters.
r? ````@estebank```` or ````@oli-obk```` or someone else on wg-diag or compiler i dont really care lol
patchable-function-entry: Add unstable compiler flag and attribute
Tracking issue: #123115
Add the -Z patchable-function-entry compiler flag and the #[patchable_function_entry(prefix_nops = m, entry_nops = n)] attribute.
Rebased and adjusted the canditate implementation to match changes in the RFC.
Currently bootstrap doesn't use any inner paths from rust-analyzer and
bootstrap with `ShouldRun::create_or_deps`.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
rustdoc: use current stage if download-rustc enabled
When using download-rustc, using stage 1 rustdoc results in the wrong librustc_driver being used.
```sh
$ ./build/host/stage1/bin/rustdoc --version
./build/host/stage1/bin/rustdoc: error while loading shared libraries: librustc_driver-7ff02ed05016d515.so: cannot open shared object file: No such file or directory
```
This change fixes that by not cutting the stage if download-rustc is enabled.
Fixes for 32-bit SPARC on Linux
This PR fixes a number of issues which previously prevented `rustc` from being built
successfully for 32-bit SPARC using the `sparc-unknown-linux-gnu` triplet.
In particular, it adds linking against `libatomic` where necessary, uses portable `AtomicU64`
for `rustc_data_structures` and rewrites the spec for `sparc_unknown_linux_gnu` to use
`TargetOptions` and replaces the previously used `-mv8plus` with the more portable
`-mcpu=v9 -m32`.
To make `rustc` build successfully, support for 32-bit SPARC needs to be added to the `object`
crate as well as the `nix` crate which I will be sending out later as well.
r? nagisa
patch `rust-lld` and `ld.lld` on NixOS
When `rustc` uses its self-contained lld, we also need to patch `rust-lld` and `ld.lld`.
The `rpath` for `rust-lld` is `$ORIGIN/../../../:$ORIGIN/../lib`, so I use `--add-rpath` instead of `--set-rpath`, which should be easier to maintain.
I also changed `src/bootstrap/src/core/download.rs`, even this doesn't fix any known issues.
For the `lld-wrapper.sh` of lld, refer to: https://github.com/rust-lang/rustc-dev-guide/pull/1999.
fix broken build cache caused by rustdoc builds
Currently rustdoc breaks the build cache (due to having different rustflags) when building rustdoc before building another tool (e.g., `x test miri && x test rustdoc && x test miri`).
This change fixes that by moving `on-broken-pipe` into `prepare_cargo_tool` so it is set for all tools.
cc `@RalfJung`
Fixes#123177
Bump black, ruff and platformdirs
Mainly because I encountered the following error, and we have no reason to prevent our upgrade.
```
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed.
This behaviour is the source of the following dependency conflicts.
virtualenv 20.25.3 requires platformdirs<5,>=3.9.1, but you have platformdirs 3.6.0 which is incompatible.
```
r? `@Kobzol`
miri: make sure we can find link_section statics even for the local crate
Miri needs some way to iterate all the exported functions and "used" statics of all crates. For dependency crates, this already works fine since we can overwrite the query resonsible for computing `exported_symbols`, but it turns out for local binary crates this does not work: for binaries, `reachable_set` skips a lot of its logic and only checks `contains_extern_indicator()` and `RUSTC_STD_INTERNAL_SYMBOL`. Other flags like `CodegenFnAttrFlags::USED` are entirely ignored.
This PR proposes to use the same check, `has_custom_linkage`, in binaries that we already use to drive the main workqueue of the reachability recursive traversal. I have no idea why binaries used a slightly different check that ignores `USED` -- was that deliberate or does it just not matter most of the time?
Currently rustdoc breaks the build cache (due to having different rustflags) when building
rustdoc before building another tool (e.g., `x test miri && x test rustdoc && x test miri`).
This change fixes that by moving `on-broken-pipe` into `prepare_cargo_tool` so it is
set for all tools.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Update cargo
10 commits in bc89bffa5987d4af8f71011c7557119b39e44a65..4ed7bee47f7dd4416b36fada1909e9a62c546246
2024-06-22 00:36:36 +0000 to 2024-06-25 16:28:22 +0000
- test: omit target-dir name (rust-lang/cargo#14142)
- test: migrate offline, open_namespaces and owner to snapbox (rust-lang/cargo#14138)
- docs: remove stray comment (rust-lang/cargo#14133)
- Change tests to support `rustc` wording changes (rust-lang/cargo#14135)
- deps: dont use tracing-attributes for workspace, use for cargo only (rust-lang/cargo#14122)
- Include vcs_info even if workspace is dirty (rust-lang/cargo#13960)
- test: migrate profile* to snapbox (rust-lang/cargo#14128)
- test: migrate path and paths to snapbox (rust-lang/cargo#14109)
- test: migrate rustflags, rustup and script to snapbox (rust-lang/cargo#14126)
- test: migrate rename_deps, replace, required_features and run to snapbox (rust-lang/cargo#14127)
Rollup of 7 pull requests
Successful merges:
- #126618 (Mark assoc tys live only if the corresponding trait is live)
- #126746 (Deny `use<>` for RPITITs)
- #126868 (not use offset when there is not ends with brace)
- #126884 (Do not ICE when suggesting dereferencing closure arg)
- #126893 (Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level)
- #126915 (Don't suggest awaiting in closure patterns)
- #126943 (De-duplicate all consecutive native libs regardless of their options)
r? `@ghost`
`@rustbot` modify labels: rollup
Mainly because I encountered the following error, and we have no reason to prevent our upgrade.
```
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed.
This behaviour is the source of the following dependency conflicts.
virtualenv 20.25.3 requires platformdirs<5,>=3.9.1, but you have platformdirs 3.6.0 which is incompatible.
```
Specify target specific linker for `riscv64gc-gnu` job
In https://github.com/rust-lang/rust/pull/125669 I updated the `riscv64gc-gnu` job to be more in line with other jobs, like the `armhf-gnu` one.
I missed something important, though! Since the `riscv64gc-unknown-linux-gnu` builds go through a cross compiler, invoking `cc` is not correct! That would invoke the `x86_64-unknown-linux-gnu` linker, instead of the `riscv64gc-unknown-linux-gnu` linker.
While developing #125669 I assumed this line would have been sufficient, however it was not:
553a69030e/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile (L27-L28)
Unfortunately, without the linker set, `cc` is invoked, and the following linker error occurs:
<details>
<summary>Long output</summary>
```
2024-06-21T14:37:54.4786899Z === HAYSTACK ===
2024-06-21T14:37:54.4787240Z error: linking with `cc` failed: exit status: 1
2024-06-21T14:37:54.4787589Z |
2024-06-21T14:37:54.4806781Z = note: LC_ALL="C" PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/bin:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/bin:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "cc" "/tmp/rustc7Ju6va/symbols.o" "inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o" "inaccessible/tmp/program.dv9uftjrq86w5xa7l2eo7g9l7.rcgu.o" "-Wl,--as-needed" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/inaccessible-temp-dir/inaccessible-temp-dir/rmake_out" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libstd-bb9ed017b7d70437.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libpanic_unwind-5b34ef68c22a7b9b.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libobject-4b9224407e296f51.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libmemchr-1eaaa8d74bbe0b36.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libaddr2line-b34292f7086867e9.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libgimli-1927540c5dff6690.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/librustc_demangle-ab493befe3742702.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libstd_detect-41195694489636c4.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libhashbrown-6905da49c8a1542a.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/librustc_std_workspace_alloc-bbc6290f03f92349.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libminiz_oxide-7a4683d4a82cf47c.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libadler-071583516cdbce90.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libunwind-d84b176d2f4c1334.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libcfg_if-92b7de0160f87442.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/liblibc-cff1533ea7c26263.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/liballoc-49e374c13f9e6132.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/librustc_std_workspace_core-9389dcc15b2f7f7b.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libcore-46f0fa14905fdc5c.rlib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib/libcompiler_builtins-20e1af401f90cd1c.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/riscv64gc-unknown-linux-gnu/lib" "-o" "program" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
2024-06-21T14:37:54.4823900Z = note: /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4825032Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4826130Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4827200Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4828279Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4829365Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4830474Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4831554Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4833002Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4834116Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: Relocations in generic ELF (EM: 243)
2024-06-21T14:37:54.4835237Z /usr/bin/ld: inaccessible/tmp/program.program.45572bc5f2b14090-cgu.0.rcgu.o: error adding symbols: file in wrong format
2024-06-21T14:37:54.4835971Z collect2: error: ld returned 1 exit status
2024-06-21T14:37:54.4836449Z
2024-06-21T14:37:54.4836584Z
2024-06-21T14:37:54.4836744Z error: aborting due to 1 previous error
2024-06-21T14:37:54.4836983Z
2024-06-21T14:37:54.4836990Z
2024-06-21T14:37:54.4837083Z === NEEDLE ===
2024-06-21T14:37:54.4837518Z failed to find or create the directory specified by `--temps-dir`
2024-06-21T14:37:54.4838250Z thread 'main' panicked at /checkout/tests/run-make/inaccessible-temp-dir/rmake.rs:35:14:
2024-06-21T14:37:54.4838801Z needle was not found in haystack
2024-06-21T14:37:54.4839270Z note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2024-06-21T14:37:54.4840125Z thread 'main' panicked at /checkout/tests/run-make/inaccessible-temp-dir/rmake.rs:27:5:
2024-06-21T14:37:54.4840759Z called `Result::unwrap()` on an `Err` value: Any { .. }
2024-06-21T14:37:54.4841194Z ------------------------------------------
```
</details>
By setting `--set target.riscv64gc-unknown-linux-gnu.linker=riscv64-linux-gnu-gcc` the correct linker is invoked.
## Testing
> [!NOTE]
> `riscv64gc-unknown-linux-gnu` is a [**Tier 2 with Host Tools** platform](https://doc.rust-lang.org/beta/rustc/platform-support.html), all tests may not necessarily pass! This change should only make fix existing broken tests (like `inaccessible-temp-dir`) while introducing no new breakage.
You can test out the job locally:
```sh
mv src/ci/docker/host-x86_64/disabled/riscv64gc-gnu src/ci/docker/host-x86_64/riscv64gc-gnu
DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu
```
`-Z patchable-function-entry` works like `-fpatchable-function-entry`
on clang/gcc. The arguments are total nop count and function offset.
See MCP rust-lang/compiler-team#704
Eliminate the distinction between PREC_POSTFIX and PREC_PAREN precedence level
I have been tangling with precedence as part of porting some pretty-printer improvements from syn back to rustc (related to parenthesization of closures, returns, and breaks by the AST pretty-printer).
As far as I have been able to tell, there is no difference between the 2 different precedence levels that rustc identifies as `PREC_POSTFIX` (field access, square bracket index, question mark, method call) and `PREC_PAREN` (loops, if, paths, literals).
There are a bunch of places that look at either `prec < PREC_POSTFIX` or `prec >= PREC_POSTFIX`. But there is nothing that needs to distinguish PREC_POSTFIX and PREC_PAREN from one another.
d49994b060/compiler/rustc_ast/src/util/parser.rs (L236-L237)d49994b060/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs (L2829)d49994b060/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs (L1290)
In the interest of eliminating a distinction without a difference, this PR collapses these 2 levels down to 1.
There is exactly 1 case where an expression with PREC_POSTFIX precedence needs to be parenthesized in a location that an expression with PREC_PAREN would not, and that's when the receiver of ExprKind::MethodCall is ExprKind::Field. `x.f()` means a different thing than `(x.f)()`. But this does not justify having separate precedence levels because this special case in the grammar is not governed by precedence. Field access does not have "lower precedence than" method call syntax — you can tell because if it did, then `x.f[0].f()` wouldn't be able to have its unparenthesized field access in the receiver of a method call. Because this Field/MethodCall special case is not governed by precedence, it already requires special handling and is not affected by eliminating the PREC_POSTFIX precedence level.
d49994b060/compiler/rustc_ast_pretty/src/pprust/state/expr.rs (L217-L221)
