Skip to content

Conversation

@davidtwco
Copy link
Member

@davidtwco davidtwco commented Oct 15, 2021

cc #60705 rust-lang/compiler-team#938

Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain . characters which aren't universally supported. Therefore, Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language, not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters A-Z, a-z, 0-9, and _.

Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers).

This pull request changes the default symbol mangling scheme from the legacy scheme to the new Rust mangling scheme on nightly.

The following pull requests implemented v0 mangling in rustc (if I'm missing any, let me know):

Rust's symbol mangling scheme has support in the following external tools:

#85530 (comment) contains a summary of the most recent crater run of the v0 mangling, and the remaining issues from that were fixed by #87194 (confirmed by follow-up crater run, #85530 (comment)).

@rustbot label +T-compiler
r? @michaelwoerister

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 15, 2021
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 15, 2021
@Mark-Simulacrum
Copy link
Member

It looks like the valgrind and LLVM tool patches were only just merged in the last couple months - are they included in published releases? It'll probably take at least a year or two for them to get into e.g. LTS releases on distros, which we may not want to wait for, but having at least some release seems reasonable to me and is probably not that long a wait.

@Mark-Simulacrum
Copy link
Member

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 15, 2021
@bors
Copy link
Collaborator

bors commented Oct 15, 2021

⌛ Trying commit 4f1bf2a with merge d6cf5a91f80fba50e1594bddce52ee42486468c6...

@davidtwco
Copy link
Member Author

It looks like the valgrind and LLVM tool patches were only just merged in the last couple months - are they included in published releases? It'll probably take at least a year or two for them to get into e.g. LTS releases on distros, which we may not want to wait for, but having at least some release seems reasonable to me and is probably not that long a wait.

As far as I can tell, the LLVM patch is in LLVM 13 (GitHub says llvm/llvm-project@0a2d4f3 is on the branch at least) and valgrind 3.18.0 has support (release notes).

@bors
Copy link
Collaborator

bors commented Oct 15, 2021

☀️ Try build successful - checks-actions
Build commit: d6cf5a91f80fba50e1594bddce52ee42486468c6 (d6cf5a91f80fba50e1594bddce52ee42486468c6)

@rust-timer
Copy link
Collaborator

Queued d6cf5a91f80fba50e1594bddce52ee42486468c6 with parent af9b508, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (d6cf5a91f80fba50e1594bddce52ee42486468c6): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

  • Very large improvement in instruction counts (up to -20.7% on incr-patched: Job builds of regex)
  • Very large regression in instruction counts (up to 9.5% on incr-unchanged builds of webrender-wrench)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Oct 15, 2021
@est31
Copy link
Member

est31 commented Oct 17, 2021

the LLVM patch is in LLVM 13 [...] and valgrind 3.18.0 has support (release notes).

FTR, on the just released Ubuntu 21.10, the llvm available in the repos is 13.0, and the valgrind available is 3.17.0. Debian sid however is still on LLVM 11.0.

Nix OS has just updated to the new valgrind on their master branch, and I think it'll take a few days until it arrives on hydra. Stable users on 21.05 still get 3.16.1, but 21.11 seems to be on track to getting the new version.

@michaelwoerister
Copy link
Member

As discussed in the compiler team triage meeting a while ago, we will do a @rust-lang/compiler team FCP on this PR. That will take at least 10 days, so that the new default would make it to stable 1.58 (released January 13th 2022). With that timeline in mind, do you still think it is necessary to wait for a valgrind release, @Mark-Simulacrum?

@Mark-Simulacrum
Copy link
Member

I think the latest valgrind release already contains the relevant patches. I'm not sure how I feel about the default being not supported by tooling on LTS distros, but I don't know that we want to wait for the potentially long time that would take -- it seems unlikely to be too impactful -- rustfilt is pretty fast and easy to install. I think we can see how much trouble we might run into by flipping the default for the compiler itself now (perhaps even before an FCP concludes) so that we can get some sense of the impact -- to maximize the time for identifying any problems we can observe in the wild from users and compiler developers using these.

Another concern I'll note that as of now this increases the compiler's install size by ~27 MB (from 378 to 405 MB) -- not a huge increase, but also not particularly small. The download size only goes up by ~5MB so I guess the extended symbols compress well. The stripped binaries avoid this extra cost, but those aren't what we ship today. Maybe it's worth blocking this on stable support for split-debuginfo, which would give a smoother path toward stripping binaries (right?) for most users.

But this is not any hard blockers IMO, just some concerns to think through as we make this decision. I think a writeup of each of these and why we're making a particular tradeoff here would be helpful to me at least. On the other hand, there are definite benefits to the new mangling -- e.g., I've been using it for some of the performance triage + improvement work I'm doing locally -- so generally I think we should move ahead.

Timeline wise, I don't know whether we expect much breakage or issues filed, but I'll note that shipping in early January probably means most of the beta/nightly cycles will be during holidays and generally we don't have as much speed. So maybe delaying 1 releases (to ~1.59 or 1.60) would be of benefit regardless.

@eddyb
Copy link
Member

eddyb commented Oct 18, 2021

I don't think split-debuginfo can handle linking (import/export) symbols - and I've only heard of a way to split the latter on Windows (mapping names to "ordinals").

(I sometimes "symbols" used ambiguously - the distinction I'm making is that debuginfo is non-semantic, but "linking names" are semantic and allow less wiggle room)

It would be great to keep linking names compressed (esp. since a lot of names would share very similar crate roots, path components, etc.) until some rustc-dev-using project needs to link to librustc_driver.so, or rustc ICEs and wants to print a backtrace without debuginfo available.

Sadly I'm worried platform tooling is decades behind having this kind of infrastructure directly supported, and we'd have to do a lot of it ourselves (and in brittle ways).

@michaelwoerister
Copy link
Member

I think we can see how much trouble we might run into by flipping the default for the compiler itself now (perhaps even before an FCP concludes) so that we can get some sense of the impact

Yes, that sounds like a good idea. I'll open a PR shortly.

I think a writeup of each of these and why we're making a particular tradeoff here would be helpful to me at least.

What format would you like that to have? Extending the PR message maybe?

On the other hand, there are definite benefits to the new mangling

I think that's an important point: there's also a cost to keeping the old mangling scheme around. We developed the new scheme because the old one is lacking in a number of ways.

shipping in early January probably means most of the beta/nightly cycles will be during holidays

That's good point.

@michaelwoerister
Copy link
Member

I think we can see how much trouble we might run into by flipping the default for the compiler itself now (perhaps even before an FCP concludes) so that we can get some sense of the impact

Implemented in PR #90054.

@Mark-Simulacrum
Copy link
Member

Yeah, I was thinking about adding to the PR message. I skimmed the RFC but I think it didn't directly address the tradeoffs I mentioned.

Another aspect which seems like it's worth including is our plans for eventual removal of the old mangling scheme. I could also imagine that some users might be interested in an alternate mangling that is just a hash and so is as short as possible.

I don't think split-debuginfo can handle linking (import/export) symbols - and I've only heard of a way to split the latter on Windows (mapping names to "ordinals").

Hm, I guess. I think there's probably still an increase in debuginfo size with the new mangling but I suppose it's probably not as important. Seems good to call out this support / lack thereof, though.

@michaelwoerister
Copy link
Member

michaelwoerister commented Oct 19, 2021

Another aspect which seems like it's worth including is our plans for eventual removal of the old mangling scheme. I could also imagine that some users might be interested in an alternate mangling that is just a hash and so is as short as possible.

Yes, we might want to extend the new scheme with a well-defined "hash mode" for cases like this. E.g. _RH<sha256 of what the symbol_name would be in non-hash mode>.

I would also be interested in a "zstd mode" with a predefined dictionary. That might give additional compression without losing information. But we'd need to collect numbers for that and make sure zstd dictionaries are standardized enough for something like that.

But both things would need a proper RFC amendment.

@michaelwoerister michaelwoerister added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Oct 21, 2021
@michaelwoerister
Copy link
Member

I've labeled the PR as blocked for now because of @Mark-Simulacrum's point about this becoming stable right after the holiday season. I'll look into a writeup about tradeoffs some time next week.

JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 21, 2021
…piler, r=Mark-Simulacrum

Make new symbol mangling scheme default for compiler itself.

As suggest in rust-lang#89917 (comment), this PR enables the new symbol mangling scheme for the compiler itself. The standard library is still compiled using the legacy mangling scheme so that the new symbol format does not show up in user code (yet).

r? `@Mark-Simulacrum`
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 23, 2021
…ler, r=Mark-Simulacrum

Make new symbol mangling scheme default for compiler itself.

As suggest in rust-lang#89917 (comment), this PR enables the new symbol mangling scheme for the compiler itself. The standard library is still compiled using the legacy mangling scheme so that the new symbol format does not show up in user code (yet).

r? `@Mark-Simulacrum`
@wesleywiser
Copy link
Member

Timeline wise, I don't know whether we expect much breakage or issues filed, but I'll note that shipping in early January probably means most of the beta/nightly cycles will be during holidays and generally we don't have as much speed. So maybe delaying 1 releases (to ~1.59 or 1.60) would be of benefit regardless.

I think this is a really good point! Perhaps it would make sense to land this change on nightly and disable it once beta branches for a few cycles? That would give us extra testing time on nightly while not putting us on a path toward shipping in 1.58 when many people would have been on holiday.

@davidtwco davidtwco force-pushed the issue-60705-stabilize-rust-symbol-mangling-scheme branch from 36de2f7 to a473676 Compare June 10, 2025 14:02
@rust-log-analyzer

This comment has been minimized.

@davidtwco davidtwco force-pushed the issue-60705-stabilize-rust-symbol-mangling-scheme branch from a473676 to 85fa90a Compare July 24, 2025 11:28
@rustbot
Copy link
Collaborator

rustbot commented Jul 24, 2025

Some changes occurred in tests/codegen-llvm/sanitizer

cc @rcvalle

@rustbot rustbot added the PG-exploit-mitigations Project group: Exploit mitigations label Jul 24, 2025
@bors

This comment was marked as resolved.

@davidtwco davidtwco force-pushed the issue-60705-stabilize-rust-symbol-mangling-scheme branch from 85fa90a to 83ca9cf Compare October 9, 2025 14:49
@rustbot

This comment has been minimized.


pub fn get_symbol_mangling_version(&self) -> SymbolManglingVersion {
self.cg.symbol_mangling_version.unwrap_or(SymbolManglingVersion::Legacy)
self.cg.symbol_mangling_version.unwrap_or(SymbolManglingVersion::V0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Please update src/doc/rustc/src/symbol-mangling/index.md as well (says at the bottom that the default is legacy).

@davidtwco davidtwco force-pushed the issue-60705-stabilize-rust-symbol-mangling-scheme branch from 83ca9cf to 94a6bec Compare November 10, 2025 11:56
@rustbot

This comment has been minimized.

@davidtwco davidtwco force-pushed the issue-60705-stabilize-rust-symbol-mangling-scheme branch from 94a6bec to f581659 Compare November 10, 2025 11:57
@davidtwco
Copy link
Member Author

Updated to reflect rust-lang/compiler-team#938

@davidtwco davidtwco changed the title sess: default to v0 symbol mangling sess: default to v0 symbol mangling on nightly Nov 10, 2025
@rust-log-analyzer

This comment has been minimized.

Rust's current mangling scheme depends on compiler internals; loses
information about generic parameters (and other things) which makes for
a worse experience when using external tools that need to interact with
Rust symbol names; is inconsistent; and can contain `.` characters
which aren't universally supported. Therefore, Rust has defined its own
symbol mangling scheme which is defined in terms of the Rust language,
not the compiler implementation; encodes information about generic
parameters in a reversible way; has a consistent definition; and
generates symbols that only use the characters `A-Z`, `a-z`, `0-9`, and
`_`.

Support for the new Rust symbol mangling scheme has been added to
upstream tools that will need to interact with Rust symbols (e.g.
debuggers).

This commit changes the default symbol mangling scheme from the legacy
scheme to the new Rust mangling scheme.

Signed-off-by: David Wood <[email protected]>
@davidtwco davidtwco force-pushed the issue-60705-stabilize-rust-symbol-mangling-scheme branch from f581659 to b4b7f67 Compare November 11, 2025 11:14
@rustbot
Copy link
Collaborator

rustbot commented Nov 11, 2025

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@wesleywiser
Copy link
Member

@bors r+ rollup=never

@bors
Copy link
Collaborator

bors commented Nov 11, 2025

📌 Commit b4b7f67 has been approved by wesleywiser

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-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Nov 11, 2025
@bors
Copy link
Collaborator

bors commented Nov 11, 2025

⌛ Testing commit b4b7f67 with merge d1d4863...

bors added a commit that referenced this pull request Nov 11, 2025
…ngling-scheme, r=wesleywiser

sess: default to v0 symbol mangling on nightly

cc #60705 rust-lang/compiler-team#938

Rust's current mangling scheme depends on compiler internals; loses information about generic parameters (and other things) which makes for a worse experience when using external tools that need to interact with Rust symbol names; is inconsistent; and can contain `.` characters which aren't universally supported. Therefore, Rust has defined its own symbol mangling scheme which is defined in terms of the Rust language, not the compiler implementation; encodes information about generic parameters in a reversible way; has a consistent definition; and generates symbols that only use the characters `A-Z`, `a-z`, `0-9`, and `_`.

Support for the new Rust symbol mangling scheme has been added to upstream tools that will need to interact with Rust symbols (e.g. debuggers).

This pull request changes the default symbol mangling scheme from the legacy scheme to the new Rust mangling scheme on nightly.

The following pull requests implemented v0 mangling in rustc (if I'm missing any, let me know):

- #57967
- #63559
- #75675
- #77452
- #77554
- #83767
- #87194
- #87789

Rust's symbol mangling scheme has support in the following external tools:

- `binutils`/`gdb` (GNU `libiberty`)
    - [[PATCH] Move rust_{is_mangled,demangle_sym} to a private libiberty header.
](https://gcc.gnu.org/pipermail/gcc-patches/2019-June/523011.html) committed as gcc-mirror/gcc@979526c
    - [[PATCH] Simplify and generalize rust-demangle's unescaping logic.
](https://gcc.gnu.org/pipermail/gcc-patches/2019-August/527835.html) committed as gcc-mirror/gcc@42bf58b
    - [[PATCH] Remove some restrictions from rust-demangle.
](https://gcc.gnu.org/pipermail/gcc-patches/2019-September/530445.html) committed as gcc-mirror/gcc@e1cb00d
    - [[PATCH] Refactor rust-demangle to be independent of C++ demangling.
](https://gcc.gnu.org/pipermail/gcc-patches/2019-November/533719.html) ([original submission](https://gcc.gnu.org/pipermail/gcc-patches/2019-October/532388.html)) committed as gcc-mirror/gcc@32fc371
    - [[PATCH] Support the new ("v0") mangling scheme in rust-demangle.
](https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558905.html) ([original submission](https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html)) committed as gcc-mirror/gcc@8409649
- `lldb`/`llvm-objdump`/`llvm-nm`/`llvm-symbolizer`/`llvm-cxxfilt`/etc
  - llvm/llvm-project@7310403
  - llvm/llvm-project@c8c2b46
  - llvm/llvm-project@0a2d4f3
- Linux `perf`
- `valgrind`
  - [Update demangler to support Rust v0 name mangling.](https://bugs.kde.org/show_bug.cgi?id=431306)

#85530 (comment) contains a summary of the most recent crater run of the v0 mangling, and the remaining issues from that were fixed by #87194 (confirmed by follow-up crater run, #85530 (comment)).

`@rustbot` label +T-compiler
r? `@michaelwoerister`
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-21-3 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
------FileCheck stderr------------------------------
/checkout/tests/codegen-llvm/naked-fn/generics.rs:27:11: error: CHECK: expected string not found in input
// CHECK: add rax, 1
          ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen-llvm/naked-fn/generics/generics.ll:40:22: note: scanning from here
module asm ".balign 4"
                     ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen-llvm/naked-fn/generics/generics.ll:41:2: note: possible intended match here
module asm ".globl generic_function"
 ^

Input file: /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen-llvm/naked-fn/generics/generics.ll
Check file: /checkout/tests/codegen-llvm/naked-fn/generics.rs

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: ; ModuleID = 'generics.2e39417dc5a6b368-cgu.0' 
            2: source_filename = "generics.2e39417dc5a6b368-cgu.0" 
            3: target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128" 
            4: target triple = "x86_64-unknown-linux-gnu" 
            5:  
            6: module asm ".intel_syntax" 
            7: module asm ".pushsection .text._RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_,\22ax\22, @progbits" 
            8: module asm ".balign 4" 
            9: module asm ".globl _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_" 
           10: module asm ".type _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_, @function" 
           11: module asm "_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_:" 
           12: module asm "xor rax, rax" 
           13: module asm "add rax, rdi" 
           14: module asm "add rax, 1" 
           15: module asm "add rax, 42" 
           16: module asm "ret" 
           17: module asm ".Lfunc_end__RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_:" 
           18: module asm ".size _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_, . - _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_" 
           19: module asm ".popsection" 
           20: module asm "" 
           21: module asm ".att_syntax" 
           22: module asm ".intel_syntax" 
           23: module asm ".pushsection .text._RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_,\22ax\22, @progbits" 
           24: module asm ".balign 4" 
           25: module asm ".globl _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_" 
           26: module asm ".type _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_, @function" 
           27: module asm "_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_:" 
           28: module asm "xor rax, rax" 
           29: module asm "add rax, rdi" 
           30: module asm "add rax, 2" 
           31: module asm "add rax, 42" 
           32: module asm "ret" 
           33: module asm ".Lfunc_end__RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_:" 
           34: module asm ".size _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_, . - _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_" 
           35: module asm ".popsection" 
           36: module asm "" 
           37: module asm ".att_syntax" 
           38: module asm ".intel_syntax" 
           39: module asm ".pushsection .text.generic_function,\22ax\22, @progbits" 
           40: module asm ".balign 4" 
check:27'0                          X~ error: no match found
           41: module asm ".globl generic_function" 
check:27'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:27'1      ?                                    possible intended match
           42: module asm ".type generic_function, @function" 
check:27'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           43: module asm "generic_function:" 
check:27'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           44: module asm "call _RNvXCs3Y2WkPYsbfo_8genericsxNtB2_6Invert6invert" 
           45: module asm "ret" 
           46: module asm ".Lfunc_end_generic_function:" 
           47: module asm ".size generic_function, . - generic_function" 
           48: module asm ".popsection" 
           49: module asm "" 
           50: module asm ".att_syntax" 
           51: module asm ".intel_syntax" 
           52: module asm ".pushsection .text.method,\22ax\22, @progbits" 
           53: module asm ".balign 4" 
           54: module asm ".globl method" 
           55: module asm ".type method, @function" 
           56: module asm "method:" 
           57: module asm "mov rax, rdi" 
           58: module asm "ret" 
           59: module asm ".Lfunc_end_method:" 
           60: module asm ".size method, . - method" 
           61: module asm ".popsection" 
           62: module asm "" 
           63: module asm ".att_syntax" 
           64: module asm ".intel_syntax" 
           65: module asm ".pushsection .text.trait_method,\22ax\22, @progbits" 
           66: module asm ".balign 4" 
           67: module asm ".globl trait_method" 
           68: module asm ".type trait_method, @function" 
           69: module asm "trait_method:" 
           70: module asm "mov rax, rdi" 
           71: module asm "ret" 
           72: module asm ".Lfunc_end_trait_method:" 
           73: module asm ".size trait_method, . - trait_method" 
           74: module asm ".popsection" 
           75: module asm "" 
           76: module asm ".att_syntax" 
           77: module asm ".intel_syntax" 
           78: module asm ".pushsection .text.naked_with_args_and_return,\22ax\22, @progbits" 
           79: module asm ".balign 4" 
           80: module asm ".globl naked_with_args_and_return" 
           81: module asm ".type naked_with_args_and_return, @function" 
           82: module asm "naked_with_args_and_return:" 
           83: module asm "lea rax, [rdi + rsi]" 
           84: module asm "ret" 
           85: module asm ".Lfunc_end_naked_with_args_and_return:" 
           86: module asm ".size naked_with_args_and_return, . - naked_with_args_and_return" 
           87: module asm ".popsection" 
           88: module asm "" 
           89: module asm ".att_syntax" 
           90:  
           91: @llvm.compiler.used = appending global [1 x ptr] [ptr @_RNvXCs3Y2WkPYsbfo_8genericsxNtB2_6Invert6invert], section "llvm.metadata" 
           92:  
           93: ; Function Attrs: nounwind nonlazybind uwtable 
           94: define void @test(i64 noundef %x) unnamed_addr #0 { 
           95: start: 
           96: ; call generics::using_const_generics::<1> 
           97:  %_2 = tail call noundef i64 @_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_(i64 noundef %x) #3 
           98: ; call generics::using_const_generics::<2> 
           99:  %_3 = tail call noundef i64 @_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_(i64 noundef %x) #3 
          100:  %_4 = tail call noundef i64 @generic_function(i64 noundef %x) #3 
          101:  %_7 = tail call noundef i64 @method(i64 noundef %x) #3 
          102:  %_8 = tail call noundef i64 @trait_method(i64 noundef %x) #3 
          103:  ret void 
          104: } 
          105:  
          106: ; <i64 as generics::Invert>::invert 
          107: ; Function Attrs: mustprogress nofree norecurse nosync nounwind nonlazybind willreturn memory(none) uwtable 
          108: define internal noundef i64 @_RNvXCs3Y2WkPYsbfo_8genericsxNtB2_6Invert6invert(i64 noundef %self) unnamed_addr #1 { 
          109: start: 
          110:  %_0 = sub i64 0, %self 
          111:  ret i64 %_0 
          112: } 
          113:  
          114: ; generics::using_const_generics::<1> 
          115: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          116: declare noundef i64 @_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_(i64 noundef) unnamed_addr #2 
          117:  
          118: ; generics::using_const_generics::<2> 
          119: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          120: declare noundef i64 @_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_(i64 noundef) unnamed_addr #2 
          121:  
          122: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          123: declare noundef i64 @generic_function(i64 noundef) unnamed_addr #2 
          124:  
          125: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          126: declare noundef i64 @method(i64 noundef) unnamed_addr #2 
          127:  
          128: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          129: declare noundef i64 @trait_method(i64 noundef) unnamed_addr #2 
          130:  
          131: attributes #0 = { nounwind nonlazybind uwtable "probe-stack"="inline-asm" "target-cpu"="x86-64" } 
          132: attributes #1 = { mustprogress nofree norecurse nosync nounwind nonlazybind willreturn memory(none) uwtable "probe-stack"="inline-asm" "target-cpu"="x86-64" } 
          133: attributes #2 = { noinline nounwind nonlazybind uwtable "probe-stack"="inline-asm" "target-cpu"="x86-64" } 
          134: attributes #3 = { nounwind } 
          135:  
          136: !llvm.module.flags = !{!0, !1} 
          137: !llvm.ident = !{!2} 
          138:  
          139: !0 = !{i32 8, !"PIC Level", i32 2} 
          140: !1 = !{i32 2, !"RtLibUseGOT", i32 1} 
          141: !2 = !{!"rustc version 1.93.0-nightly (d1d4863e0 2025-11-11)"} 
>>>>>>

------------------------------------------

error: verification with 'FileCheck' failed
status: exit status: 1
command: "/usr/lib/llvm-21/bin/FileCheck" "--input-file" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen-llvm/naked-fn/generics/generics.ll" "/checkout/tests/codegen-llvm/naked-fn/generics.rs" "--check-prefix=CHECK" "--allow-unused-prefixes" "--dump-input-context" "100"
stdout: none
--- stderr -------------------------------
/checkout/tests/codegen-llvm/naked-fn/generics.rs:27:11: error: CHECK: expected string not found in input
// CHECK: add rax, 1
          ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen-llvm/naked-fn/generics/generics.ll:40:22: note: scanning from here
module asm ".balign 4"
                     ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen-llvm/naked-fn/generics/generics.ll:41:2: note: possible intended match here
module asm ".globl generic_function"
 ^

Input file: /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen-llvm/naked-fn/generics/generics.ll
Check file: /checkout/tests/codegen-llvm/naked-fn/generics.rs

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: ; ModuleID = 'generics.2e39417dc5a6b368-cgu.0' 
            2: source_filename = "generics.2e39417dc5a6b368-cgu.0" 
            3: target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128" 
            4: target triple = "x86_64-unknown-linux-gnu" 
            5:  
            6: module asm ".intel_syntax" 
            7: module asm ".pushsection .text._RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_,\22ax\22, @progbits" 
            8: module asm ".balign 4" 
            9: module asm ".globl _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_" 
           10: module asm ".type _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_, @function" 
           11: module asm "_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_:" 
           12: module asm "xor rax, rax" 
           13: module asm "add rax, rdi" 
           14: module asm "add rax, 1" 
           15: module asm "add rax, 42" 
           16: module asm "ret" 
           17: module asm ".Lfunc_end__RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_:" 
           18: module asm ".size _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_, . - _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_" 
           19: module asm ".popsection" 
           20: module asm "" 
           21: module asm ".att_syntax" 
           22: module asm ".intel_syntax" 
           23: module asm ".pushsection .text._RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_,\22ax\22, @progbits" 
           24: module asm ".balign 4" 
           25: module asm ".globl _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_" 
           26: module asm ".type _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_, @function" 
           27: module asm "_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_:" 
           28: module asm "xor rax, rax" 
           29: module asm "add rax, rdi" 
           30: module asm "add rax, 2" 
           31: module asm "add rax, 42" 
           32: module asm "ret" 
           33: module asm ".Lfunc_end__RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_:" 
           34: module asm ".size _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_, . - _RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_" 
           35: module asm ".popsection" 
           36: module asm "" 
           37: module asm ".att_syntax" 
           38: module asm ".intel_syntax" 
           39: module asm ".pushsection .text.generic_function,\22ax\22, @progbits" 
           40: module asm ".balign 4" 
check:27'0                          X~ error: no match found
           41: module asm ".globl generic_function" 
check:27'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:27'1      ?                                    possible intended match
           42: module asm ".type generic_function, @function" 
check:27'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           43: module asm "generic_function:" 
check:27'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           44: module asm "call _RNvXCs3Y2WkPYsbfo_8genericsxNtB2_6Invert6invert" 
           45: module asm "ret" 
           46: module asm ".Lfunc_end_generic_function:" 
           47: module asm ".size generic_function, . - generic_function" 
           48: module asm ".popsection" 
           49: module asm "" 
           50: module asm ".att_syntax" 
           51: module asm ".intel_syntax" 
           52: module asm ".pushsection .text.method,\22ax\22, @progbits" 
           53: module asm ".balign 4" 
           54: module asm ".globl method" 
           55: module asm ".type method, @function" 
           56: module asm "method:" 
           57: module asm "mov rax, rdi" 
           58: module asm "ret" 
           59: module asm ".Lfunc_end_method:" 
           60: module asm ".size method, . - method" 
           61: module asm ".popsection" 
           62: module asm "" 
           63: module asm ".att_syntax" 
           64: module asm ".intel_syntax" 
           65: module asm ".pushsection .text.trait_method,\22ax\22, @progbits" 
           66: module asm ".balign 4" 
           67: module asm ".globl trait_method" 
           68: module asm ".type trait_method, @function" 
           69: module asm "trait_method:" 
           70: module asm "mov rax, rdi" 
           71: module asm "ret" 
           72: module asm ".Lfunc_end_trait_method:" 
           73: module asm ".size trait_method, . - trait_method" 
           74: module asm ".popsection" 
           75: module asm "" 
           76: module asm ".att_syntax" 
           77: module asm ".intel_syntax" 
           78: module asm ".pushsection .text.naked_with_args_and_return,\22ax\22, @progbits" 
           79: module asm ".balign 4" 
           80: module asm ".globl naked_with_args_and_return" 
           81: module asm ".type naked_with_args_and_return, @function" 
           82: module asm "naked_with_args_and_return:" 
           83: module asm "lea rax, [rdi + rsi]" 
           84: module asm "ret" 
           85: module asm ".Lfunc_end_naked_with_args_and_return:" 
           86: module asm ".size naked_with_args_and_return, . - naked_with_args_and_return" 
           87: module asm ".popsection" 
           88: module asm "" 
           89: module asm ".att_syntax" 
           90:  
           91: @llvm.compiler.used = appending global [1 x ptr] [ptr @_RNvXCs3Y2WkPYsbfo_8genericsxNtB2_6Invert6invert], section "llvm.metadata" 
           92:  
           93: ; Function Attrs: nounwind nonlazybind uwtable 
           94: define void @test(i64 noundef %x) unnamed_addr #0 { 
           95: start: 
           96: ; call generics::using_const_generics::<1> 
           97:  %_2 = tail call noundef i64 @_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_(i64 noundef %x) #3 
           98: ; call generics::using_const_generics::<2> 
           99:  %_3 = tail call noundef i64 @_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_(i64 noundef %x) #3 
          100:  %_4 = tail call noundef i64 @generic_function(i64 noundef %x) #3 
          101:  %_7 = tail call noundef i64 @method(i64 noundef %x) #3 
          102:  %_8 = tail call noundef i64 @trait_method(i64 noundef %x) #3 
          103:  ret void 
          104: } 
          105:  
          106: ; <i64 as generics::Invert>::invert 
          107: ; Function Attrs: mustprogress nofree norecurse nosync nounwind nonlazybind willreturn memory(none) uwtable 
          108: define internal noundef i64 @_RNvXCs3Y2WkPYsbfo_8genericsxNtB2_6Invert6invert(i64 noundef %self) unnamed_addr #1 { 
          109: start: 
          110:  %_0 = sub i64 0, %self 
          111:  ret i64 %_0 
          112: } 
          113:  
          114: ; generics::using_const_generics::<1> 
          115: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          116: declare noundef i64 @_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy1_EB2_(i64 noundef) unnamed_addr #2 
          117:  
          118: ; generics::using_const_generics::<2> 
          119: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          120: declare noundef i64 @_RINvCs3Y2WkPYsbfo_8generics20using_const_genericsKy2_EB2_(i64 noundef) unnamed_addr #2 
          121:  
          122: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          123: declare noundef i64 @generic_function(i64 noundef) unnamed_addr #2 
          124:  
          125: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          126: declare noundef i64 @method(i64 noundef) unnamed_addr #2 
          127:  
          128: ; Function Attrs: noinline nounwind nonlazybind uwtable 
          129: declare noundef i64 @trait_method(i64 noundef) unnamed_addr #2 
          130:  
          131: attributes #0 = { nounwind nonlazybind uwtable "probe-stack"="inline-asm" "target-cpu"="x86-64" } 
          132: attributes #1 = { mustprogress nofree norecurse nosync nounwind nonlazybind willreturn memory(none) uwtable "probe-stack"="inline-asm" "target-cpu"="x86-64" } 
          133: attributes #2 = { noinline nounwind nonlazybind uwtable "probe-stack"="inline-asm" "target-cpu"="x86-64" } 
          134: attributes #3 = { nounwind } 
          135:  
          136: !llvm.module.flags = !{!0, !1} 
          137: !llvm.ident = !{!2} 
          138:  
          139: !0 = !{i32 8, !"PIC Level", i32 2} 
          140: !1 = !{i32 2, !"RtLibUseGOT", i32 1} 
          141: !2 = !{!"rustc version 1.93.0-nightly (d1d4863e0 2025-11-11)"} 
>>>>>>
------------------------------------------

---- [codegen] tests/codegen-llvm/naked-fn/generics.rs stdout end ----

@bors
Copy link
Collaborator

bors commented Nov 11, 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 Nov 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

perf-regression Performance regression. PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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.