Invert infer `error_reporting` mod struture
Parallel change to #127493, which moves `rustc_infer::infer::error_reporting` to `rustc_infer::error_reporting::infer`. After this, we should just be able to merge this into `rustc_trait_selection::error_reporting::infer`, and pull down `TypeErrCtxt` into that crate. 👍
r? lcnr
Promote the `wasm32-wasip2` target to Tier 2
This commit promotes the `wasm32-wasip2` Rust target to tier 2 as proposed in rust-lang/compiler-team#760. There are two major changes in this PR:
1. The `dist-various-2` container, which already produces the other WASI targets, now has an extra target added for `wasm32-wasip2`.
2. A new `wasm-component-ld` binary is added to all host toolchains when LLD is enabled. This is the linker used for the `wasm32-wasip2` target.
This new linker is added for all host toolchains to ensure that all host toolchains can produce the `wasm32-wasip2` target. This is similar to how `rust-lld` was originally included for all host toolchains to be able to produce WebAssembly output when the targets were first added. The new linker is developed [here][wasm-component-ld] and is pulled in via a crates.io-based dependency to the tree here.
[wasm-component-ld]: https://github.com/bytecodealliance/wasm-component-ld
Migrate `std-core-cycle`, `obey-crate-type-flag`, `mixing-libs` and `issue-18943` `run-make` tests to `rmake.rs`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: x86_64-apple-1
try-job: x86_64-msvc
try-job: aarch64-gnu
run-make-support: update gimli to 0.31.0
This version bump is required for the tests in #126985 as suggested [here](https://github.com/rust-lang/rust/pull/126985#issuecomment-2196745112).
r? tgross35
(^ that didn't work. cc `@tgross35)`
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: dist-x86_64-linux
Fix and enforce `unsafe_op_in_unsafe_fn` in compiler
In preparation for edition 2024, this PR previews the fallout of enabling the `unsafe_op_in_unsafe_fn` lint in the compiler, since it's defaulting to warn in the new edition (#112038).
The major annoyance comes primarily from the `rustc_codegen_llvm` module, where there's a ton of unsafe calls. I tended to wrap individual calls to unsafe fns in `unsafe {}`, but there a handful of places I chose to just wrap several calls in an `unsafe {}` block just because it would've been excessive to wrap each call individually.
This doesn't enable the lint for the standard library, since I'm not totally certain what T-libs prefers w/ this lint.
Rollup of 6 pull requests
Successful merges:
- #120990 (Suggest a borrow when using dbg)
- #127047 (fix least significant digits of f128 associated constants)
- #127709 (match lowering: Move `MatchPair` tree creation to its own module)
- #127770 (Update books)
- #127780 (Make sure trait def ids match before zipping args in `note_function_argument_obligation`)
- #127795 (Fix typos in RELEASES.md)
r? `@ghost`
`@rustbot` modify labels: rollup
Update books
## rust-lang/book
3 commits in f1e49bf7a8ea6c31ce016a52b8a4f6e1ffcfbc64..67fa536768013d9d5a13f3a06790521d511ef711
2024-07-12 21:21:45 UTC to 2024-07-05 17:35:06 UTC
- Use Rust 2021 Edition for mdBook (rust-lang/book#3974)
- Backport changes to chapter 11 (rust-lang/book#3969)
- Upgrade to Rust 1.79.0 (rust-lang/book#3968)
## rust-lang/edition-guide
2 commits in 941db8b3df45fd46cd87b50a5c86714b91dcde9c..5454de3d12b9ccc6375b629cf7ccda8264640aac
2024-07-14 07:06:34 UTC to 2024-07-12 06:05:29 UTC
- Update timeline etc. for Rust 2024
- 2024: Add note about never_type_fallback_flowing_into_unsafe lint level. (rust-lang/edition-guide#311)
## rust-embedded/book
1 commits in b10c6acaf0f43481f6600e95d4b5013446e29f7a..019f3928d8b939ec71b63722dcc2e46330156441
2024-07-11 17:46:10 UTC to 2024-07-11 17:46:10 UTC
- typo on tooling.md (rust-embedded/book#373)
## rust-lang/reference
9 commits in 1ae3deebc3ac16e276b6558e01420f8e605def08..e2f0bdc4031866734661dcdb548184bde1450baf
2024-06-29 16:59:51 +0000 to 2024-07-15 17:52:44 +0000
- Suppress type length limit test and note that it is not enforced (rust-lang/reference#1527)
- elaborate on slice wide pointer metadata (rust-lang/reference#1499)
- '.inst' in inline-assembly changed to '.insn' (rust-lang/reference#1453)
- Clarify that `asm!` blocks can be duplicated or deduplicated by the compiler (rust-lang/reference#1441)
- Add mdbook-spec (rust-lang/reference#1520)
- Add note about static libraries not linking their dependencies (rust-lang/reference#1472)
- more explicitly explain the UB around immutable extern statics (rust-lang/reference#1502)
- Improvements to `items/functions.md` (rust-lang/reference#1458)
- Enable mdbook smart-punctuation. (rust-lang/reference#1516)
## rust-lang/rust-by-example
1 commits in 658c6c27cb975b92227936024816986c2d3716fb..89aecb6951b77bc746da73df8c9f2b2ceaad494a
2024-07-11 12:33:43 UTC to 2024-07-11 12:33:43 UTC
- Update option_result.md (rust-lang/rust-by-example#1864)
## rust-lang/rustc-dev-guide
6 commits in d6e3a32a557db5902e714604def8015d6bb7e0f7..0c4d55cb59fe440d1a630e4e5774d043968edb3f
2024-07-15 15:16:43 UTC to 2024-07-01 19:05:14 UTC
- Improve documentation of MIR queries & passes (rust-lang/rustc-dev-guide#1434)
- Bump dependencies for date-check tool (rust-lang/rustc-dev-guide#2012)
- Fix typo: lists -> lints (rust-lang/rustc-dev-guide#2011)
- use "bootstrap" instead of "rustbuild" (rust-lang/rustc-dev-guide#2010)
- Fix grammar issue in optimize-build.md (rust-lang/rustc-dev-guide#2009)
- Update name of Fuchsia builder (rust-lang/rustc-dev-guide#2008)
Bootstrap command refactoring: port remaining commands with access to `Build` (step 6)
Continuation of https://github.com/rust-lang/rust/pull/127450.
This PR ports commands in bootstrap that can easily get access to `Build(er)` to `BootstrapCommand`. After this PR, everything that can access `Build(er)` should be using the new API.
Statistics of `bootstrap` code (ignoring `src/bin/<shims>`) after this PR:
```
7 usages of `Command::new`
69 usages of `command()` (new API)
- out of that: 16 usages of `as_command_mut()` (new API, but accesses the inner command)
```
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
Switch it to using a just-built standard library which enables it to be
cross compiled. Additionally allow it access to `min_specialization`
which `ahash`, a dependency, wants.
Stop using the `gen` identifier in the compiler
In preparation for edition 2024, this PR previews the fallout of removing usages of `gen` since it's being reserved as a keyword.
There are two notable changes here:
1. Had to rename `fn gen(..)` in gen/kill analysis to `gen_`. Not certain there's a better name than that.
2. There are (false?[^1]) positives in `rustc_macros` when using synstructure, which uses `gen impl` to mark an implementation. We could suppress this in a one-off way, or perhaps just ignore `gen` in macros altogether, since if an identifier ends up in expanded code then it'll get properly denied anyways.
Not relevant to the compiler, but it's gonna be really annoying to change `rand`'s `gen` fn in the library and miri...
[^1]: I haven't looked at the synstructure proc macro code itself so I'm not certain if it'll start to fail when converted to ed2024 (or, e.g., when syn starts parsing `gen` as a kw).
offset_from: always allow pointers to point to the same address
This PR implements the last remaining part of the t-opsem consensus in https://github.com/rust-lang/unsafe-code-guidelines/issues/472: always permits offset_from when both pointers have the same address, no matter how they are computed. This is required to achieve *provenance monotonicity*.
Tracking issue: https://github.com/rust-lang/rust/issues/117945
### What is provenance monotonicity and why does it matter?
Provenance monotonicity is the property that adding arbitrary provenance to any no-provenance pointer must never make the program UB. More specifically, in the program state, data in memory is stored as a sequence of [abstract bytes](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#abstract-byte), where each byte can optionally carry provenance. When a pointer is stored in memory, all of the bytes it is stored in carry that provenance. Provenance monotonicity means: if we take some byte that does not have provenance, and give it some arbitrary provenance, then that cannot change program behavior or introduce UB into a UB-free program.
We care about provenance monotonicity because we want to allow the optimizer to remove provenance-stripping operations. Removing a provenance-stripping operation effectively means the program after the optimization has provenance where the program before the optimization did not -- since the provenance removal does not happen in the optimized program. IOW, the compiler transformation added provenance to previously provenance-free bytes. This is exactly what provenance monotonicity lets us do.
We care about removing provenance-stripping operations because `*ptr = *ptr` is, in general, (likely) a provenance-stripping operation. Specifically, consider `ptr: *mut usize` (or any integer type), and imagine the data at `*ptr` is actually a pointer (i.e., we are type-punning between pointers and integers). Then `*ptr` on the right-hand side evaluates to the data in memory *without* any provenance (because [integers do not have provenance](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html#integers-do-not-have-provenance)). Storing that back to `*ptr` means that the abstract bytes `ptr` points to are the same as before, except their provenance is now gone. This makes `*ptr = *ptr` a provenance-stripping operation (Here we assume `*ptr` is fully initialized. If it is not initialized, evaluating `*ptr` to a value is UB, so removing `*ptr = *ptr` is trivially correct.)
### What does `offset_from` have to do with provenance monotonicity?
With `ptr = without_provenance(N)`, `ptr.offset_from(ptr)` is always well-defined and returns 0. By provenance monotonicity, I can now add provenance to the two arguments of `offset_from` and it must still be well-defined. Crucially, I can add *different* provenance to the two arguments, and it must still be well-defined. In other words, this must always be allowed: `ptr1.with_addr(N).offset_from(ptr2.with_addr(N))` (and it returns 0). But the current spec for `offset_from` says that the two pointers must either both be derived from an integer or both be derived from the same allocation, which is not in general true for arbitrary `ptr1`, `ptr2`.
To obtain provenance monotonicity, this PR hence changes the spec for offset_from to say that if both pointers have the same address, the function is always well-defined.
### What further consequences does this have?
It means the compiler can no longer transform `end2 = begin.offset(end.offset_from(begin))` into `end2 = end`. However, it can still be transformed into `end2 = begin.with_addr(end.addr())`, which later parts of the backend (when provenance has been erased) can trivially turn into `end2 = end`.
The only alternative I am aware of is a fundamentally different handling of zero-sized accesses, where a "no provenance" pointer is not allowed to do zero-sized accesses and instead we have a special provenance that indicates "may be used for zero-sized accesses (and nothing else)". `offset` and `offset_from` would then always be UB on a "no provenance" pointer, and permit zero-sized offsets on a "zero-sized provenance" pointer. This achieves provenance monotonicity. That is, however, a breaking change as it contradicts what we landed in https://github.com/rust-lang/rust/pull/117329. It's also a whole bunch of extra UB, which doesn't seem worth it just to achieve that transformation.
### What about the backend?
LLVM currently doesn't have an intrinsic for pointer difference, so we anyway cast to integer and subtract there. That's never UB so it is compatible with any relaxation we may want to apply.
If LLVM gets a `ptrsub` in the future, then plausibly it will be consistent with `ptradd` and [consider two equal pointers to be inbounds](https://github.com/rust-lang/rust/pull/124921#issuecomment-2205795829).
use std for file mtime and atime modifications
Since 1.75 std provides an interface to set access and modified times on files. This change replaces the external dependency previously used for these operations with the corresponding std functions.
handle ci-rustc incompatible options during config parse
This PR ensures that `config.toml` does not use CI rustc incompatible options when CI rustc is enabled (just like [ci-llvm checks](e2cf31a614/src/bootstrap/src/core/config/config.rs (L1809-L1836))). Some options can change compiler's behavior in certain scenarios. If we don't check these incompatible options, CI runners using CI rustc might ignore options we have explicitly set. This could be dangerous as we might think a rustc test passed with option T but in fact it wasn't tested with option T.
Later in https://github.com/rust-lang/rust/pull/122709, I will disable CI rustc if any of those options were used (similar to [this approach](dd2c24aafd/src/ci/run.sh (L165-L169))). If CI runners fail because of these checks, it means the logic in run.sh isn't covering the incompatible options correctly (since any incompatible option should turn off CI rustc).
The list may not be complete, but should be a good first step as it's better than nothing!
Blocker for https://github.com/rust-lang/rust/pull/122709
use "bootstrap" instead of "rustbuild" in comments and docs
Let's stick with the single name "bootstrap" to refer to the bootstrap project to avoid confusion. This should make it clearer, especially for new contributors.
using correct tool mode for `run-make-support` crate
We don't need to ensure std (and rustc) for testing run-make-support's unit tests. Using stage 0 compiler is already enough and speeds up `x test run-make-support` invocations on a clean build.
Remove memory leaks in doctests in `core`, `alloc`, and `std`
cc `@RalfJung` https://github.com/rust-lang/rust/issues/126067https://github.com/rust-lang/miri/issues/3670
Should be no actual *documentation* changes[^1], all added/modified lines in the doctests are hidden with `#`,
This PR splits the existing memory leaks in doctests in `core`, `alloc`, and `std` into two general categories:
1. "Non-focused" memory leaks that are incidental to the thing being documented, and/or are easy to remove, i.e. they are only there because preventing the leak would make the doctest less clear and/or concise.
- These doctests simply have a comment like `# // Prevent leaks for Miri.` above the added line that removes the memory leak.
- [^2]Some of these would perhaps be better as part of the public documentation part of the doctest, to clarify that a memory leak can happen if it is not otherwise mentioned explicitly in the documentation (specifically the ones in `(A)Rc::increment_strong_count(_in)`).
2. "Focused" memory leaks that are intentional and documented, and/or are possibly fragile to remove.
- These doctests have a `# // FIXME` comment above the line that removes the memory leak, with a note that once `-Zmiri-disable-leak-check` can be applied at test granularity, these tests should be "un-unleakified" and have `-Zmiri-disable-leak-check` enabled.
- Some of these are possibly fragile (e.g. unleaking the result of `Vec::leak`) and thus should definitely not be made part of the documentation.
This should be all of the leaks currently in `core` and `alloc`. I only found one leak in `std`, and it was in the first category (excluding the modules `@RalfJung` mentioned in https://github.com/rust-lang/rust/issues/126067 , and reducing the number of iterations of [one test](https://github.com/rust-lang/rust/blob/master/library/std/src/sync/once_lock.rs#L49-L94) from 1000 to 10)
[^1]: assuming [^2] is not added
[^2]: backlink
Since 1.75 std provides an interface to set access and modified times on files.
This change replaces the external dependency previously used for these operations
with the corresponding std functions.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
We don't need to ensure std (and rustc) for testing run-make-support's
unit tests. Using stage 0 compiler is already enough and speeds up
`x test run-make-support` invocations on a clean build.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Bootstrap command refactoring: improve debuggability (step 5)
Continuation of https://github.com/rust-lang/rust/pull/127321.
This PR improves the debuggability of command execution, by improving the output logged when a command fails (it now includes the exact location where the command was created and where it was executed), and also by adding a "drop bomb", which will panic if a command was created, but not executed (which is probably a bug).
Here is how the output of a failed command looks like:
```
Command "git" "foo" "[bar]" (failure_mode=Exit, stdout_mode=Capture, stderr_mode=Capture) did not execute successfully.
Expected success, got exit status: 1
Created at: src/core/build_steps/compile.rs:1699:9
Executed at: src/core/build_steps/compile.rs:1699:58
STDOUT ----
STDERR ----
git: 'foo' is not a git command. See 'git --help'.
```
And this is what is printed if you forget to execute a command:
```
thread 'main' panicked at /projects/personal/rust/rust/src/tools/build_helper/src/drop_bomb/mod.rs:42:13:
command constructed at `src/core/build_steps/compile.rs:1699:9` was dropped without being executed: `git`
```
Best reviewed commit by commit.
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
Fix incorrect NDEBUG handling in LLVM bindings
We currently compile our LLVM bindings using `-DNDEBUG` if debuginfo for LLVM is disabled. However, `NDEBUG` doesn't have any relation to debuginfo, it controls whether assertions are enabled.
Split the LLVM_NDEBUG environment variable into two, so that assertions and debuginfo are controlled independently.
After this change, `LLVMRustDIBuilderInsertDeclareAtEnd` triggers an assertion failure on LLVM 19 due to an incorrect cast. Fix it by removing the unused return value entirely.
r? `@cuviper`
Rollup of 11 pull requests
Successful merges:
- #126502 (Ignore allocation bytes in some mir-opt tests)
- #126922 (add lint for inline asm labels that look like binary)
- #127209 (Added the `xop` target-feature and the `xop_target_feature` feature gate)
- #127310 (Fix import suggestion ice)
- #127338 (Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake)
- #127381 (Migrate `issue-83045`, `rustc-macro-dep-files` and `env-dep-info` `run-make` tests to rmake)
- #127535 (Fire unsafe_code lint on unsafe extern blocks)
- #127619 (Suggest using precise capturing for hidden type that captures region)
- #127631 (Remove `fully_normalize`)
- #127632 (Implement `precise_capturing` support for rustdoc)
- #127660 (Rename the internal `const_strlen` to just `strlen`)
r? `@ghost`
`@rustbot` modify labels: rollup
Implement `precise_capturing` support for rustdoc
Implements rustdoc (+json) support for local (i.e. non-cross-crate-inlined) RPITs with `use<...>` precise capturing syntax.
Tests kinda suck. They're really hard to write 😰
r? `@fmease` or re-roll if you're too busy!
also cc `@aDotInTheVoid` for the json side
Tracking:
* https://github.com/rust-lang/rust/issues/127228#issuecomment-2201443216 (not fully fixed for cross-crate-inlined opaques)
* https://github.com/rust-lang/rust/issues/123432
Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: armhf-gnu
// try-job: test-various // already tried
try-job: x86_64-msvc
try-job: aarch64-apple
Ensure floats are returned losslessly by the Rust ABI on 32-bit x86
Solves #115567 for the (default) `"Rust"` ABI. When compiling for 32-bit x86, this PR changes the `"Rust"` ABI to return floats indirectly instead of in x87 registers (with the exception of single `f32`s, which this PR returns in general purpose registers as they are small enough to fit in one). No change is made to the `"C"` ABI as that ABI requires x87 register usage and therefore will need a different solution.
