This patch includes testsuite changes to show each of the decls supported.
Next step is to migrate the stdlib + testsuite + corelibs: I'd would *greatly* appreciate help with this.
After that is done, deprecation + migration of the old form can happen.
When declaring a nominal type:
struct Weak<T> {
weak var value: T
}
The diagnostic might mislead the developer to adding ': class' literally
to the 'T' in the generic parameters for `Weak`:
"'weak' may not be applied to non-class-bound protocol 'T'; consider
adding a class bound"
This is misleading in two ways: 1, 'T' isn't necessarily a protocol
(this patch generalizes that part of the message) and 2, you can't put
`: class` in the generic parameter list for `Weak`. In addition, the
stray class constraint causes diagnostic spew that also hides the issue.
Also provide a fix-it to constrain with 'AnyObject', which is probably
what the devloper means in this case.
rdar://problem/25481209
As part of this, use a different enum for parsed generic requirements.
NFC except that I noticed that ASTWalker wasn't visiting the second
type in a conformance constraint; fixing this seems to have no effect
beyond producing better IDE annotations.
Start parsing a "trailing" where clause for extension declarations, which follows the extended type name and (optional) inheritance clause. Such a where clause is only currently permitted for protocol extensions right now.
When used on a protocol extension, it allows one to create a more-constrained protocol extension, e.g.,
extension CollectionType where Self.Generator.Element : Equatable { ... }
which appears to be working, at least in the obvious cases I've tried.
More cleanup, tests, and penance for the previous commit's "--crash" introductions still to come.
Swift SVN r26689
Allows same-type constraints that map down to tuple types. This is a
minimal fix that allows the code in rdar://problem/18120419 to
type-check. However, the actual code in that radar triggers a SILGen
assertion (Archetype to be substituted must be valid in function), and
we're not recursively matching concrete types the way we should be, so
this is a baby step.
Among other things, this allows one to provide a same-type con
Swift SVN r24535
Here is how we parse SILFunctionType:
1> Printer will print the generic signature of SILFunctionType by splitting the
requirement lists by depth.
2> Parser will parse the printed generic signature as nested generic parameter
lists, and will construct generic signature from the generic parameter lists
by calling getAsCanonicalGenericSignature.
3> When parsing the substitution list of an ApplyInst, we assume the order of
the substitutions match the order of AllNestedArchetypes.
Parsing of back-to-back generic parameter lists is only enabled in SIL mode.
Another option is to parse generic signatures directly, but at SIL level, we
need to access Archetypes and they are currently built from generic parameter
lists. That means we have to reconstruct both generic signatures and generic
parameter lists.
rdar://17963350
Swift SVN r21421
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
Introduces a new kind of function type, GenericFunctionType, that
represents a polymorphic function type with all of its generic
parameters and requirements stored in a more readily canonicalizable
form. It is meant to eventually replace PolymorphicFunctionType, but
for now we build it up in parallel so we can switch over to it
pieacemeal.
Note: this representation is built and then thrown away. We'll start
recording it soon.
Swift SVN r8881
heuristic than skipUntilAnyOperator() to find the end of a type list
Almost all testcases added in this commit used to skip all the way to EOF.
Swift SVN r7991
Another baby step toward a proper canonical form for polymorphic
function types: generic parameters will eventually be uniquable by
their depth and index.
Swift SVN r7380
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
If the name of a func declaration ends in '<' and the following token is an identifier, the '<' has to be a generic angle bracket instead of part of the operator name. Fixes <rdar://problem/13782566>.
Swift SVN r5226
Per Chris's feedback and suggestions on the verbose fix-it API, convert
diagnostics over to using the builder pattern instead of Clang's streaming
pattern (<<) for fix-its and ranges. Ranges are included because
otherwise it's syntactically difficult to add a fix-it after a range.
New syntax:
diagnose(Loc, diag::warn_problem)
.highlight(E->getRange())
.fixItRemove(E->getLHS()->getRange())
.fixItInsert(E->getRHS()->getLoc(), "&")
.fixItReplace(E->getOp()->getRange(), "++");
These builder functions only exist on InFlightDiagnostic; while you can
still modify a plain Diagnostic, you have to do it with plain accessors
and a raw DiagnosticInfo::FixIt.
Swift SVN r4894
Fix-its are now working!
Feedback on the API is welcome. I mostly took what was in Clang as a model,
so the usual way to use a FixIt is to pipe it into an active diagnostic:
<< Diagnostic::FixIt::makeInsertion(Tok.getLoc(), "&")
<< Diagnostic::FixIt::makeDeletion(E->getRange())
<< Diagnostic::FixIt::makeReplacement(E->getRange(), "This")
(Yes, of course you can specify the first two in terms of makeReplacement,
but that's not as convenient or as communicative.)
I plan to extend the expected-* notation to include a notation for fix-its
before converting any other diagnostics over, but this is a start.
Swift SVN r4751
introduce the generic type parameters (which are simply type aliases
for a to-be-determined archetype type) into scope for name
lookup. We can now parse something like
func f<T, U : Range>(x : T, y : U) { }
but there is no semantic analysis or even basic safety checking (yet).
Swift SVN r2197
