In <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id=

`rustc_macros`: Make it possible to derive both `Diagnostic` and `LintDiagnostic` on the same type about rust HOT 4 OPEN

fmease commented on June 7, 2024

`rustc_macros`: Make it possible to derive both `Diagnostic` and `LintDiagnostic` on the same type

from rust.

Comments (4)

fmease commented on June 7, 2024 5

I'll probably investigate getting rid of emit_span_lint, emit_node_span_lint and the like in favor of emit_lint etc. (no span / multi-span parameter) and storing the span(s) of LintDiagnostics in the lint diagnostic structs themselves via #[primary_span] which seems to be the most logical approach. However, it'll require updating all existing lint diagnostic structs.

cc @nnethercote

from rust.

compiler-errors commented on June 7, 2024

Yep, I think that LintDiagnostics should be responsible for providing the primary_span to the underlying lint function, just like they do for their primary message. This should be pretty easy to do 👍

from rust.

fmease commented on June 7, 2024

Ah, that's annoying. We can't simply leverage Diag::span (inside LintDiagnostic::decorate_lint) unlike Diagnostic because lint_level (lint_level_impl) needs access to the (multi) span before decorate'ing the Diag to suppress lints whose spans come from an external macro (and to disable suggestions):

rust/compiler/rustc_middle/src/lint.rs

Lines 333 to 351 in 4eedf73

 if err.span.primary_spans().iter().any(|s| in_external_macro(sess, *s)) { 

 // Any suggestions made here are likely to be incorrect, so anything we 

 // emit shouldn't be automatically fixed by rustfix. 

 err.disable_suggestions(); 

 // If this is a future incompatible that is not an edition fixing lint 

 // it'll become a hard error, so we have to emit *something*. Also, 

 // if this lint occurs in the expansion of a macro from an external crate, 

 // allow individual lints to opt-out from being reported. 

 let incompatible = future_incompatible.is_some_and(|f| f.reason.edition().is_none()); 

 if !incompatible && !lint.report_in_external_macro { 

 err.cancel(); 

 // Don't continue further, since we don't want to have 

 // `diag_span_note_once` called for a diagnostic that isn't emitted. 

 return; 

 } 

 }

By the way, I've already migrated all lint diagnostic structs to the new system.

The only solution I see is adding a span method to trait LintDiagnostic (similar to the existing msg method) which I really wanted to avoid because it makes the API more complicated and bloats the generated code.

from rust.

fmease commented on June 7, 2024

Right now, my patched rustc fails to build std because of that >.<

from rust.

Recommend Projects

`rustc_macros`: Make it possible to derive both `Diagnostic` and `LintDiagnostic` on the same type about rust HOT 4 OPEN

Comments (4)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	if err.span.primary_spans().iter().any(\|s\| in_external_macro(sess, *s)) {
	// Any suggestions made here are likely to be incorrect, so anything we
	// emit shouldn't be automatically fixed by rustfix.
	err.disable_suggestions();

	// If this is a future incompatible that is not an edition fixing lint
	// it'll become a hard error, so we have to emit something. Also,
	// if this lint occurs in the expansion of a macro from an external crate,
	// allow individual lints to opt-out from being reported.
	let incompatible = future_incompatible.is_some_and(\|f\| f.reason.edition().is_none());

	if !incompatible && !lint.report_in_external_macro {
	err.cancel();

	// Don't continue further, since we don't want to have
	// `diag_span_note_once` called for a diagnostic that isn't emitted.
	return;
	}
	}