Skip to content

Remove validateDeclForNameLookup and related logic #24957

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

Closed

Conversation

xymus
Copy link
Contributor

@xymus xymus commented May 21, 2019

validateDeclForNameLookup was a phase executed before validateDecl on some decls to avoid cycles. We already moved its work to be lazier, so we don't need this phase anymore. Calling validateDecl is enough as it relies on the new lazy services to avoid cycles.

The next goal is to make lazy more of the logic in validateDecl so it is evaluated only when it is actually needed.

@xymus
Copy link
Contributor Author

xymus commented May 21, 2019

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented May 21, 2019

@swift-ci Please test source compatibility

@slavapestov
Copy link
Contributor

I believe you can remove {LazyResolver,TypeChecker}::resolveProtocolEnvironment() now, too.

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from 7a49ec1 to b3f375c Compare June 17, 2019 21:05
@xymus
Copy link
Contributor Author

xymus commented Jun 17, 2019

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Jun 17, 2019

@swift-ci Please test source compatibility

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from b3f375c to 6f0b915 Compare June 18, 2019 22:34
@xymus
Copy link
Contributor Author

xymus commented Jun 18, 2019

@swift-ci Please test source compatibility

@xymus
Copy link
Contributor Author

xymus commented Jun 18, 2019

@swift-ci Please smoke test

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from 6f0b915 to 9d76ff7 Compare June 21, 2019 17:28
@xymus
Copy link
Contributor Author

xymus commented Jun 21, 2019

@swift-ci Please test source compatibility

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from 9d76ff7 to 761cd67 Compare July 10, 2019 16:46
@xymus
Copy link
Contributor Author

xymus commented Jul 10, 2019

@swift-ci Please test source compatibility

@xymus
Copy link
Contributor Author

xymus commented Jul 10, 2019

@swift-ci Please smoke test

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch 2 times, most recently from 6b4d88f to c715c51 Compare July 24, 2019 20:37
@xymus
Copy link
Contributor Author

xymus commented Jul 24, 2019

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Jul 24, 2019

@swift-ci Please test source compatibility

Copy link
Contributor

@slavapestov slavapestov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few suggestions you might want to look at. The only important one is the removal of the requestNominalLayout() call.

auto aliasDecl = dyn_cast<TypeAliasDecl>(typeDecl);
if (resolution.getStage() == TypeResolutionStage::Structural &&
aliasDecl && !aliasDecl->getGenericParams() &&
!aliasDecl->getUnderlyingTypeLoc().wasValidated()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a similar check in getStructuralType() in GenericSignatureBuilder.cpp. Maybe TypeAliasDecl::getStructuralType() should automatically return the checked underlying type if its available.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've applied the suggested change to TypeAliasDecl::getStructuralType. I'll leave this check here because we still want to execute TypeChecker::resolveTypeInContext if the type was previously validated, it provides better diagnostics.

static Type substMemberTypeWithBase(ModuleDecl *module, TypeDecl *member,
Type baseTy, bool useArchetypes = true);
Type baseTy, bool useArchetypes = true,
TypeResolutionStage stage = TypeResolutionStage::Interface);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe if you pass in a TypeResolution instead of a TypeResolutionStage, you can combine the useArchetypes and state parameters into one; useArchetypes then just becomes resolution.usesArchetypes().

generic);
if (!type)
type =
TypeChecker::resolveTypeInContext(typeDecl, foundDC, resolution,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should getting the structural type be pushed down into resolveTypeInContext(), since it has access to the resolution object?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably could, but we also need to avoid the call to the previous resolveDeclSignature because it triggers validateDecl.

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from c715c51 to 12598ba Compare July 24, 2019 23:32
@xymus
Copy link
Contributor Author

xymus commented Jul 24, 2019

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Jul 24, 2019

@swift-ci Please test source compatibility

1 similar comment
@xymus
Copy link
Contributor Author

xymus commented Jul 25, 2019

@swift-ci Please test source compatibility

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch 2 times, most recently from 68dcec4 to 96e4e97 Compare August 1, 2019 17:22
@xymus
Copy link
Contributor Author

xymus commented Aug 1, 2019

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Aug 1, 2019

@swift-ci Please test source compatibility

1 similar comment
@xymus
Copy link
Contributor Author

xymus commented Aug 1, 2019

@swift-ci Please test source compatibility

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from 96e4e97 to 3daaeaf Compare August 5, 2019 17:03
@xymus
Copy link
Contributor Author

xymus commented Aug 5, 2019

@swift-ci Please test source compatibility

@xymus
Copy link
Contributor Author

xymus commented Aug 5, 2019

@swift-ci Please smoke test

@@ -1024,7 +1021,12 @@ class TypeChecker final : public LazyResolver {
void checkDefaultArguments(ParameterList *params, ValueDecl *VD);

virtual void resolveDeclSignature(ValueDecl *VD) override {
validateDeclForNameLookup(VD);
auto dc = VD->getDeclContext();
if (auto nominal = dyn_cast<NominalTypeDecl>(dc)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be necessary?

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from 3daaeaf to a9de890 Compare August 9, 2019 22:30
@xymus
Copy link
Contributor Author

xymus commented Aug 9, 2019

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Aug 9, 2019

@swift-ci Please test source compatibility

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from a9de890 to 367ce21 Compare August 12, 2019 17:02
@xymus
Copy link
Contributor Author

xymus commented Aug 12, 2019

@swift-ci Please test source compatibility

It passed the source compat suite, now trying again with one less hack.

@xymus
Copy link
Contributor Author

xymus commented Aug 12, 2019

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Aug 12, 2019

@swift-ci Please test source compatibility

@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from 367ce21 to 49e9609 Compare August 12, 2019 22:57
@xymus
Copy link
Contributor Author

xymus commented Aug 12, 2019

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Aug 12, 2019

@swift-ci Please test source compatibility

xymus added 9 commits August 20, 2019 14:58
This fixes an issue with protocol compositions using a typealias of
anoter protocol composition causing a difference between the flat
structural type and the nested underlying TypeRepr.
With the recent change to StructuralTypeRequest where all returned types
are wrapped in a TypeAliasType, printing the requirement signature
could display requirements such as `Self.P3Assoc == Self.P3Assoc`.
This change will make sure that when in debug mode, the underlying type
will be displayed instead on the RHS.
@xymus xymus force-pushed the remove-validateDeclForNameLookup branch from 49e9609 to 87be387 Compare August 20, 2019 23:11
@xymus
Copy link
Contributor Author

xymus commented Aug 20, 2019

@swift-ci Please test source compatibility

@xymus
Copy link
Contributor Author

xymus commented Aug 20, 2019

@swift-ci Please smoke test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants