Rustc pull #2283
Merged
Rustc pull #2283
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Build GCC on CI Previously, we have downloaded a specific commit of GCC and prebuilt it inside Docker using the `build-gccjit.sh` script. This PR removes that scripts and uses the bootstrap GCC step. This allows us to use the `src/gcc` submodule for determining which GCC should be built, and it also moves the logic closer to LLVM, which is also built by bootstrap. A few things to note: - The `sccache` option is currently in the `llvm` block, so the GCC build uses `llvm.ccache`, which is a bit weird :) We could either add `gcc.ccache`, or (what I think would be better) to just move `ccache` to the `build` section, as I don't think that it will be necessary to use ccache for LLVM, but not for GCC. - When the GCC codegen backend is built, it needs to depend on a step that first builds GCC. This is currently done in a hacky way. The proper solution is to create a separate step for the GCC codegen backend, but that is a larger change. Let me know what you think. r? `@onur-ozkan` try-job: i686-msvc-1 try-job: x86_64-mingw-1
Include version number of libs being built in cargo lib metadata (esp. `librustc_driver*.so`)
Previously, on a non-stable channel, it's possible for two builds from different versioned sources (e.g. 1.84.0 vs 1.84.1) to produce a `librustc_driver*.so` with the same filename hashes. This causes problems with side-by-side installs wrt. linker search paths because 1.84.1 rustc bin and 1.84.0 rustc bin may try to link to the "same" `librustc_driver*.so` (same filename hash) but fail because the contents of the so is actually different.
We try to mitigate this by including the version number of artifacts being built via `__CARGO_DEFAULT_LIB_METADATA` (kind of an ugly hack, but I don't think cargo has a way for us to tell cargo to use a package version override).
Fixes #136701 (mitigates, really).
### Testing
Tested manually[^host] by:
```bash
$ cat src/version
1.86.0
$ ./x build library # w/ compiler profile, (non-stable) dev channel
$ lddtree build/host/stage1/bin/rustc
rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2)
librustc_driver-ea1b1b2291881cc4.so => build/host/stage1/bin/../lib/librustc_driver-ea1b1b2291881cc4.so
[...]
```
and observing that changing `src/version` to bump a point release causes `librustc_driver*.so` to have a different hash while sources are unmodified otherwise.
```bash
$ cat src/version
1.86.1
$ ./x build library # w/ compiler profile, (non-stable) dev channel
$ lddtree build/host/stage1/bin/rustc
rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2)
librustc_driver-746badadbcb74721.so => build/host/stage1/bin/../lib/librustc_driver-746badadbcb74721.so
[...]
```
cc `@clan` `@demize` could you check that if you backport this change against 1.84.{0,1} as reported in #136701, that the produced `rustc` binary works, under the context of the Gentoo build system setup?
[^host]: on a `x86_64-unknown-linux-gnu` host, no cross
Change interners to start preallocated with an increased capacity Inspired by rust-lang/rust#137005. Added a `with_capacity` function to `InternedSet`. Changed the `CtxtInterners` to start with `InternedSets` preallocated with a capacity. This *does* increase memory usage at very slightly(by ~1 MB at the start), altough that increase quickly disaperars for larger crates(since they require such capacity anyway). A local perf run indicates this improves compiletimes for small crates(like `ripgrep`), without a negative effect on larger ones.
remove `MaybeUninit::uninit_array` Closes #134584. Closes #66845. The future of this unstable method was described in rust-lang/rust#125082 (comment). Since `inline_const` was stabilized in 1.79 (4 stable releases away) and no one expressed interest for keeping it in rust-lang/rust#96097, I think it can be removed now as it is not a stable method.
Use less CString in the examples of CStr. Fixes #83999
Avoid collecting associated types for undefined trait Fixes #137508 Fixes #137554
Rustc dev guide subtree update r? ``@Kobzol`` ``@jieyouxu``
Update gcc submodule To add support for the x87 feature (see rust-lang/rust#137612 (comment)). r? `@antoyo`
revert accidental change in get_closest_merge_commit This was accidentally merged as part of rust-lang/rust#137594. I need this local diff to be able to debug miri syncs, and then typed `git commit -a` too fast and didn't realize it includes this change... sorry for that. r? ``@Kobzol``
Make -Z unpretty=mir suggest -Z dump-mir as well for discoverability While debugging something else, I got quite annoyed with `-Z unpretty=mir` showing me post-processed MIR instead of the one just after it is built. I ended up asking on Zulip and got pointed to `-Z dump-mir`. While this feature is documented in the rustc dev guide, I think it'd be good if the possibility of making use of it was staring you in the face while you need it.
raw-dylib is a link kind that allows rustc to link against a library without having any library files present. This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker. While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future. This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.
Rollup of 10 pull requests Successful merges: - #134585 (remove `MaybeUninit::uninit_array`) - #136187 (Use less CString in the examples of CStr.) - #137201 (Teach structured errors to display short `Ty<'_>`) - #137620 (Fix `attr` cast for espidf) - #137631 (Avoid collecting associated types for undefined trait) - #137635 (Don't suggest constraining unstable associated types) - #137642 (Rustc dev guide subtree update) - #137660 (Update gcc submodule) - #137670 (revert accidental change in get_closest_merge_commit) - #137671 (Make -Z unpretty=mir suggest -Z dump-mir as well for discoverability) r? `@ghost` `@rustbot` modify labels: rollup
…zkan fixed wast version was released, remove randomization exemption
Don't infer attributes of virtual calls based on the function body Fixes (after backport) #137646. Since we don't know the exact implementation of the virtual call, it might write to parameters, we can't infer the readonly attribute.
The embedded bitcode should always be prepared for LTO/ThinLTO Fixes #115344. Fixes #117220. There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`. When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module. This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`. r? nikic
And remove outdated requirements to run `run-make` tests on Windows.
Rewrite the `ci.py` script in Rust It would seem that I would learn by now that any script written in Python will become unmaintainable sooner or later, but alas.. r? `@marcoieni` try-job: aarch64-gnu try-job: dist-x86_64-linux-alt try-job: x86_64-msvc-ext2 Fixes: rust-lang/rust#137013
…x, r=GuillaumeGomez `librustdoc`: return `impl fmt::Display` in more places instead of writing to strings Continuation of #136784 , another attempt at landing the larger parts of #136748 . I'd like to, gradually, make all of the building blocks for rendering docs in `librustdoc` return `impl fmt::Display` instead of returning `Strings`, or receiving a `&mut String` (or `&mut impl fmt::Write`). Another smaller end goal is to be able to get rid of [`write_str`](https://github.com/rust-lang/rust/blob/8dac72bb1d12b2649acd0c190e41524f83da5683/src/librustdoc/html/format.rs#L40-L42). This PR is a large step in that direction. Most of the changes are quite mechanical, and split up into separate commits for easier reviewing (hopefully). I took `print_item` and then started by converting all the functions it called (and their dependencies), and the last commit does the conversion for `print_item` itself. Ignoring whitespace should make reviewing a bit easier. And most importantly, perf run shows pretty good results locally, hopefully CI will also show green 😁 r? `@GuillaumeGomez` , if you feel like it.
Update to LLVM 20 rc 3 Fixes a compiler-builtins miscompile (see rust-lang/compiler-builtins#760).
…i-obk Optimize empty provenance range checks. Currently it gets the pointers in the range and checks if the result is empty, but it can be done faster if you combine those two steps. r? `@oli-obk`
With the removal of `cfg(parallel_compiler)`, these are always shared references and `std::sync::OnceLock`.
…rkingjubilee Remove layouting dead code for non-array SIMD types. These aren't supported anymore, and are already rejected in type checking.
…obzol do not build additional stage on compiler paths When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler, which is clearly not what we requested. This doesn't happen when running `x build --stage N` without explicitly targeting the compiler. The changes applied fix this issue. r? ghost
Revert "store ScalarPair via memset when one side is undef and the other side can be memset" cc #137892 reverts #135335 r? oli-obk
A few cleanups after the removal of `cfg(not(parallel))` I noticed a few small things that are no longer needed after the removal of `cfg(not(parallel))` in #132282. One of the later changes adjusts several imports, so viewing the changes individually is recommended. r? SparrowLii (or reroll)
fix order on shl impl this doesn't fix any bugs, it makes shl_impl_all! look more consistent with the other impl's in core/ops/bit.rs
Fix docker run-local docs This fixes the docker run-local docs to have a valid cargo command.
…TheVoid,jieyouxu Always allow rustdoc-json tests to contain long lines The rustdoc-json test syntax often requires very long lines, so the checks for long lines aren't really useful. `@aDotInTheVoid` told me she'd like this and r? jieyouxu you're gonna tell me that the implementation is terrible. at least the performance seems reasonable: 2.5s after and 2.5s before.
…ouxu triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search This happened because `test/rustdoc-js` is a prefix of `test/rustdoc-json`, and triagebot works on prefixes. Maybe this should be fixed in triagebot, but this works now. This happened on #137956 and #137955.
Remove `NtItem` and `NtStmt` Another piece of #124141. r? `@petrochenkov`
Stabilize `std::io::ErrorKind::InvalidFilename` FCP complete: rust-lang/rust#130192 (comment) Tracking issues: #86442 & #130192 This PR: - Stabilizes `InvalidFilename` without changing its name to `InvalidFileName`. - Fixes the doc comment (rust-lang/rust#130192 (comment)) - Does not separate "the name is too long" case into a separate `ErrorKind`. That case is currently documented to be covered by `InvalidFilename` in the doc. I'm not sure if it would be possible to change this later or if that would be an unacceptable breaking change. - Does not map more raw OS errors to this `ErrorKind` (as suggested in rust-lang/rust#86442 (comment)). This can presumably be addressed later.
Move methods from Map to TyCtxt, part 4. A follow-up to rust-lang/rust#137350. r? ```@Zalathar```
Support rmeta inputs for --crate-type=bin --emit=obj This already works for --emit=metadata, but is possible anytime we're not linking. Tests: - `rmeta_bin` checks we're not changing --emit=link (already passes) - `rmeta_bin-pass` tests the new behavior for --emit=obj (would fail today) and also --emit=metadata which isn't changing
Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs
In #137617, the `ConstParamTy` rib was adjusted to act kinda like the `ForwardGenericParamBan`. However, this means that it no longer served its purpose banning generics from *parent items*. Although we still are checking for param type validity using the `ConstParamTy_` trait, which means that we weren't accepting code we shouldn't, I think it's a bit strange for us not to be rejecting code like this during *resolution* and instead letting these malformed const generics leak into the type system:
```rust
trait Foo<T> {
fn bar<const N: T>() {}
}
```
This PR does a few things:
1. Introduce a `ForwardGenericParamBanReason` enum, and start using the `ForwardGenericParamBan` rib to ban forward-declared params in const tys when `generic_const_parameter_types` is enabled.
2. Start using the `ConstParamTy` rib to ban *all* generics when `generic_const_parameter_types` is disabled.
3. Improve the diagnostics for both of the cases above, and for forward-declared params in parameter defaults too :3
r? `@BoxyUwU` or reassign
…rrors fix ICE in pretty-printing `global_asm!` fixes rust-lang/rust#138260 since rust-lang/rust#137180, `global_asm!` gets a fake body, that the pretty printing logic did not know what to do with. based on [#t-compiler/help > tests for MIR pretty printing](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/tests.20for.20MIR.20pretty.20printing) I created `tests/ui/unpretty/mir` which seemed as good a place as any for a test. If there is a better place, let me know. try-job: test-various try-job: x86_64-apple-2
…art2, r=notriddle Rustdoc: remove a bunch of @ts-expect-error from main.js r? ```````@notriddle``````` Most remaining instances of ````````@ts-expect-error```````` in `search.js` and `main.js` are some sort of unchecked assertion, most of them involving nullibility, and we have yet to decide on how to handle these.
…ur-ozkan,jieyouxu Use `RUSTC_LINT_FLAGS` more An alternative to the failed #138084. Fixes #138106. r? `````@jieyouxu`````
…errors merge `TypeChecker` and `TypeVerifier` Stacked on top of #138354. Best reviewed commit by commit. r? `@compiler-errors`
remove unnecessary variant
Delegation: one more ICE fix for `MethodCall` generation self-explanatory Fixes rust-lang/rust#138362 r? `@petrochenkov`
Delegation: reject C-variadics The explanation is contained in attached issues. Fixes rust-lang/rust#127443 Fixes rust-lang/rust#127413 r? `@petrochenkov`
Use sa_sigaction instead of sa_union.__su_sigaction for AIX Revert test cases to use `sa_sigaction` instead of `sa_union.__su_sigaction`, now that the `libc` crate implementation for AIX defines `sa_sigaction` as a direct member of `struct sigaction`, aligning it with implementations on other similar platforms. ([[AIX] Use sa_sigaction instead of the union](rust-lang/libc#4250)).
Calculate predecessor count directly Avoid allocating a vector of small vectors merely to determine how many predecessors each basic block has. Additionally use u8 and saturating operations. The pass only needs to distinguish between [0..1] and [2..].
Rollup of 12 pull requests Successful merges: - #134076 (Stabilize `std::io::ErrorKind::InvalidFilename`) - #137504 (Move methods from Map to TyCtxt, part 4.) - #138175 (Support rmeta inputs for --crate-type=bin --emit=obj) - #138259 (Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs) - #138280 (fix ICE in pretty-printing `global_asm!`) - #138318 (Rustdoc: remove a bunch of `@ts-expect-error` from main.js) - #138331 (Use `RUSTC_LINT_FLAGS` more) - #138357 (merge `TypeChecker` and `TypeVerifier`) - #138394 (remove unnecessary variant) - #138403 (Delegation: one more ICE fix for `MethodCall` generation) - #138407 (Delegation: reject C-variadics) - #138409 (Use sa_sigaction instead of sa_union.__su_sigaction for AIX) r? `@ghost` `@rustbot` modify labels: rollup
jieyouxu
commented
Mar 13, 2025
Comment on lines
141
to
+142
| - Stage: `stage1`, `stage2` | ||
| - Binary format: `elf` |
There was a problem hiding this comment.
This merge conflicted due to stage0 being removed and binary format getting added next to it.
Kobzol
approved these changes
Mar 13, 2025
|
Merging. |
|
sync PRs closing rust issues open to track backports is unfortunate 😓 |
|
oh wtf |
|
I can't even see which issue got closed from here, I'll have to revisit my notifications |
|
rust-lang/rust#137186 (comment) it's like what happens for forks now |
|
Really annoying :( I can't even tell that happened lmao |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a merge conflict in test directives that I resolved.