Skip to content

Rewrite config parsing for better span support #13084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Jarcho
Copy link
Contributor

@Jarcho Jarcho commented Jul 11, 2024

changelog: Improved spans on config errors.
rust-lang/rust-clippy#13084

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jul 11, 2024
Copy link
Member

@xFrednet xFrednet left a comment

Choose a reason for hiding this comment

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

I really like these changes! One tiny nit, then you can r=me :D

@xFrednet
Copy link
Member

Oh one more thing, do we maybe want to add a lint or warning, if the ".." is not in the last index? I feel like it could be confusing otherwise 🤔

@Jarcho
Copy link
Contributor Author

Jarcho commented Jul 13, 2024

I'm personally on the side that it should be first since this is extending an existing list. An ellipsis comes first when writing so the thing that's acting like one should also come first.

As for linting when it appears in the middle it might be worth it since it's otherwise silently ignored now.

@xFrednet
Copy link
Member

I'm personally on the side that it should be first since this is extending an existing list. An ellipsis comes first when writing so the thing that's acting like one should also come first.

I think for a single value, the other thing looks a bit better as in

x = ["custom", ".."]

But with multiple values and potentially multiple lines, it's definitely better to have it in the front. So, that should be our default suggestion.

It's probably easier to make this a warning, and not a lint, since we can then just emit it while reading the config file. It'd be good if this warning/lint could be part of this PR, but we could make it a followup PR, if you prefer.

@bors
Copy link
Contributor

bors commented Jul 17, 2024

☔ The latest upstream changes (presumably #13088) made this pull request unmergeable. Please resolve the merge conflicts.

@Jarcho
Copy link
Contributor Author

Jarcho commented Jul 18, 2024

Added a change to the metadata collector. Should this be changed back to printing [] for the default value of an empty array? msrv and trivial_copy_size_limit already didn't list a default value.

For the warning that requires changing how values are deserialized in order to get the span correct. I'll look into it.

@xFrednet
Copy link
Member

Hmm, I like having the default value for everything for consistency. For booleans etc we also display the default, even if it's the default of those values. So, I'd be in favor of keeping it.

I like that the original order of the values in the default configuration is now retained.

@Jarcho
Copy link
Contributor Author

Jarcho commented Jul 27, 2024

Latest change is basically a full rewrite using toml_edit instead or serde and toml. This lets us deserialize values with spans and get better error reporting. A bunch of misc. changes are included as well at the moment.

I'll be splitting this up later into multiple commits for easier reading, but you can get a feel for the end result with this. The diff is going to be totally useless right now.

bors added a commit that referenced this pull request Jul 29, 2024
Misc changes to `clippy_config`

Contains part of #13084

Changes include:
* Sort config list and each configs lint list.
* Add default text for the two configs that were missing it.
* Switch the lint list in the configs to an attribute.
* Make `dev fmt` sort the config list.

r? `@xFrednet`

changelog: none
@xFrednet
Copy link
Member

Could you rebase to include the changes from the last PR?

Copy link
Member

@xFrednet xFrednet left a comment

Choose a reason for hiding this comment

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

Tiny NIT, the rest looks good to me. We can merge this, once the commit has a proper name and the nit is fixed.

This PR was initially created to restrict the ".." value to the beginning or end. My understanding is that currently all positions are accepted again, right? Adding this restriction and a respective warning can be done in a followup, this PR is already quite large.

Comment on lines +611 to +623
macro_rules! deserialize_table {
($dcx:ident, $table:ident, $($name:ident($name_str:literal): $ty:ty,)+) => {
Copy link
Member

Choose a reason for hiding this comment

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

NIT: I think the usage if this macro is not self-explanatory. I would suggest adding a doc comment and renaming it to deserialize_table_row since it only processes one row.

Maybe:

Suggested change
macro_rules! deserialize_table {
($dcx:ident, $table:ident, $($name:ident($name_str:literal): $ty:ty,)+) => {
/// Can be used to deserialize a table row. Each column has a local
/// of type `Option<T>` that is filled, when the value is found.
///
/// Example usage:
/// ```
/// deserialize_table_row!(dcx, table,
/// path("path"): String,
/// reason("reason"): String,
/// );
/// ```
///
/// Example input:
/// ```toml
/// disallowed-methods = [
/// { path = "std::vec::Vec::leak", reason = "no leaking memory" },
/// # path = Some("std::vec::Vec::leak")
/// # reason = Some("no leaking memory")
///
/// { path = "std::time::Instant::now" },
/// # path = Some("std::vec::Vec::leak")
/// # reason = None
/// ]
/// ```
macro_rules! deserialize_table_row {
($dcx:ident, $table:ident, $($name:ident($name_str:literal): $ty:ty,)+) => {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What's this about rows? It can deserialize any toml table, both inline and regular. The TableLike trait is implemented for both.

Copy link
Member

Choose a reason for hiding this comment

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

Huh, I guess it depends on what you describe as a "table". I thought the whole disallowed-methods is a table, like this

path reason
"std::vec::Vec::leak" "std::vec::Vec::leak"
"std::time::Instant::now"

But I'm guessing now that you called { path = "std::vec::Vec::leak", reason = "no leaking memory" } a table?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, that's what you mean. The name is referring to a toml table.

Copy link
Member

Choose a reason for hiding this comment

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

Okay, then we can keep it like this. Could you rename the commit and fix the last error? Then we can merge this :D

@xFrednet
Copy link
Member

xFrednet commented Aug 2, 2024

Have you seen my question from the last review:

This PR was initially created to restrict the ".." value to the beginning or end. My understanding is that currently all positions are accepted again right? Adding this restriction and a respective warning can be done in a followup, this PR is already quite large.

@bors
Copy link
Contributor

bors commented Aug 6, 2024

☔ The latest upstream changes (presumably #13225) made this pull request unmergeable. Please resolve the merge conflicts.

@xFrednet
Copy link
Member

I'm unassigning myself from this PR. @Jarcho if you want to continue this work, please request a new reviewer with r? clippy

@xFrednet xFrednet removed their assignment Mar 16, 2025
@rustbot

This comment has been minimized.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Mar 31, 2025
@Jarcho Jarcho force-pushed the conf_refactor branch 3 times, most recently from 7cf2738 to 219d1ec Compare April 12, 2025 20:54
@Jarcho
Copy link
Contributor Author

Jarcho commented Apr 12, 2025

r? clippy

@Jarcho Jarcho changed the title Make extendable configs easier to add Rewrite config parsing for better span support Apr 12, 2025
@Jarcho Jarcho force-pushed the conf_refactor branch 2 times, most recently from 0ec2bd5 to 22cfaaa Compare April 12, 2025 21:25
@Jarcho
Copy link
Contributor Author

Jarcho commented Apr 12, 2025

disallow_span_lint is removed because the path to clippy.toml isn't normalized (it's in a parent directory of the test). It's a pretty low value test that only checks that clippy has it's own config file set correctly so away it goes.

The part has been split from this PR.

Failing run

@rustbot

This comment has been minimized.

@Jarcho Jarcho force-pushed the conf_refactor branch 4 times, most recently from 141033c to 2bf8a6b Compare April 21, 2025 01:54
@Jarcho
Copy link
Contributor Author

Jarcho commented Apr 21, 2025

@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 from the author. (Use `@rustbot ready` to update this status) labels Apr 21, 2025
@rustbot

This comment has been minimized.

* More precise spans in diagnostics
* Allow multiple diagnostics for each config value
* Ability to capture spans in the parsed config
* Easier support of `..` in lists
* Remove `clippy_utils` dependancy from `clippy_config`
* Multi-column support for long suggestion lists
@rustbot
Copy link
Collaborator

rustbot commented May 4, 2025

☔ The latest upstream changes (possibly ea13461) made this pull request unmergeable. Please resolve the merge conflicts.

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants