-
Notifications
You must be signed in to change notification settings - Fork 201
getRestrictItem returns a lits of hints #1648
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
base: master
Are you sure you want to change the base?
getRestrictItem returns a lits of hints #1648
Conversation
The naive approach given in this PR fails, as some rules can be more specific and unrestrict things. Local test output:
Relevant import yaml: - modules:
- {name: HypotheticalModule1, as: HM1, asRequired: true}
- {name: HypotheticalModule2, importStyle: explicitOrQualified}
- {name: HypotheticalModule3, importStyle: qualified}
- {name: 'HypotheticalModule3.*', importStyle: unqualified}
- {name: 'HypotheticalModule3.OtherSubModule', importStyle: unrestricted, qualifiedStyle: post}
- {name: HypotheticalModule4, importStyle: qualified, as: HM4, asRequired: true}
- {name: HypotheticalModule5, importStyle: qualified, qualifiedStyle: post} So the idea is that we'd have the direct match rule for I'm updating my fix to do |
I've tested the patch on the reproduction repository and the patched version correctly reports the rule violation 🎉 |
Only sconcat if an exact match is found
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.
Suggest reviewing with whitespace changes hidden
Just exact -> | ||
[sconcat (exact NonEmpty.:| wildcard)] |
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.
This preserves the old behavior: take the exact
match and concat the rest of the rules into it.
Nothing -> | ||
wildcard |
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.
In this branch, we had no exact match, meaning that wildcard
contains all of the wildcard matches that hit. This means we have multiple wildcard rules that should be checked, and we probably don't want to combine these...
I can see some logic where "nested" rules should be combined, but totally disparate rules should not be. Like, Handler.**
and Handler.Foo.**
maybe should be combined because of the shared literal prefix. But **.*Spec
and Handler.**
should not, even though they have overlaps in Handler.FooSpec
.
13e58fa
to
1316708
Compare
This PR addresses #1647
Thanks for the pull request!
By raising this pull request you confirm you are licensing your contribution under all licenses that apply to this project (see LICENSE) and that you have no patents covering your contribution.
If you care, my PR preferences are at https://github.com/ndmitchell/neil#contributions, but they're all guidelines, and I'm not too fussy - you don't have to read them.