[Type checker] Reduce/isolate reuse of parent generic environments #6086
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
@swift-ci please smoke test and merge |
slavapestov
reviewed
Dec 6, 2016
lib/Sema/TypeCheckDecl.cpp
Outdated
Contributor
There was a problem hiding this comment.
We already have VarDecl::isSelfParameter()...
Member
Author
There was a problem hiding this comment.
Ugh! I was looking for that on ParamDecl. Thank you
slavapestov
reviewed
Dec 6, 2016
lib/AST/DeclContext.cpp
Outdated
Contributor
There was a problem hiding this comment.
maybe just isa<NominalTypeDecl>(this) then...
slavapestov
reviewed
Dec 6, 2016
lib/Sema/ITCDecl.cpp
Outdated
Contributor
There was a problem hiding this comment.
There's a constructor that takes a dc too, it's nicer
slavapestov
reviewed
Dec 6, 2016
lib/Sema/ITCDecl.cpp
Outdated
Contributor
There was a problem hiding this comment.
If the parameter is always non-null, it could be a reference
slavapestov
reviewed
Dec 6, 2016
test/decl/ext/generic.swift
Outdated
slavapestov
reviewed
Dec 6, 2016
lib/Sema/TypeCheckDecl.cpp
Outdated
Contributor
There was a problem hiding this comment.
reference instead of pointer maybe?
We cannot properly determine the context type of any parameter (including 'self') until after we have determined the generic environment for the enclosing function.
DeclContext's nomenclature around "type contexts" is confusing, because it essentially means "nominal type contexts", e.g., struct/class/enum/protocol and extensions thereof. This implies the presence of a 'Self' type, the ability to have members, etc. However, typealiases are also currently classified as "type contexts", despite not having a reasonable 'Self' type, which breaks in various places. Stop classifying typealiases as "type contexts".
Typealiases were getting type-checked in their parent's context, not their own context. For non-generic typealiases this is fine, because the generic environment is inherited. Generic typealiases, on the other hand, have their own generic environment that should be used. Do so.
This method gets the GenericTypeDecl for a typealias, nominal type, or extension thereof. While the result is typed as GenericTypeDecl, it's not always generic, so rename it accordingly. An audit of the callers illustrated that they should be using different entrypoints anyway, so fix all of the callers and make this function private.
…solver. PartialGenericTypeToArchetypeResolver is (eventually) going away. Isolate it's use to those places where we still rely on its odd behavior.
Stop using PartialGenericTypeToArchetypeResolver in extensions. It means Yet Another ArchetypeBuilder pass (for now).
The GenericTypeOrArchetypeResolver changes are effectively porting some existing hacks from the now-dead PartialGenericTypeOrArchetypeResolver, which dodges some regressions in the compiler-crashers suite and fixes 11 new crashers. There is undoubtedly a more principled approach to fix these problems, most of which now step from recursively looking for a generic environment that isn't there, but doing so requires improvements to our name lookup.
…vironment. This routine was passing a 'null' generic environment when it should, in fact, provide the generic environment for its context. Fixes a code-completion regression introduced by the removal of PartialGenericTypeToArchetypeResolver.
DougGregor
force-pushed
the
baby-steps-away-from-parent-environment
branch
from
592d9a6 to
553216a
Compare
Member
Author
|
@swift-ci please smoke test |
1 similar comment
Member
Author
|
@swift-ci please smoke test |
Member
Author
|
Linux build failed with something unrelated in LLVM: buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/branch-master/llvm/lib/Target/PowerPC/PPCMCInstLower.cpp:40:22: error: no member named 'Mang' in 'llvm::AsmPrinter' macOS build failed with an exception |
Member
Author
|
@swift-ci please smoke test |
Member
Author
|
@swift-ci please smoke test macOS |
Member
Author
|
@swift-ci please smoke test Linux |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The type checker is still reusing the archetypes from parent contexts in nested generic contexts, which is is both a mess (semantically) and means that we cannot add any new requirements to those archetypes, a source of numerous bugs. Take a few more concrete steps toward eliminating this reuse of parent archetypes:
selfparameter late, after we've had a change to create the generic environment for a functiontypealiasdeclarations with thetypealiasas the context, so we're in the right generic environment for generictypealiasdeclarationsPartialGenericTypeToArchetypeResolver, which handled the weird case of pulling archetypes from an outer context rather than the current context. Instead, be explicit about the places where we reuse archetypes by explicitly telling the archetype builder to reuse the parent archetypes.