-
Notifications
You must be signed in to change notification settings - Fork 583
Add lint rule to disallow shadowing when it looks buggy #365
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
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 think this is ready to go, although I had a few low-level questions about nil and copying.
The semantics are closer to a "compiler extension", where only legitimately incorrect code is illegal, and I'd prefer a "lint rule" style, where confusing or possibly-mistaken code is illegal too. But I don't mind either one for our code base as long as we're running something.
Updated with some CFA changes; I actually really like how it is now. |
@@ -3193,7 +3193,7 @@ func (r *Relater) structuredTypeRelatedToWorker(source *Type, target *Type, repo | |||
var originalErrorChain *ErrorChain | |||
saveErrorState := r.getErrorState() | |||
relateVariances := func(sourceTypeArguments []*Type, targetTypeArguments []*Type, variances []VarianceFlags, intersectionState IntersectionState) (Ternary, bool) { | |||
if result := r.typeArgumentsRelatedTo(sourceTypeArguments, targetTypeArguments, variances, reportErrors, intersectionState); result != TernaryFalse { | |||
if result = r.typeArgumentsRelatedTo(sourceTypeArguments, targetTypeArguments, variances, reportErrors, intersectionState); result != TernaryFalse { |
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 one is legitimately a bug.
This is a version of #357 but with custom lint rule which uses a control flow graph to determine when variable shadowing could never cause a negative side effect (the shadowing cannot flow into any code that uses the shadowed/outer variable). This reduces the number of false positives, and in one instance actually found an extra shadow that the lint rule in #357 didn't catch due to this PR being stricter about closing over outer variables.
Perf testing shows that this lint rule does not have any negative performance impact to linting (I have found other places that cause it to be slow).