You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: text/3389-manifest-lint.md
+28-1Lines changed: 28 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -135,7 +135,8 @@ cargo will:
135
135
- Leaving off the `tool::` when it is `rust`
136
136
- cargo will error if `lint` contains `::` as the first part is assumed to be
137
137
a tool and it should be listed in that tool's table
138
-
2. Sort them by priority and then lint name
138
+
2. Sort them by priority and then an unspecified order within priority that we may change in the [future](#future-possibilities).
139
+
- On initial release, the sort will likely be reverse alphabetical which would cause `all` to be last, making it unlikely to do what the user wants which would raise awareness of the need for setting `priority` for all groups.
139
140
3. Pass them on the command line before other configuration like
140
141
`RUSTFLAGS`, allowing user configuration to override package configuration.
141
142
- These flags will be fingerprinted so changing them will cause a rebuild only
@@ -351,6 +352,32 @@ Ruby
351
352
# Future possibilities
352
353
[future-possibilities]: #future-possibilities
353
354
355
+
## Help the user with `priority`
356
+
357
+
When running linters through cargo, we could warn the user when there is ambiguity, including
358
+
- A group and a lint at the same priority
359
+
- A group that is a superset of another group at the same priority
360
+
- Two intersecting groups at the same priority
361
+
- A lint or group that is masked by a group in a later priority
362
+
363
+
We could then take this a step further and change the way we sort within a
364
+
priority level to put the most specific entry last, where ambiguity doesn't
365
+
exist. This would nearly eliminate the need for specifying `priority` with the
366
+
current groups.
367
+
368
+
We specifically recommend warning, rather than error, so groups can evolve to
369
+
become intersecting without it being a breaking change.
370
+
371
+
To implement this, either cargo needs to pass the lints down to the tool in a
372
+
way to communicate the priority batches, allow cargo to query the group
373
+
memberships from the linter, or we hard code this at compile-time like
0 commit comments