Skip to content

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
wants to merge 142 commits into from
Closed

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Jun 30, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

bjorn3 and others added 30 commits June 3, 2025 10:00
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
…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
…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.
antoyo and others added 12 commits June 30, 2025 09:20
…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`
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc 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. rollup A PR which is a rollup labels Jun 30, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jun 30, 2025

📌 Commit bcd7053 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 30, 2025
@bors
Copy link
Collaborator

bors commented Jun 30, 2025

⌛ Testing commit bcd7053 with merge 569455a...

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
@rust-log-analyzer
Copy link
Collaborator

The job test-various failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors
Copy link
Collaborator

bors commented Jun 30, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 30, 2025
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.