-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Refactor applicability to use safe and unsafe #7819
Conversation
63d56d6
to
b3f5bba
Compare
Here we structure applicability as two enumerations
We could also consider a flat structure
or a structure that more closely matches when it is applicable / safe
(implemented in #7821) |
CodSpeed Performance ReportMerging #7819 will degrade performances by 3.35%Comparing Summary
Benchmarks breakdown
|
b3f5bba
to
c5ae2f1
Compare
PR Check ResultsEcosystem✅ ecosystem check detected no changes. |
Closing in favor of #7821 |
Following much discussion for #4181 at #5119, #5476, #7769, #7819, and in [Discord](https://discord.com/channels/1039017663004942429/1082324250112823306/1159144114231709746), this pull request changes `Applicability` from using `Automatic`, `Suggested`, and `Manual` to `Always`, `Sometimes`, and `Never`. Also removes `Applicability::Unspecified` (replacing #7792).
After working with the previous change in #7821 I found the names a bit unclear and their relationship with the user-facing API muddied. Since the applicability is exposed to the user directly in our JSON output, I think it's important that these names align with our configuration options. I've replaced `Manual` or `Never` with `Display` which captures our intent for these fixes (only for display). Here, we create room for future levels, such as `HasPlaceholders`, which wouldn't fit into the `Always`/`Sometimes`/`Never` levels. Unlike #7819, this retains the flat enum structure which is easier to work with.
Following much discussion for #4181 at #5119, #5476, #7769, #7819, and in [Discord](https://discord.com/channels/1039017663004942429/1082324250112823306/1159144114231709746), this pull request changes `Applicability` from using `Automatic`, `Suggested`, and `Manual` to `Always`, `Sometimes`, and `Never`. Also removes `Applicability::Unspecified` (replacing #7792).
After working with the previous change in #7821 I found the names a bit unclear and their relationship with the user-facing API muddied. Since the applicability is exposed to the user directly in our JSON output, I think it's important that these names align with our configuration options. I've replaced `Manual` or `Never` with `Display` which captures our intent for these fixes (only for display). Here, we create room for future levels, such as `HasPlaceholders`, which wouldn't fit into the `Always`/`Sometimes`/`Never` levels. Unlike #7819, this retains the flat enum structure which is easier to work with.
Following much discussion for #4181 at #5119, #5476, #7769, and in Discord, this pull request changes
Applicability
from usingSuggested
for uncertain fixes toUnsafe
.Also removes
Applicability::Unspecified
(replacing #7792).I have some qualms about how we will explain "manual" fixes to users which are a type of unsafe fix that cannot be applied programmatically. However, since manual fixes are not presented to the user after #7769 we can worry about this in the future.