readme: tweak wording around soundness
Miri *can* tell you whether your code is sound when it finds UB -- it's not sound in that case. It can give negative answers, just not positive ones.
Fix miri.bat to not exit unconditionally
#3703 has a small typo causing it to regress ./miri.bat to not working at all.
This PR fixes it. Tested on Windows 11, with stable toolchain missing as well as installed.
```test
./miri toolchain
error: toolchain 'stable-x86_64-pc-windows-msvc' is not installed
Failed to build miri-script. Is the 'stable' toolchain installed?
```
Closes#3714
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
```
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)
ast: Standardize visiting order for attributes and node IDs
This should only affect `macro_rules` scopes and order of diagnostics.
Also add a deprecation lint for `macro_rules` called outside of their scope, like in https://github.com/rust-lang/rust/issues/124535.
Add `SliceLike` to `rustc_type_ir`, use it in the generic solver code (+ some other changes)
First, we split out `TraitRef::new_from_args` which takes *just* `ty::GenericArgsRef` from `TraitRef::new` which takes `impl IntoIterator<Item: Into<GenericArg>>`. I will explain in a minute why.
Second, we introduce `SliceLike`, which allows us to be generic over `List<T>` and `[T]`. This trait has an `as_slice()` and `into_iter()` method, and some other convenience functions. However, importantly, since types like `I::GenericArgs` now implement `SliceLike` rather than `IntoIter<Item = I::GenericArg>`, we can't use `TraitRef::new` on this directly. That's where `new_from_args` comes in.
Finally, we adjust all the code to use these slice operators. Some things get simpler, some things get a bit more annoying since we need to use `as_slice()` in a few places. 🤷
r? lcnr
Deprecate no-op codegen option `-Cinline-threshold=...`
This deprecates `-Cinline-threshold` since using it has no effect. This has been the case since the new LLVM pass manager started being used, more than 2 years ago.
Recommend using `-Cllvm-args=--inline-threshold=...` instead.
Closes#89742 which is E-help-wanted.
