Rustc pull update #2251
Closed
Rustc pull update #2251
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
github-actions
bot
force-pushed
the
rustc-pull
branch
from
214129f to
bd5a42f
Compare
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
github-actions
bot
force-pushed
the
rustc-pull
branch
from
bd5a42f to
9c5f907
Compare
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`
github-actions
bot
force-pushed
the
rustc-pull
branch
from
9c5f907 to
6eefa09
Compare
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
Support raw-dylib link kind on ELF 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. I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27 Tracking issue: #135694 r? bjorn3 try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various
mgca: Lower all const paths as `ConstArgKind::Path` When `#![feature(min_generic_const_args)]` is enabled, we now lower all const paths in generic arg position to `hir::ConstArgKind::Path`. We then lower assoc const paths to `ty::ConstKind::Unevaluated` since we can no longer use the anon const expression lowering machinery. In the process of implementing this, I factored out `hir_ty_lowering` code that is now shared between lowering assoc types and assoc consts. This PR also introduces a `#[type_const]` attribute for trait assoc consts that are allowed as const args. However, we still need to implement code to check that assoc const definitions satisfy `#[type_const]` if present (basically is it a const path or a monomorphic anon const). r? `@BoxyUwU`
dec2flt: Clean up float parsing modules This is the first portion of my work adding support for parsing and printing `f16`. Changes in `float.rs` replace the magic constants with expressions and add some use of generics to better support the new float types. Everything else is related to documentation or naming; there are no functional changes in this PR. This can be reviewed by commit.
Retire the legacy `Makefile`-based `run-make` test infra The final piece of [porting run-make tests to use Rust #121876](rust-lang/rust#121876). Closes #121876. Closes #40713. Closes #81791 (no longer using `wc`). Closes #56475 (no longer a problem in current form of that test; we don't ignore the test on `aarch64-unknown-linux-gnu`). ### Summary This PR removes the legacy `Makefile`-based `run-make` test infra which has served us well over the years. The legacy infra is no longer needed since we ported all of `Makefile`-based `run-make` tests to the new `rmake.rs` infra. Additionally, this PR: - Removes `tests/run-make/tools.mk` since no more `Makefile`-based tests remain. - Updates `tests/run-make/README.md` and rustc-dev-guide docs to remove mention about `Makefile`-based `run-make` tests - Update test suite requirements in rustc-dev-guide on Windows to no longer need MSYS2 (they should also now run successfully on native Windows MSVC). - Update `triagebot.toml` to stop backlinking to #121876. **Thanks to everyone who helped in this effort to modernize the `run-make` test infra and test suite!** r? bootstrap
…u-se Count char width at most once in `Formatter::pad` When both width and precision flags are specified, then `Formatter::pad` counts the character width twice. Instead, record the character width when truncating it to the precision, so it does not need to be recomputed. Simplify control flow so the cases are more clear. Related: - 6c9e708f4be (`fmt::Formatter::pad`: don't call chars().count() more than one time, 2021-09-01): Reduce counting chars from thrice to twice in worst case - ede39aeb331 (feat: reinterpret `precision` field for strings, 2016-06-29): Change meaning of precision for strings - b820748ff5a (Implement formatting arguments for strings and integers, 2013-08-10): Implement `Formatter::pad`
…ject-hard-error, r=oli-obk Make `ptr_cast_add_auto_to_object` lint into hard error In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds. This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting. We considered just making this a hard error, but opted against it at that time due to breakage found by crater. This breakage was mostly due to the `anymap` crate which has been a persistent problem for us. It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`. So let's see about making a hard error of this. r? ghost cc ```@adetaylor``` ```@Darksonn``` ```@BoxyUwU``` ```@RalfJung``` ```@compiler-errors``` ```@oli-obk``` ```@WaffleLapkin``` Related: - rust-lang/rust#135881 - rust-lang/rust#136702 - rust-lang/rust#136776 Tracking: - rust-lang/rust#127323 - rust-lang/rust#44874 - rust-lang/rust#123430
Added documentation for flushing per #74348 Resolves #74348
Perform deeper compiletest path normalization for `$TEST_BUILD_DIR` to account for compare-mode/debugger cases, and normalize long type file filename hashes Fixes #136510. ### Summary - Whereas previously `$TEST_BUILD_DIR` is a normalization of `/path/to/build/test/<test_suite_name>/`, we now more deeply normalize. `$TEST_BUILD_DIR` now becomes a normalization of `/path/to/build/test/<test_suite_name>/<subdirs>/$name.$revision.$compare_mode.$debugger/` to normalize away path name differences when `--compare-mode` and/or `--debugger` are specified. - We also centralize the normalization of long type name hashes cf. rust-lang/rust#136328 (comment). ### Review advice - Best reviewed commit-by-commit. - Split into 3 commits: - **Commit 1**: compiletest changes to have `$TEST_BUILD_DIR` more deeply normalize. - **Commit 2**: remove per-test hacks for long type path hash normalizations, and rebless tests *specifically* affected by that. - **Commit 3**: rebless other tests that were changed as a side-effect of deeper `$TEST_BUILD_DIR` normalizations. **Commit 2** is created via first finding tests that try to perform long type file hash normalizations on an ad hoc, per-test basis: ``` rg --no-ignore -l --no-ignore -F -e "long-type" tests/ui/**/*.rs ``` <details> <summary>Tests with ad hoc long-type hash normalizations</summary> ``` tests/ui/type_length_limit.rs tests/ui/traits/on_unimplemented_long_types.rs tests/ui/regions/issue-102374.rs tests/ui/recursion/recursion.rs tests/ui/recursion/issue-83150.rs tests/ui/recursion/issue-23122-2.rs tests/ui/methods/inherent-bound-in-probe.rs tests/ui/issues/issue-67552.rs tests/ui/issues/issue-37311-type-length-limit/issue-37311.rs tests/ui/issues/issue-20413.rs tests/ui/issues/issue-8727.rs tests/ui/infinite/infinite-instantiation.rs tests/ui/infinite/infinite-instantiation-struct-tail-ice-114484.rs tests/ui/higher-ranked/trait-bounds/hrtb-doesnt-borrow-self-1.rs tests/ui/higher-ranked/trait-bounds/hrtb-doesnt-borrow-self-2.rs tests/ui/higher-ranked/trait-bounds/hang-on-deeply-nested-dyn.rs tests/ui/error-codes/E0275.rs tests/ui/diagnostic-width/secondary-label-with-long-type.rs tests/ui/diagnostic-width/long-e0277.rs tests/ui/diagnostic-width/non-copy-type-moved.rs tests/ui/diagnostic-width/long-E0308.rs tests/ui/diagnostic-width/E0271.rs tests/ui/diagnostic-width/binop.rs ``` </details> These ad hoc normalizations were removed, and they are reblessed. r? `````@lqd`````
Look for `python3` first on MacOS, not `py` `py` is not installed by default *and* trying to run it results in a popup asking if you want to install it. `python3` is installed by default. This hopefully should not be too disruptive to people on Windows, since they should be going through `x.ps1` instead anyway. Just in case, I've added a check for Cygwin and Msys (i'm not sure how else you'd get a bash shell on windows). I've tested this on macOS, WSL, "git bash" (which appears to be MSYS), and MSVC with `bash -c ./x` (which runs in WSL, but differently than interactive bash 🙃). I haven't tested Cygwin, which is unsupported anyway, but the code tries to make it work.
Upload Datadog metrics with citool This removes one Python script and also the installation of the `datadog-ci` JavaScript package, along with the corresponding package and lock file. r? `@ghost`
Slightly reformat `std::fs::remove_dir_all` error docs To make the error cases easier to spot on a quick glance, as I've been bitten by this a couple of times already 💀 cc #137230.
Check signature WF when lowering MIR body Alternative to #137233. rust-lang/rust#137233 (comment) Fixes rust-lang/rust#137186 We do this check in `mir_drops_elaborated_and_const_checked` and not during `mir_promoted` because that may result in borrowck cycles if WF requires looking into an opaque hidden type. This causes some TAIT tests to fail unnecessarily. r? lcnr try-job: test-various
…lacrum [illumos] attempt to use posix_spawn to spawn processes illumos has `posix_spawn`, and the very newest versions also have `_addchdir`, so use that. POSIX standardized this function so I also added a weak symbol lookup for the non `_np` version. (illumos has both.) This probably also works on Solaris, but I don't have access to an installation to validate this so I decided to focus on illumos instead. This is a nice ~4x performance improvement for process creation. My go-to as usual is nextest against the clap repo, which acts as a stress test for process creation -- with [this commit]: ```console $ cargo nextest run -E 'not test(ui_tests) and not test(example_tests)' before: Summary [ 1.747s] 879 tests run: 879 passed, 2 skipped after: Summary [ 0.445s] 879 tests run: 879 passed, 2 skipped ``` [this commit]: clap-rs/clap@fde45f9
uefi: Add Service Binding Protocol abstraction - Some UEFI protocols such as TCP4, TCP6, UDP4, UDP6, etc are managed by service binding protocol. - A new instance of such protocols is created and destroyed using the corresponding service binding protocol. - This PR adds abstractions to make using such protocols simpler using Rust Drop trait. - The reason to add these abstractions in a seperate PR from TCP4 Protocol is to make review easier. [EFI_SERVICE_BINDING_PROTCOL](https://uefi.org/specs/UEFI/2.11/11_Protocols_UEFI_Driver_Model.html#efi-service-binding-protocol) cc ````@nicholasbishop````
Stabilize `string_extend_from_within` FCP'd here: rust-lang/rust#103806 (comment). Closes #103806.
…ss-bevy, r=lcnr Only use implied bounds hack if bevy, and use deeply normalize in implied bounds hack Consolidates the implied bounds computation mode into a single function, which deeply normalizes, and if it's in **compat** mode (for bevy), it extracts outlives bounds from the infcx. Previously, we were using the implied bounds compat mode in two cases: 1. During WF, if it detects `ParamSet` 2. EVERYWHERE ELSE (lol) -- e.g. borrowck, predicate entailment, etc. While I think this is fine, and the net effect was just that we emitted fewer diagnostics, it makes me uncomfortable that all crates were using the supposed "compat" code. Fixes #137767
…nur-ozkan Various coretests improvements The first commit is not yet strictly necessary as directly testing libcore works though useless work, but will be necessary once rust-lang/rust#136642 migrates the liballoc tests into a separate package. The second commit fixes rust-lang/rust#137478 and ensures that coretests actually gets tested on all CI job. The third commit fixes an error that didn't get caught because coretests doesn't run on the wasm32 CI job.
…ini,weihanglo Make `rust.description` more general-purpose and pass `CFG_VER_DESCRIPTION` Moves the `description` field from the `rust` section to the `build` section as it can be useful for tools and is not specific to rustc. Also passes this value to tool builds through the `CFG_VER_DESCRIPTION` env. Motivated from https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Propagate.20rust.2Edescription.20to.20tools.20in.20dist.20build
Remove unsizing coercions for tuples See rust-lang/rust#42877 (comment) and below comments for justification. Tracking issue: #42877 Fixes: #135217
Resume one waiter at once in deadlock handler When multiple query loop errors occur in the code, only one waiter should be resumed at a time to avoid waking up multiple waiters at the same time and causing deadlock due to thread grabbing. This fixes the UI failures in #132051 cc `@Zoxc` `@cjgillot` `@nnethercote` `@bjorn3` `@Kobzol` Zulip discussion [here](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fwg-parallel-rustc/topic/Deadlocks.20and.20Rayon) Edit: We can't reproduce these bugs with the existing test suits, so we keep them until we merge #132051 UPDATES #129912 UPDATES #120757 UPDATES #129911
mir_build: Integrate "simplification" steps into match-pair-tree creation The “simplification” step helps to prepare THIR patterns for lowering into MIR, and originally dates back to the earliest days of MIR in the compiler. Over time, various intermediate data structures have been introduced (e.g. `MatchPair`, later renamed to `MatchPairTree`) that reduce the need for a separate simplification step, because some of the necessary simplifications can be built into the construction of those intermediate structures instead. This PR continues that process to its logical conclusion and removes the simplification step entirely, by integrating its remaining responsibilities into match-pair-tree creation: flattening “irrefutable” nodes, collecting bindings/ascriptions in flat lists, and sorting or-patterns after other subpatterns. This has a few immediate benefits: - We can remove `TestCase::Irrefutable`, which was not allowed to exist after simplification, and was much larger than other test-case variants. - We can make `MatchPairTree::place` non-optional, because only irrefutable nodes could fail to have a place. In the future, this should also help with some ideas I have for simplifying how `AscribeUserType` and `ExpandedConstant` nodes are handled, by representing them as side-data keyed by THIR pattern ID, so that they are no longer their own kinds of THIR pattern node.
…rors compiler: add `ExternAbi::is_rustic_abi` Various parts of the compiler were hand-rolling this extremely simple check that is nonetheless easy to get wrong as the compiler evolves over time. Discourage them from being so "original" again by replacing it with a single implementation on the type that represents these ABIs. This simplifies a surprising amount of code as a result. Also fixes #132981, an ICE that emerged due to other checks being made stricter.
Rollup of 20 pull requests Successful merges: - #134063 (dec2flt: Clean up float parsing modules) - #136581 (Retire the legacy `Makefile`-based `run-make` test infra) - #136662 (Count char width at most once in `Formatter::pad`) - #136764 (Make `ptr_cast_add_auto_to_object` lint into hard error) - #136798 (Added documentation for flushing per #74348) - #136865 (Perform deeper compiletest path normalization for `$TEST_BUILD_DIR` to account for compare-mode/debugger cases, and normalize long type file filename hashes) - #136975 (Look for `python3` first on MacOS, not `py`) - #136977 (Upload Datadog metrics with citool) - #137240 (Slightly reformat `std::fs::remove_dir_all` error docs) - #137298 (Check signature WF when lowering MIR body) - #137463 ([illumos] attempt to use posix_spawn to spawn processes) - #137477 (uefi: Add Service Binding Protocol abstraction) - #137569 (Stabilize `string_extend_from_within`) - #137633 (Only use implied bounds hack if bevy, and use deeply normalize in implied bounds hack) - #137679 (Various coretests improvements) - #137723 (Make `rust.description` more general-purpose and pass `CFG_VER_DESCRIPTION`) - #137728 (Remove unsizing coercions for tuples) - #137731 (Resume one waiter at once in deadlock handler) - #137875 (mir_build: Integrate "simplification" steps into match-pair-tree creation) - #138028 (compiler: add `ExternAbi::is_rustic_abi`) r? `@ghost` `@rustbot` modify labels: rollup
Inline `FnOnce`/`FnMut`/`Fn` shims once again This PR fixes the argument checking for `extern "rust-call"` ABI functions with a spread arg, which do no expect their arguments to be exploded from a tuple like closures do. Secondly, it removes the hack that prevented them from being inlined. This results in more work done by the compiler, but it does end up allowing us to inline functions we didn't before. Fixes #137901
github-actions
bot
force-pushed
the
rustc-pull
branch
from
6eefa09 to
96aafd0
Compare
|
make obsolete by #2283 |
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.
Latest update from rustc.