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

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)

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

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

rust-bors · 2026-10-22T12:32:43Z

☀️ Try build successful (CI)
Build commit: 326b86a (326b86a089984d17f6a9d72e3577b9daf3f5cd6b)
Base parent: f8125e4 (f8125e48dc669320b4e5e83487dcbfb681957961)

nikic · 2026-10-26T08:20:06Z

@rustbot ready

mati865

@bors r+

View changes since this review

rust-bors · 2026-10-26T10:33:39Z

📌 Commit 3e4d3ee has been approved by mati865

It is now in the queue for this repository.

mati865 · 2026-10-26T10:44:04Z

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...

Maybe not only ones with DiagnosticLocation? Currently LLVM errors look very raw and provide user with no hints on what to do. I remember the first time I encountered LLVM error from rustc I wasn't sure if that was compiler bug or my code is wrong.
Feels even more out of place currently, given how well rustc diagnostics are, even for ICEs.

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 #146393.

rust-bors · 2026-10-26T12:30:48Z

💔 Test for 42df3ea failed: CI. Failed job:

auto - test-aarch64-msvc-1 (web logs, enhanced plaintext logs)

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

Apparently this depends on where the tests are run from?

nikic · 2026-10-26T13:27:15Z

Meh. Dropped the forced -C opt-level=0 for the unoptimized revision of huge-stacks.rs again, because that fails on aarch64-pc-windows-msvc. Failure tracked at #164988.

@bors try jobs=test-aarch64-msvc-1

Don't ignore unknown LLVM diagnostics try-job: test-aarch64-msvc-1

rust-bors · 2026-10-26T15:55:53Z

☀️ Try build successful (CI)
Build commit: 0e10d56 (0e10d56fb6f1e4b2ad9d5ccfcfe310c29609f8fd)
Base parent: 019b59d (019b59d8101bb3e141f1b880684747b4217beeb6)

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

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

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 26, 2026

mati865 approved these changes Oct 26, 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 26, 2026

This comment has been minimized.

Sign in to view

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

nikic mentioned this pull request Oct 26, 2026

huge-stacks.rs with -C opt-level=0 fails on aarch64-pc-windows-msvc with LLVM error #164988

Open

nikic added 2 commits October 26, 2026 14:24

Ignore stack size warnings for now

98d6ec1

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

Normalize path in error message

4980e18

Apparently this depends on where the tests are run from?

nikic force-pushed the llvm-diags branch from 3e4d3ee to 4980e18 Compare October 26, 2026 13:25

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-review Status: Awaiting review from the assignee but also interested parties. labels Oct 26, 2026

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

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

0e10d56

Don't ignore unknown LLVM diagnostics try-job: test-aarch64-msvc-1

This comment has been minimized.

Sign in to view

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.

rust-bors Bot commented Oct 22, 2026

Uh oh!

This comment has been minimized.

nikic commented Oct 22, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Oct 22, 2026

Uh oh!

nikic commented Oct 26, 2026

Uh oh!

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!

rust-bors Bot commented Oct 26, 2026

Uh oh!

mati865 commented Oct 26, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Oct 26, 2026

Uh oh!

nikic commented Oct 26, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Oct 26, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

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

mati865 left a comment •

edited by rustbot

Loading