-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Rollup of 5 pull requests #143250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Rollup of 5 pull requests #143250
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
It is only used within cg_llvm.
It is only used within cg_llvm.
And move passing it to the linker to the driver code.
This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.
…=bjorn3 Replace ad-hoc ABI "adjustments" with an `AbiMap` to `CanonAbi` Our `conv_from_spec_abi`, `adjust_abi`, and `is_abi_supported` combine to give us a very confusing way of reasoning about what _actual_ calling convention we want to lower our code to and whether we want to compile the resulting code at all. Instead of leaving this code as a miniature adventure game in which someone tries to combine stateful mutations into a Rube Goldberg machine that will let them escape the maze and arrive at the promised land of codegen, we let `AbiMap` devour this complexity. Once you have an `AbiMap`, you can answer which `ExternAbi`s will lower to what `CanonAbi`s (and whether they will lower at all). Removed: - `conv_from_spec_abi` replaced by `AbiMap::canonize_abi` - `adjust_abi` replaced by same - `Conv::PreserveAll` as unused - `Conv::Cold` as unused - `enum Conv` replaced by `enum CanonAbi` target-spec.json changes: - If you have a target-spec.json then now your "entry-abi" key will be specified in terms of one of the `"{abi}"` strings Rust recognizes, e.g. ```json "entry-abi": "C", "entry-abi": "win64", "entry-abi": "aapcs", ```
Many of `std`'s dependency have a dependency on the crates.io `compiler-builtins` when used with the feature `rustc-std-workspace-core`. Use a Cargo patch to select the in-tree version instead. `compiler-builtins` is also added as a dependency of `rustc-std-workspace-core` so these crates can remove their crates.io dependency in the future.
… r=workingjubilee store `target.min_global_align` as an `Align` Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
…ieyouxu Remove all unused feature gates from the compiler
…o enable retpoline-related target features
…jorn3 Use the in-tree `compiler-builtins` for the sysroot Many of `std`'s dependency have a dependency on the crates.io `compiler-builtins` when used with the feature `rustc-std-workspace-core`. Use a Cargo patch to select the in-tree version instead. `compiler-builtins` is also added as a dependency of `rustc-std-workspace-core` so these crates can remove their crates.io dependency in the future. Zulip discussion: [#t-compiler > Using in-tree compiler-builtins](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Using.20in-tree.20compiler-builtins/with/522445336) Once this merges, the following PRs will need to make it to a release for the relevant crates: - rust-lang/getopts#119 (can merge at any time) - rust-lang/hashbrown#625 (can merge at any time) - rust-lang/stdarch#1825 - rust-lang/rustc-demangle#80 - rust-lang/cfg-if#84 - unicode-rs/unicode-width#77 The above should cover all tier 1 targets with no `std` features enabled. The remaining cover the rest: - alexcrichton/dlmalloc-rs#50 (wasm, xous, sgx) - gimli-rs/gimli#769 - r-efi/r-efi#89 (efi) - r-efi/r-efi-alloc#9 (efi) - fortanix/rust-sgx#770 (sgx) - hermit-os/hermit-rs#718 (hermit) - bytecodealliance/wasi-rs#108 (wasi) - gimli-rs/addr2line#345 - oyvindln/adler2#2 - BurntSushi/memchr#180 - Frommi/miniz_oxide#173 - gimli-rs/object#777 try-job: x86_64-gnu try-job: test-various
…twco retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features `-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates). * Enables target features for `-Zretpoline-external-thunk`: `+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`. * Enables target features for `-Zretpoline`: `+retpoline-indirect-branches`, `+retpoline-indirect-calls`. It corresponds to clang -mretpoline & -mretpoline-external-thunk flags. Also this PR forbids to specify those target features manually (warning). Issue: rust-lang#116852
add `extern "custom"` functions tracking issue: rust-lang#140829 previous discussion: rust-lang#140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? `@traviscross` cc `@tgross35` try-job: x86_64-apple-2
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#128425 (Make `missing_fragment_specifier` an unconditional error) - rust-lang#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - rust-lang#140770 (add `extern "custom"` functions) - rust-lang#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - rust-lang#142248 (Add supported asm types for LoongArch32) - rust-lang#142267 (assert more in release in `rustc_ast_lowering`) - rust-lang#142274 (Update the stdarch submodule) - rust-lang#142276 (Update dependencies in `library/Cargo.lock`) - rust-lang#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - rust-lang#140920 (Extract some shared code from codegen backend target feature handling) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various
Unimplement unsized_locals Implements rust-lang/compiler-team#630 Tracking issue here: rust-lang#111942 Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`. There may be more that should be removed (possibly in follow up prs) - the `forget_unsized` function and `forget` intrinsic. - the `unsized_locals` test directory; I've just fixed up the tests for now - various codegen support for unsized values and allocas cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3`` ``@rustbot`` label F-unsized_locals Fixes rust-lang#79409
…ngjubilee Simplify implementation of Rust intrinsics by using type parameters in the cache The current implementation of intrinsics have a lot of duplication to handle different overloads of overloaded LLVM intrinsic. This PR uses the **base name and the type parameters** in the cache instead of the full, overloaded name. This has the benefit that `call_intrinsic` doesn't need to provide the full name, rather the type parameters (which is most of the time more available). This uses `LLVMIntrinsicCopyOverloadedName2` to get the overloaded name from the base name and the type parameters, and only uses it to declare the function. (originally was part of rust-lang#140763, split off later) `@rustbot` label A-codegen A-LLVM r? codegen
…lexcrichton Remove wasm legacy abi Closes rust-lang#122532 Closes rust-lang#138762 Fixes rust-lang#71871 rust-lang#88152 Fixes rust-lang#115666 Fixes rust-lang#129486
…ork, r=workingjubilee,saethlin Move metadata object generation for dylibs to the linker code This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time. Prerequisite of rust-lang#96708.
…and faster string parsing
Fix const_undef
…update_cg_gcc_2025-06-30
Sync from downstream
…rait, r=workingjubilee inherit `#[align]` from trait method prototypes ```@workingjubilee``` this seems straightforward enough. Now that we're planning to make `-Cmin-function-alignment` a target modifier, I don't think there are any cross-crate complications here? ```@Jules-Bertholet``` is this the behavior you had in mind? In particular the inheritance of the attribute of a default impl is maybe a bit unintuitive at first? (but I think it's ok if that behavior is explicitly documented). r? ghost
…inting, r=petrochenkov Improve macro stats printing Fix a small formatting issue that has been annoying me. r? `@petrochenkov`
…, r=Kobzol [COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary This is part of a patch series to untangle `compiletest` to hopefully nudge it towards being more maintainable. This PR: - Moves some early config checks (some warnings) to the compiletest library. - Moves `src/main.rs` to `src/bin/main.rs` to make the separation (as in, compiletest's library component vs the tool binary component) more obvious. r? `@Kobzol` (or reroll)
…cc_2025-06-30, r=GuillaumeGomez GCC backend subtree update cc `@antoyo` r? ghost
Subtree update of `rust-analyzer` r? `@ghost`
@bors r+ rollup=never p=5 |
bors
added a commit
that referenced
this pull request
Jun 30, 2025
Rollup of 5 pull requests Successful merges: - #143156 (inherit `#[align]` from trait method prototypes) - #143223 (Improve macro stats printing) - #143229 ([COMPILETEST-UNTANGLE 1/N] Move some some early config checks to the lib and move the compiletest binary) - #143239 (GCC backend subtree update) - #143246 (Subtree update of `rust-analyzer`) r? `@ghost` `@rustbot` modify labels: rollup
💔 Test failed - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-attributes
Area: Attributes (`#[…]`, `#![…]`)
A-compiletest
Area: The compiletest test runner
A-testsuite
Area: The testsuite used to check the correctness of rustc
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
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.
Successful merges:
#[align]
from trait method prototypes #143156 (inherit#[align]
from trait method prototypes)rust-analyzer
#143246 (Subtree update ofrust-analyzer
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup