Skip to content

Remove The Last Vestiges of isInvalid from Parse Harder This Time #27862

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
Oct 26, 2019

Conversation

CodaFi
Copy link
Contributor

@CodaFi CodaFi commented Oct 24, 2019

Another go at #27820

Diagnose the fact that we're missing a colon, not the fact that we're missing a type since that's actually what has gone wrong.
@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 24, 2019

@swift-ci please smoke test

@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 24, 2019

And because I ain't about to make the same mistake twice

@swift-ci please test source compatibility

@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 24, 2019

OK, this fixes a crasher now. Will rebase once source compatibility gets back to me.

@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 24, 2019

Release compatibility failure isn't mine.

@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 24, 2019

@swift-ci please smoke test and merge

@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 24, 2019

@swift-ci please smoke test

Use the isInvalid() bit on the TypeRepr to signal that a closure
parameter is potentially a tuple destructure.  This has two benefits
1) Parse is no longer using the isInvalid() bit on Decl
2) Invalidating the type repr itself means that we no longer spuriously
diagnose variable patterns in destructures as missing types.
Even if we weren't invalidating the parameter's type, this would be
completing a type's members on a parameter label.
@CodaFi CodaFi force-pushed the valid-the-impalers-revenge branch from fe8ff4b to a772d76 Compare October 24, 2019 23:03
@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 24, 2019

@swift-ci please smoke test

@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 25, 2019

'Long as we're waiting on the bots to change

@swift-ci please test source compatibility

@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 25, 2019

@swift-ci please smoke test macOS platform

1 similar comment
@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 25, 2019

@swift-ci please smoke test macOS platform

@CodaFi
Copy link
Contributor Author

CodaFi commented Oct 26, 2019

⛵️

@CodaFi CodaFi merged commit bbed527 into swiftlang:master Oct 26, 2019
@CodaFi CodaFi deleted the valid-the-impalers-revenge branch October 26, 2019 00:38
CodaFi added a commit to CodaFi/swift that referenced this pull request Nov 11, 2019
When SE-110 was being implemented, we accidentally began to accept
closure parameter declarations that had no associated parameter names,
e.g.

foo { ([Int]) in /**/ }

This syntax has never been sanctioned by any version of Swift and should
be banned.  However, the change was made long enough ago and there are
enough clients relying on this, that we cannot accept the source break
at the moment.  For now, add a bit to ParamDecl that marks a parameter
as destructured, and back out setting the invalid bit on the type repr
for these kinds of declarations.

To prevent further spread of this syntax, stub in a warning that offers
to insert an anonymous parameter.

Resolves part of rdar://56673657 and improves QoI for errors like
rdar://56911630
CodaFi added a commit that referenced this pull request Nov 11, 2019
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