-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Kill off some usages of the DeclChecker::IsFirstPass bit #15420
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
Kill off some usages of the DeclChecker::IsFirstPass bit #15420
Conversation
2f28657
to
e0d1ccc
Compare
…by an Objective-C generic parameter In general it's fine to emit a diagnostic but leave the conformance valid here, we're not going to go on to emit code, and an ErrorType here causes other diagnostics to be not be emitted in a test due to minor validation order perturbations.
This is already handled by the common redeclaration check.
…pass' Since protocol members no longer get visited in the 'second pass', change functions, constructors, associated types and pattern bindings to check accessibility in the first pass.
The diagnostic change is harmless. The diagnostic that is no longer being emitted was intended for multi-file conformance checking only, and we still emit a diagnostic for the overall conformance failure with missing witnesses.
e0d1ccc
to
24ac4f5
Compare
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
@swift-ci Please smoke test compiler performance |
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.
Hi @slavapestov – I can mark this as reviewed, but I'm not sure what value I'm adding here. While I've been experimenting with the code recently, I don't feel like I intuitively understand it yet.
Also, if you weren't trying to rid us of IsFirstPass
, I'd request that it be renamed to something semantically meaningful. :-)
What I'd really like to see (and this is separable feedback) is for some deduplication of logic in parallel Decl validation paths. For example, the nominal decls do very similar things for the most part, but it isn't clear which differences are essential and which are accidental.
@davezarzycki You've been working on this area recently cleaning up the various state bits and we had the forum discussion so I wanted to bring these PRs to your attention. I'm not looking for any specific feedback, but if you have any I'm happy to listen! My goal is to completely eliminate Cleaning up duplication between the various typeCheck and validateDecl cases would be nice. In addition to the ones you pointed out, there is also duplication between functions, constructors and destructors, in particular the manner in which we calculate the generic function type. My approach so far as been to avoid attacking the 'surface-level' duplication, and instead try to simplify the underlying APIs so that there's less stuff to de-duplicate later. Also, I've been trying to make more fundamental structural changes to the declaration checker, like simplifying how we detect and track circularity, and this current project to eliminate passes. I hope that after enough iteration of this, the duplication will go away on its own. |
The SwifterSwift failure is in expression type checking and not related to my changes (and since the expression type checker ran it probably means the decl checker was OK). |
Follow-up to #15408. For most declaration kinds, moves all of the type checking work to the 'first pass'. Classes, enums, functions and pattern binding decls still remain. Once those are done, we'll be doing nothing in the 'second pass', at which point the flag and walk over the AST can be removed.