Skip to content

Conversation

mu001999
Copy link
Contributor

@mu001999 mu001999 commented Sep 24, 2025

Fixes #146968

Emit error CfgPredicateIdentifier if the word is path-segment keyword.

Disallow using path-segment keyword when parsing cfg pred

r? petrochenkov

@rustbot
Copy link
Collaborator

rustbot commented Sep 24, 2025

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) 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. labels Sep 24, 2025
@petrochenkov
Copy link
Contributor

Could you

  • add similar test cases for some non path-segment keyword, like struct
  • add test cases for --cfg on command line and make sure that they behave identically to cfg! and #[cfg].

After that we should be able to run crater on this.
@rustbot author

@rustbot rustbot 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 Sep 26, 2025
@rustbot
Copy link
Collaborator

rustbot commented Sep 26, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 505d13f to b2be57d Compare September 27, 2025 03:24
@rustbot
Copy link
Collaborator

rustbot commented Sep 27, 2025

This PR was rebased onto a different master 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.

@mu001999
Copy link
Contributor Author

add test cases for --cfg on command line and make sure that they behave identically to cfg! and #[cfg]

--cfg will emit same error but will be suppressed because parse_cfg is called with ParseSess::with_fatal_emitter

@mu001999
Copy link
Contributor Author

@rustbot ready

@rustbot 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 Sep 27, 2025
@petrochenkov
Copy link
Contributor

add test cases for --cfg on command line and make sure that they behave identically to cfg! and #[cfg]

--cfg will emit same error but will be suppressed because parse_cfg is called with ParseSess::with_fatal_emitter

with_fatal_emitter doesn't suppress errors, it makes them fatal.
--cfg parsing has its own error reporting logic in fn parse_cfg in compiler\rustc_interface\src\interface.rs, and the new errors are not emitted there.
@rustbot author

@rustbot rustbot 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 Sep 30, 2025
@mu001999
Copy link
Contributor Author

with_fatal_emitter doesn't suppress errors, it makes them fatal.

@petrochenkov I found with_fatal_emitter create dcx with FatalOnlyEmitter, see

pub fn with_fatal_emitter(locale_resources: Vec<&'static str>, fatal_note: String) -> Self {
let translator = Translator::with_fallback_bundle(locale_resources, false);
let sm = Arc::new(SourceMap::new(FilePathMapping::empty()));
let fatal_emitter =
Box::new(HumanEmitter::new(stderr_destination(ColorConfig::Auto), translator));
let dcx = DiagCtxt::new(Box::new(FatalOnlyEmitter {
fatal_emitter,
fatal_note: Some(fatal_note),
}))
.disable_warnings();
ParseSess::with_dcx(dcx, sm)
}

and the comment of FatalOnlyEmitter and the impl of FatalOnlyEmitter::emit_diagnostic show only errors with diag.level == Level::Fatal can be emitted, see

/// An emitter that does nothing when emitting a non-fatal diagnostic.
/// Fatal diagnostics are forwarded to `fatal_emitter` to avoid silent
/// failures of rustc, as witnessed e.g. in issue #89358.
pub struct FatalOnlyEmitter {
pub fatal_emitter: Box<dyn Emitter + DynSend>,
pub fatal_note: Option<String>,
}
impl Emitter for FatalOnlyEmitter {
fn source_map(&self) -> Option<&SourceMap> {
None
}
fn emit_diagnostic(&mut self, mut diag: DiagInner, registry: &Registry) {
if diag.level == Level::Fatal {
if let Some(fatal_note) = &self.fatal_note {
diag.sub(Level::Note, fatal_note.clone(), MultiSpan::new());
}
self.fatal_emitter.emit_diagnostic(diag, registry);
}
}
fn translator(&self) -> &Translator {
self.fatal_emitter.translator()
}
}

@mu001999
Copy link
Contributor Author

mu001999 commented Sep 30, 2025

I have debug the logic in fn parse_cfg, and the err.emit is called in fact, but it is suppressed by the FatalOnlyEmitter.

@petrochenkov
Copy link
Contributor

petrochenkov commented Sep 30, 2025

Ah, ok, "fatal emitter" means "fatal-only emitter".

In any case, the behavior is not correct.
I guess the assumption when using the fatal emitter was that we always reach the "expected key or key="value"" error at the bottom anyway, but that's not actually the case.
If we get to return (ident.name, meta_item.value_str()), then all the non-fatal errors are lost, which is incorrect.

@mu001999 mu001999 marked this pull request as draft October 9, 2025 06:02
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 956aa91 to 97cd2c7 Compare October 9, 2025 11:16
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 97cd2c7 to a7d6090 Compare October 9, 2025 11:54
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from a7d6090 to c8bc460 Compare October 9, 2025 15:31
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from cc53ca4 to 9c2ed4c Compare October 9, 2025 18:10
@rustbot rustbot added the F-explicit_tail_calls `#![feature(explicit_tail_calls)]` label Oct 9, 2025
@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 9c2ed4c to 9a7fa91 Compare October 10, 2025 05:50
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 9a7fa91 to 8cffc8c Compare October 10, 2025 17:28
@rust-log-analyzer

This comment has been minimized.

@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 8cffc8c to 11bc8bb Compare October 11, 2025 02:14
@mu001999 mu001999 force-pushed the fix/path-kw-as-cfg-pred branch from 11bc8bb to 56cda64 Compare October 11, 2025 09:40
@mu001999 mu001999 marked this pull request as ready for review October 11, 2025 11:28
@rustbot 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 11, 2025
@mu001999
Copy link
Contributor Author

@rustbot ready

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) F-explicit_tail_calls `#![feature(explicit_tail_calls)]` 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.

cfg!($crate), cfg!(crate), cfg!(self), cfg!(Self), and cfg!(super) should not be accepted

4 participants