[Sema] Fix spurious use_local_before_declaration errors. #16967
Merged
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
When performing name lookup for UnresolvedDeclRefExpr, if a local declaration after use is detected, we check outer results to see if we can find better matching candidates before raising a use_local_before_declaration error. Resolves: SR-7660.
|
I think it would make more sense if name lookup was driven by a source location and didn’t find declarations before their definition at all. |
|
@DougGregor is probably the best person to review this and give guidance. |
DougGregor
approved these changes
Jun 4, 2018
| if (Loc.isValid() && D->getLoc().isValid() && | ||
| D->getDeclContext()->isLocalContext() && | ||
| D->getDeclContext() == DC && | ||
| Context.SourceMgr.isBeforeInBuffer(Loc, D->getLoc())) { |
There was a problem hiding this comment.
This check is necessary, but not sufficient for all cases. For example, a variable in a guard cannot be used within the else of that guard:
guard let x = someOptional else { /* x is not visible here */ }
However, I think that's okay: this pull request is about improving on the current situation, and as the FIXME notes, ASTScope-based name lookup is the full answer. More importantly, it's not wrong to do what this new code is doing, i.e., it won't reject valid code.
|
@swift-ci please smoke test |
|
Thanks for the comments and review. |
|
@swift-ci please smoke test |
DougGregor
added a commit
to DougGregor/swift
that referenced
this pull request
Jul 10, 2018
Recent work to improve checking for forward references to local types (swiftlang#16967) started rejecting code that referred to a local type before it is defined. Swift previously accepted such code, because local types can’t capture anyway, so allow it again… for now. As a separate action item, I’d like to revisit the language design here, because it’s somewhat surprising when we can vs. cannot forward-reference local declarations, and the rules differ from those of top-level code in scripts *and* top-level code for non-scripts. Fixes rdar://problem/41659447
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 current implementation of type checker is overly strict for use_local_before_declaration cases.
When performing name lookup for UnresolvedDeclRefExpr, if a local declaration after use is detected, an error is raised immediately, without checking outer results where legal candidates may occur.
This PR adds relevant checking to see if we can find better matching candidates from outer results before raising a use_local_before_declaration error.
Resolves SR-7660.