Skip to content

Fix nested types in closure context and non-static operator crash #9377

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

Merged
merged 5 commits into from
May 7, 2017

Conversation

slavapestov
Copy link
Contributor

@slavapestov slavapestov commented May 7, 2017

  • Fixes rdar://problem/31803589 and rdar://problem/31469036.
  • Fixes 8 compiler crashers.
  • Adds regression tests for rdar://problem/rdar30689883 and https://bugs.swift.org/browse/SR-2600 which are already fixed.
    rdar://problem/31104529

…tocol or extension that's nested in another type

When performing a name lookup from inside of a protocol
or extension, skip directly to the source file context
when we are done visiting the protocol or extension.

Otherwise, if we have invalid code where the protocol
or extension is nested inside another type, we might
find a member whose type contains generic parameters
of the outer type; these parameters will not resolve,
since we do not model protocols or extensions nested
inside generic contexts (yet?).

This supercedes an earlier workaround for a similar
issue; the new workaround fixes more crashes.

This is needed to avoid crasher regressions with an
upcoming patch.
We were not enforcing that operators were static if
the operator was defined in a final class, or if it
was defined in a non-final class but the operator was
itself final.

Fixes <rdar://problem/31469036>.
@slavapestov
Copy link
Contributor Author

@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.

1 participant