-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Make extendable configs easier to add #13084
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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
Oh one more thing, do we maybe want to add a lint or warning, if the |
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. |
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. |
☔ The latest upstream changes (presumably #13088) made this pull request unmergeable. Please resolve the merge conflicts. |
Added a change to the metadata collector. Should this be changed back to printing For the warning that requires changing how values are deserialized in order to get the span correct. I'll look into it. |
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. |
Latest change is basically a full rewrite using 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. |
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
Could you rebase to include the changes from the last PR? |
There was a problem hiding this 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.
macro_rules! deserialize_table { | ||
($dcx:ident, $table:ident, $($name:ident($name_str:literal): $ty:ty,)+) => { |
There was a problem hiding this comment.
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:
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,)+) => { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Have you seen my question from the last review:
|
☔ The latest upstream changes (presumably #13225) made this pull request unmergeable. Please resolve the merge conflicts. |
Two small behaviour changes:
".."
as their first item to extend the default (even if there is none).".."
rather than any item in the list. A quick search showed it mostly used as the final item, rarely as the first, and once appearing in the middle. Ideally this would only support one position.r? @xFrednet
changelog: All configurations with list can now use
".."
in the first or last argument to extend the default.".."
values in the middle of the list will now issue a warning, that they should be moved to the start or end.#13084