-
Notifications
You must be signed in to change notification settings - Fork 10.5k
AST: Optimize removeShadowedDecls() #32034
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
AST: Optimize removeShadowedDecls() #32034
Conversation
@swift-ci Please smoke test |
Previously, whenever name lookup returned two declarations with the same name, we would compute the canonical type of each one as part of the shadowing check. The canonical type calculation is rather expensive for GenericFunctionTypes since it requires constructing a GenericSignatureBuilder to canonicalize type parameters that appear in the function's signature. Instead, let's first shard all declarations that have the same name by their generic signature. If two declarations have the same signature, only then do we proceed to compute their canonical type. Since computing a canonical GenericSignature is cheaper than computing a canonical GenericFunctionType, this should speed up name lookup of heavily-overloaded names, such as operators. Fixes <rdar://problem/56800097>.
817a226
to
6ca148d
Compare
@swift-ci Please smoke test |
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.
Looks great!
@swift-ci Please test compiler performance |
// If the decl is currently being validated, this is likely a recursive | ||
// reference and we'll want to skip ahead so as to avoid having its type | ||
// attempt to desugar itself. | ||
if (decl->isRecursiveValidation()) |
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.
Is this the right re-entrancy guard? We may be able to scale back to isComputingGenericSignature
.
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.
Well, we compute the interface type immediately below anyway. I kept the same guard as before because I didn't want to introduce a subtle behavioral difference here. I suspect we might be able to get away with removing these guards at some point, if not now. They're extremely unprincipled.
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.
Approach LGTM
@swift-ci Please smoke test Linux |
3 similar comments
@swift-ci Please smoke test Linux |
@swift-ci Please smoke test Linux |
@swift-ci Please smoke test Linux |
@swift-ci Please clean smoke test Linux |
Previously, whenever name lookup returned two declarations with the same
name, we would compute the canonical type of each one as part of the
shadowing check.
The canonical type calculation is rather expensive for GenericFunctionTypes
since it requires constructing a GenericSignatureBuilder to canonicalize
type parameters that appear in the function's signature.
Instead, let's first shard all declarations that have the same name by
their generic signature. If two declarations have the same signature, only
then do we proceed to compute their canonical type.
Since computing a canonical GenericSignature is cheaper than computing a
canonical GenericFunctionType, this should speed up name lookup of
heavily-overloaded names, such as operators.
Fixes rdar://problem/56800097.