Don't ignore unknown LLVM diagnostics by nikic · Pull Request #164578 · rust-lang/rust

nikic · 2026-10-19T12:58:18Z

Rust currently ignores LLVM diagnostic kinds that it does not know about. This means that we sometimes ignore error diagnostics, which can then result in silent miscompiles.

This exposes LLVMGetDiagInfoSeverity returning DiagnosticSeverity, renamed from DiagnosticLevel to match LLVM terminology. Custom code to fetch the diagnostic severity for inline asm diagnostics can then be dropped.

For unknown diagnostics, we emit a warning/error depending on severity. Notes and remarks continue to be ignored.

One oddity I ran into along the way is that the linker diagnostic has severity error, but we only report a warning. I've kept this for now as we still error down the line and this ends up providing a bit more information (which file the duplicate symbol originates from).

Fixes #146393.

rustbot · 2026-10-19T12:58:23Z

r? @mati865

rustbot has assigned @mati865.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 77 candidates
Random selection from 18 candidates

mati865

I went through the rabbit hole and the warning for PGO was added as the initial PGO support 8a4cebd (#48346) with the reasoning that should be at least a warning.
Then, #52474 built on top of it adding warnings for previously ignored LTO errors.

I've kept this for now as we still error down the line and this ends up providing a bit more information (which file the duplicate symbol originates from).

I agree that seeing where the error comes from is potentially useful for non-mangled symbols, but currently this seems to depend entirely on the next stage to emit an error upon encountering bad inputs. I imagine (uneducated guess) there might be cases where we print LLVM's error as a warning, but the next stage emits just a warning or is silent.

r=me with sentence above and comments addressed or discarded.

View changes since this review

mati865 · 2026-10-19T16:01:24Z

            dcx.emit_warn(FromLlvmDiag { message });
        }
-        llvm::diagnostic::Unsupported(diagnostic_ref) => {
+        llvm::diagnostic::PGO(diagnostic_ref)


Adding PGO test akin to lto-duplicate-symbol shouldn't be hard, no? Could be a good E-easy issue.

mati865 · 2026-10-19T16:41:56Z

-        llvm::diagnostic::Unsupported(diagnostic_ref) => {
+        llvm::diagnostic::PGO(diagnostic_ref)
+        | llvm::diagnostic::Unsupported(diagnostic_ref)
+        | llvm::diagnostic::UnknownDiagnostic(diagnostic_ref) => {


Just asking because I'm not familiar with how we want to handle LLVM errors.
Would it be useful to split UnknownDiagnostic variant into LLVM's unknown errors and "LLVM errors that we didn't map yet", so we can indicate the not mapped ones here?
Acting only when we hit a not yet mapped error that needs special handling seems fine too.

TBH I think we should rather go the other way around and remove any diagnostic kinds that we don't specially handle, i.e. drop PGO and Unsupported and use UnknownDiagnostic for everything. Apart from a few special cases (inline asm and optimization remarks), Rust mostly shouldn't care about where the diagnostic originates and just forward it.

nikic · 2026-10-20T07:33:24Z

I've pushed two additional changes here. One to remove the Diagnostic variants that don't get special treatment (they're all Diagnostic::Other now), and one to remove the special Linker handling as well. Overall, I think that special case isn't worth it, esp. with the risk that we may end up not erroring after a downgraded warning.

mati865 · 2026-10-20T09:36:50Z

Sounds good, thanks!

@bors r+

rust-bors · 2026-10-20T09:36:54Z

📌 Commit b95ad06 has been approved by mati865

It is now in the queue for this repository.

Don't ignore unknown LLVM diagnostics Rust currently ignores LLVM diagnostic kinds that it does not know about. This means that we sometimes ignore error diagnostics, which can then result in silent miscompiles. This exposes `LLVMGetDiagInfoSeverity` returning `DiagnosticSeverity`, renamed from `DiagnosticLevel` to match LLVM terminology. Custom code to fetch the diagnostic severity for inline asm diagnostics can then be dropped. For unknown diagnostics, we emit a warning/error depending on severity. Notes and remarks continue to be ignored. One oddity I ran into along the way is that the linker diagnostic has severity error, but we only report a warning. I've kept this for now as we still error down the line and this ends up providing a bit more information (which file the duplicate symbol originates from). Fixes rust-lang#146393.

…uwer Rollup of 6 pull requests Successful merges: - #163104 ([debuginfo] Emit `usize` and `isize` as typedefs) - #164488 (Don't try to skip anything in `Skip::advance_by(0)`) - #164578 (Don't ignore unknown LLVM diagnostics) - #164611 (Improve bit permutation codegen) - #162668 (document that `!` does bitwise and logical negation) - #164264 (lint: suggest `fXX::is_nan` for unsuffixed NaN comparisons)

Don't ignore unknown LLVM diagnostics Rust currently ignores LLVM diagnostic kinds that it does not know about. This means that we sometimes ignore error diagnostics, which can then result in silent miscompiles. This exposes `LLVMGetDiagInfoSeverity` returning `DiagnosticSeverity`, renamed from `DiagnosticLevel` to match LLVM terminology. Custom code to fetch the diagnostic severity for inline asm diagnostics can then be dropped. For unknown diagnostics, we emit a warning/error depending on severity. Notes and remarks continue to be ignored. One oddity I ran into along the way is that the linker diagnostic has severity error, but we only report a warning. I've kept this for now as we still error down the line and this ends up providing a bit more information (which file the duplicate symbol originates from). Fixes rust-lang#146393.

…uwer Rollup of 14 pull requests Successful merges: - #163575 (core: Add examples and assembly tests for `abort_immediate`) - #163664 (Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests) - #163104 ([debuginfo] Emit `usize` and `isize` as typedefs) - #163338 (MIR move elimination [4/6]: MoveElimination) - #163701 (add ReadDir::dir to get the directory handle of the underlying directory) - #164488 (Don't try to skip anything in `Skip::advance_by(0)`) - #164578 (Don't ignore unknown LLVM diagnostics) - #164611 (Improve bit permutation codegen) - #164612 (std: Combine `is_powerpc64_feature_detected` into `is_powerpc_feature_detected`) - #162668 (document that `!` does bitwise and logical negation) - #164264 (lint: suggest `fXX::is_nan` for unsuffixed NaN comparisons) - #164509 (layout invariant: turn delayed bug back into proper assertion) - #164594 (rustdoc: Correctly handle inner `deprecated` attribute on modules) - #164629 (arch::breakpoint: avoid confusing 'equivalent' terminology)

Don't ignore unknown LLVM diagnostics Rust currently ignores LLVM diagnostic kinds that it does not know about. This means that we sometimes ignore error diagnostics, which can then result in silent miscompiles. This exposes `LLVMGetDiagInfoSeverity` returning `DiagnosticSeverity`, renamed from `DiagnosticLevel` to match LLVM terminology. Custom code to fetch the diagnostic severity for inline asm diagnostics can then be dropped. For unknown diagnostics, we emit a warning/error depending on severity. Notes and remarks continue to be ignored. One oddity I ran into along the way is that the linker diagnostic has severity error, but we only report a warning. I've kept this for now as we still error down the line and this ends up providing a bit more information (which file the duplicate symbol originates from). Fixes rust-lang#146393.

…uwer Rollup of 13 pull requests Successful merges: - #163664 (Add new `RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags` mode for testing stable compiler behavior in UI tests) - #163104 ([debuginfo] Emit `usize` and `isize` as typedefs) - #163338 (MIR move elimination [4/6]: MoveElimination) - #163701 (add ReadDir::dir to get the directory handle of the underlying directory) - #164488 (Don't try to skip anything in `Skip::advance_by(0)`) - #164578 (Don't ignore unknown LLVM diagnostics) - #164611 (Improve bit permutation codegen) - #164612 (std: Combine `is_powerpc64_feature_detected` into `is_powerpc_feature_detected`) - #162668 (document that `!` does bitwise and logical negation) - #164264 (lint: suggest `fXX::is_nan` for unsuffixed NaN comparisons) - #164509 (layout invariant: turn delayed bug back into proper assertion) - #164594 (rustdoc: Correctly handle inner `deprecated` attribute on modules) - #164629 (arch::breakpoint: avoid confusing 'equivalent' terminology)

JonathanBrouwer · 2026-10-20T14:33:09Z

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #164634 (comment)

@bors try jobs=test-x86_64-gnu-nopt

rust-bors · 2026-10-20T14:33:18Z

This pull request was unapproved.

This PR was contained in a rollup (#164634), which was unapproved.

View changes since this unapproval

…uwer Rollup of 8 pull requests Successful merges: - #162460 (Feat - `#[inline(always)] + #[target_feature(enable = "....")]` #2) - #163485 (`rustc_builtin_macros` cleanup, part 8) - #164578 (Don't ignore unknown LLVM diagnostics) - #162369 (Document the `recursion_limit` built-in attribute) - #162840 (tier 3 target policy: target CPU and features must be supported by upstream backend) - #164330 (Skip redundant monomorphization checks) - #164656 (stabilize ExitCodeExt for Windows) - #164660 (Touch up attribute docs)

JonathanBrouwer · 2026-10-21T15:44:03Z

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #164687 (comment)

JonathanBrouwer · 2026-10-21T15:44:29Z

@bors rollup=iffy
As this failed twice

Don't ignore unknown LLVM diagnostics Rust currently ignores LLVM diagnostic kinds that it does not know about. This means that we sometimes ignore error diagnostics, which can then result in silent miscompiles. This exposes `LLVMGetDiagInfoSeverity` returning `DiagnosticSeverity`, renamed from `DiagnosticLevel` to match LLVM terminology. Custom code to fetch the diagnostic severity for inline asm diagnostics can then be dropped. For unknown diagnostics, we emit a warning/error depending on severity. Notes and remarks continue to be ignored. One oddity I ran into along the way is that the linker diagnostic has severity error, but we only report a warning. I've kept this for now as we still error down the line and this ends up providing a bit more information (which file the duplicate symbol originates from). Fixes rust-lang#146393.

rust-bors · 2026-10-21T16:02:30Z

This pull request was unapproved.

This PR was contained in a rollup (#164697), which was unapproved.

View changes since this unapproval

mati865 · 2026-10-21T16:04:21Z

Let's just avoid rolling up this PR, I don't know how many errors are there to uncover.
@bors rollup=never

mati865 · 2026-10-21T16:05:52Z

@bors try jobs=test-x86_64-gnu-debug

Don't ignore unknown LLVM diagnostics try-job: test-x86_64-gnu-debug

rust-bors · 2026-10-21T18:13:43Z

💔 Test for e83a3e0 failed: CI. Failed job:

try - test-x86_64-gnu-debug (web logs, enhanced plaintext logs)

Rust currently ignores LLVM diagnostic kinds that it does not know about. This means that we sometimes ignore error diagnostics, which can then result in silent miscompiles. This exposes `LLVMGetDiagInfoSeverity` returning `DiagnosticSeverity`, renamed from `DiagnosticLevel` to match LLVM terminology. Custom code to fetch the diagnostic severity for inline asm diagnostics can then be dropped. For unknown diagnostics, we emit a warning/error depending on severity. Notes and remarks continue to be ignored. One oddity I ran into along the way is that the linker diagnostic has severity error, but we only report a warning. I've kept this for now as we still error down the line and this ends up providing a bit more information (which file the duplicate symbol originates from).

Merge the PGO, Unsupported into UnknownDiagnostic and rename it to Other. We don't do anything special for them, so there is no need to represent them differently.

This preserves the existing behavior. Enabling these warnings is tracked in a new issue.

rustbot · 2026-10-22T07:37:25Z

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.

nikic · 2026-10-22T07:41:51Z

The error message is different depending on whether there is debuginfo. I've forced -Cdebuginfo=line-tables-only for the test (and removed the unnecessary use of volatile write to make sure the line is in the test file, so it doesn't jump around with minicore changes...)

As a side note, in the cases where LLVM diagnostics have a DiagnosticLocation, we should probably map that to a Rust diagnostic location as well, instead of letting LLVM print this as part of the error message...

@bors try jobs=test-x86_64-gnu-debug

Don't ignore unknown LLVM diagnostics try-job: test-x86_64-gnu-debug

Apparently this depends on where the tests are run from?

rust-bors · 2026-10-22T09:42:03Z

💔 Test for f1ec490 failed: CI. Failed job:

try - test-x86_64-gnu-debug (web logs, enhanced plaintext logs)

rust-log-analyzer · 2026-10-22T09:42:05Z

The job test-x86_64-gnu-debug failed! Check out the build log: (web) (plain enhanced) (plain)

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

To only update this specific test, also pass `--test-args target-feature/too-many-reserved-regs.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/target-feature/too-many-reserved-regs.rs" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/target-feature/too-many-reserved-regs" "-Znext-solver=coherence" "-A" "unused" "-W" "unused_attributes" "-A" "internal_features" "-A" "incomplete_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Clinker=clang" "-Cpanic=abort" "-Cforce-unwind-tables=yes" "--edition=2015" "--target=riscv64gc-unknown-linux-gnu" "-Copt-level=3" "-Cdebuginfo=line-tables-only" "-Zllvm-target-feature=+reserve-x1,+reserve-x3,+reserve-x4,+reserve-x5,+reserve-x6,+reserve-x7,+reserve-x8,+reserve-x9,+reserve-x11,+reserve-x12,+reserve-x13,+reserve-x14,+reserve-x15,+reserve-x16,+reserve-x17,+reserve-x18,+reserve-x19,+reserve-x20,+reserve-x21,+reserve-x22,+reserve-x23,+reserve-x24,+reserve-x25,+reserve-x26,+reserve-x27,+reserve-x28,+reserve-x29,+reserve-x30,+reserve-x31" "--extern" "minicore=/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/target-feature/too-many-reserved-regs/libminicore.rlib"
stdout: none
--- stderr -------------------------------
error: /checkout/tests/ui/target-feature/too-many-reserved-regs.rs:16:5: ran out of registers during register allocation in function 'store_val'

error: aborting due to 1 previous error

nikic · 2026-10-22T10:23:42Z

Turns out that the path depends on which directory the tests are run from. Trying again with normalization...

@bors try jobs=test-x86_64-gnu-debug

rust-bors · 2026-10-22T10:23:51Z

⌛ Trying commit 3e4d3ee with merge 326b86a…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/39762784913

Don't ignore unknown LLVM diagnostics try-job: test-x86_64-gnu-debug

rustbot assigned mati865 Oct 19, 2026

nikic mentioned this pull request Oct 19, 2026

Miscompilation on i686 at -C opt-level=1 with debug assertions (SIGILL) #164336

Open

This comment has been minimized.

Sign in to view

nikic force-pushed the llvm-diags branch from 7beba16 to abce4dc Compare October 19, 2026 13:14

mati865 approved these changes Oct 19, 2026

View reviewed changes

rust-bors Bot 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 Oct 20, 2026

JonathanBrouwer mentioned this pull request Oct 20, 2026

Rollup of 6 pull requests #164630

Closed

TechnoPorg mentioned this pull request Oct 20, 2026

Add unstable -Zllvm-tpde flag to rustc_codegen_llvm #164108

Open

JonathanBrouwer mentioned this pull request Oct 20, 2026

Rollup of 14 pull requests #164632

Closed

JonathanBrouwer mentioned this pull request Oct 20, 2026

Rollup of 13 pull requests #164634

Closed

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 20, 2026

This comment has been minimized.

Sign in to view

JonathanBrouwer mentioned this pull request Oct 21, 2026

Rollup of 14 pull requests #164697

Closed

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 21, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Oct 21, 2026

Auto merge of #164578 - nikic:llvm-diags, r=<try>

e83a3e0

Don't ignore unknown LLVM diagnostics try-job: test-x86_64-gnu-debug

This comment has been minimized.

Sign in to view

nikic added 4 commits October 22, 2026 09:33

Don't distinguish diagnostic kinds without special treatment

b5464fb

Merge the PGO, Unsupported into UnknownDiagnostic and rename it to Other. We don't do anything special for them, so there is no need to represent them differently.

Don't downgrade linker error to warning

87f93a5

Ignore stack size warnings for now

8cf7e20

This preserves the existing behavior. Enabling these warnings is tracked in a new issue.

nikic force-pushed the llvm-diags branch from 16e8e06 to 8cf7e20 Compare October 22, 2026 07:37

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Oct 22, 2026

Auto merge of #164578 - nikic:llvm-diags, r=<try>

f1ec490

Don't ignore unknown LLVM diagnostics try-job: test-x86_64-gnu-debug

This comment has been minimized.

Sign in to view

Normalize path in error message

3e4d3ee

Apparently this depends on where the tests are run from?

rust-bors Bot pushed a commit that referenced this pull request Oct 22, 2026

Auto merge of #164578 - nikic:llvm-diags, r=<try>

326b86a

Don't ignore unknown LLVM diagnostics try-job: test-x86_64-gnu-debug

Conversation

nikic commented Oct 19, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Oct 19, 2026

Uh oh!

This comment has been minimized.

mati865 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mati865 Oct 19, 2026

Choose a reason for hiding this comment

Uh oh!

mati865 Oct 19, 2026

Choose a reason for hiding this comment

Uh oh!

nikic Oct 19, 2026

Choose a reason for hiding this comment

Uh oh!

nikic commented Oct 20, 2026

Uh oh!

mati865 commented Oct 20, 2026

Uh oh!

rust-bors Bot commented Oct 20, 2026

Uh oh!

JonathanBrouwer commented Oct 20, 2026

Uh oh!

rust-bors Bot commented Oct 20, 2026

Uh oh!

This comment has been minimized.

JonathanBrouwer commented Oct 21, 2026

Uh oh!

JonathanBrouwer commented Oct 21, 2026

Uh oh!

rust-bors Bot commented Oct 21, 2026

Uh oh!

mati865 commented Oct 21, 2026

Uh oh!

mati865 commented Oct 21, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Oct 21, 2026

Uh oh!

This comment has been minimized.

rustbot commented Oct 22, 2026

Uh oh!

nikic commented Oct 22, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Oct 22, 2026

Uh oh!

rust-log-analyzer commented Oct 22, 2026

Uh oh!

nikic commented Oct 22, 2026

Uh oh!

rust-bors Bot commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

nikic commented Oct 19, 2026 •

edited by rustbot

Loading

mati865 left a comment •

edited by rustbot

Loading

rust-bors Bot commented Oct 22, 2026 •

edited

Loading