Skip to content

make more diagnostic structs pub(crate) - #160744

Open
mejrs wants to merge 2 commits into
rust-lang:mainfrom
mejrs:struct-diagnostics-privacy
Open

make more diagnostic structs pub(crate)#160744
mejrs wants to merge 2 commits into
rust-lang:mainfrom
mejrs:struct-diagnostics-privacy

Conversation

@mejrs

@mejrs mejrs commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

No description provided.

It was never used in that crate, so rustc_parse is the next obvious place to go. It's also used by rustc_hir_typeck, but sharing diagnostics between crates makes it easy for such things to become dead, so duplicate it.
@rustbot

rustbot commented Aug 8, 2026

Copy link
Copy Markdown
Collaborator

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

HIR ty lowering was modified

cc @fmease

@rustbot rustbot added 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 Aug 8, 2026
@rustbot

rustbot commented Aug 8, 2026

Copy link
Copy Markdown
Collaborator

r? @khyperia

rustbot has assigned @khyperia.
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 75 candidates
  • Random selection from 18 candidates

@rust-log-analyzer

This comment has been minimized.

@mejrs
mejrs force-pushed the struct-diagnostics-privacy branch from d292479 to 4077d5c Compare August 8, 2026 11:31
"parentheses are required to parse this as an expression",
applicability = "machine-applicable"
)]
pub struct ExprParenthesesNeeded {

@JonathanBrouwer JonathanBrouwer Aug 8, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This PR duplicates this struct to make it pub(crate), I think having less code is better even if that means having that code be public.
rustc_session is a weird place for this diagnostic to be tho... Is there a better place?

View changes since the review

@mejrs mejrs Aug 8, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This PR duplicates this struct to make it pub(crate), I think having less code is better even if that means having that code be public.

The downside of having diagnostic structs pub is that it's easy for these things to become orphaned or for crates to depend on other crates for just a diagnostic. So usually I prefer duplicating over having things public See also #155364

I think the risk of that for this one is particularly low, up to you if you would rather have less duplication.

Is there a better place?

rustc_parse would be the natural place, that's the first time it's used.

@JonathanBrouwer JonathanBrouwer Aug 8, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think I'd rather risk this specific diagnostic becoming orphaned, rather than having it be duplicated. This is personal taste tho and I can see arguments for either option.

We can consider moving the sole copy to rustc_parse and adding a dependency from rustc_hir_typeck to rustc_parse. The indirect dependency already exists (rustc_hir_typeck -> rustc_lint -> rustc_attr_parsing -> rustc_parse). Tho that does risk exactly what you mentioned, where rustc_hir_typeck depends only on rustc_parse for the diagnostic, so meh

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Right, that's why I duplicated it :)

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

Labels

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.

5 participants