Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
used on init decls, with the same semantics as "-> Self". Switch the ast
printer, and fixits to use it.
As driveby's, simplify verification of contextual keywords in declparsing,
and rename parseConstructor/Destructor to parseInit/Deinit.
Swift SVN r17356
Introduce a model where an argument name is a keyword argument if:
- It is an argument to an initializer, or
- It is an argument to a method after the first argument, or
- It is preceded by a back-tick (`), or
- Both a keyword argument name and an internal parameter name are
specified.
Provide diagnostics Fix-Its to clean up cases where the user is
probably confused, i.e.,
- "_ x: Int" -> "x: Int" where "x" would not have been a keyword
argument anyway
- "x x: Int" -> "`x: Int"
This covers the compiler side of <rdar://problem/16741975> and
<rdar://problem/16742001>.
Update the AST printer to print in this form, never printing just
a type for a parameter name because we're also going to adopt
<rdar://problem/16737312> and it was easier to move the tests once
rather than twice.
Standard library and test updates coming separately.
Swift SVN r17056
Part of <rdar://problem/16742001>. At the moment, this is just a
parsing thing, because argument names are still API by default
anyway.
Swift SVN r16991
This leaves in the existing syntax for @unchecked T?. That will
be addressed in later patches.
There's still a mysterious case where some of the SIL output
includes UncheckedOptional<T> and some places T!.
Moreover, this doesn't handle SourceKit's behavior for printing
for overrides. This just handles parsing the 'T!' syntax.
Swift SVN r16945
This restructures IfConfigDecl/Stmt to be a list of clauses controlled
by a condition. This makes it straight-forward to drop in #elseif support.
While I'm in here, this patch moves checking for extraneous stuff at the
end of the #if line from the lexer to the parser. This means that you can
now put a comment on the same line as a #if/#else/#elseif/#endif.
Swift SVN r16912
- Change the parser to unconditionally reject @mutating and @!mutating with a fixit and
specific diagnostic to rewrite them into the [non]mutating keyword.
- Update tests.
This resolves <rdar://problem/16735619> introduce nonmutating CS keyword and remove the attribute form of mutating all together
Swift SVN r16892
We had our transition path, and now it's time to kill it because it's
causing problems <rdar://problem/16672558>.
Amusing note: the SILGen test change is actually an improvement. We
weren't rebinding self when performing initializer delegation with the
separated call syntax.
Swift SVN r16707
Right now you can 'break' out of a labeled switch statement, but unlabeled
break retains its previous semantics of breaking out of the nearest loop.
Swift SVN r16616
improves location information to track the label location in the AST. We
don't currently track the location of the colon, but that would be trivial
to drop in if it is interesting.
Swift SVN r16608
The selector-style parameter parsing code is going away "soon", but we
still need to prop it up a bit longer. Hence, I don't feel too bad
about the Parser-level state I'm using in this hack to make it happen.
With that change, we can now establish two important invariants in the
AST:
- Only parameters (ParamDecl or GenericTypeParamDecl) can have their
DeclContexts changed. Everything else comes into being in the
correct context.
- All of the parameters in a function/constructor/closure/etc. are
described by ParamDecls, not just VarDecls.
Swift SVN r16593
This means we get ParamDecls rather than VarDecls. Additionally, we
parse both API names and parameter names, although the API names
aren't currently useful. As part of this, loosen up the tentative
parsing that disambiguates between a tuple and a closure
parameter-clause.
Swift SVN r16585
There is ambiguity in the grammar in the case of 'X as T', where
a '!' following the type 'T' indicates a forced cast. In this case
we do not parse the '!' as indicating @unchecked optional.
This patch also does not change the pretty-printing of @unchecked T?.
That can come in latter patches as it is clear where the sugared
version should be used.
In the REPL, we see:
(swift) let x : Int! = 42
// x : @unchecked Int?
Part of <rdar://problem/16579799>.
Swift SVN r16493
... and fix a few other bugs:
* always set the inherited protocols on the ProtocolDecl in the type checker,
so that we can remove a hack in ProtocolDecl::requiresClassSlow();
* diagnose DeclAttributes that are inverted when this is not allowed.
Swift SVN r15992
Parse the new function syntax, which allows both the argument (API)
and parameter (internal) name to be specified prior to the colon
within each parameter. Don't re-use the existing pattern-parsing
logic. Rather, implement a new (far simpler) parser for this purpose,
then map from its simple data structures to ArgParams and BodyParams
as we're used to.
There are a number of caveats here:
- We no longer have the ability to use patterns for parameters in
function declarations. The only place this really has an impact is
that it makes the ~> hack in the standard library even uglier.
- This exposed some issues with code completion with generic
parameters that need to be investigated.
- There's still some work to be done to improve recovery when things
parse poorly within a parameter list; there are some XFAILs to deal
with that.
I'll address the last two issues with follow-up commits.
Swift SVN r15967
We are removing this syntax. To stage the move, first error with
Fix-Its to rewrite to the keyword-argument syntax. In a week or so,
we'll remove all of the code supporting the "separated" call syntax.
Swift SVN r15833
We were never handling this correctly, and default arguments are checked along with the method body.
In some cases where no further validation was necessary (such as when the default argument was a literal value),
the compiler would let this slip through but in others this would cause a crash. (rdar://problem/16476405)
Swift SVN r15736
For example:
@class_protocol, @objc
is now just:
@class_protocol @objc
Once we removed attribute grouping in brackets this comma separation
became vestigial. Doug and I discussed this and thought this
was a good simplification in the grammar.
This change still remains to be done for type attributes.
Swift SVN r15540
This grammar change is motivated by consistency with richer
attributes we are going to add in the future, @availablity,
and seems a more scalable syntax amendable to parser recovery.
Conceptually, the values of the attribute look like a tuple of
arguments.
Swift SVN r15430
This representation is inspired by Clang's internal representation.
The current attribute representation, which is basically a union
of "stuff" in DeclAttributes, is not amendable to richer
attributes, such as @availability, that need to be implemented.
In Clang, attributes are modeled with actual objects that
encode both semantic and syntactic information (e.g., source ranges)
that facilitate richer checking, better diagnostics, and better tools.
This change is foundational for implementing @availability, but
also is a better long-term representation. As a migratory path,
it creates some duplications, with AttrKind and DeclAttrKind, the
two which should eventually become the same thing.
As part of this patch, there is some additional parser recovery
(for the new attribute representation) for duplicate attributes.
The parser now parses the entire duplicate attribute, which could
be quite complex, and then issues a diagnostic that the attribute
is a duplicate (and discarding it). This delayed diagnostic
also allows us to present ranges for the duplicate attribute, which
provides a better user experience.
Swift SVN r15365
we were previously lookahead parsing the argument list of a closure
literal as a tuple-type, when we should be doing so as a tuple-pattern.
This doesn't permit some pattern stuff, such as var/let on arguments.
Implement pattern parsing lookahead and use it.
Swift SVN r15350
Parse function declarations with the form
func murder inRoom(room: Int) weapon(Int) {}
where the function name ("murder") is separated from the parameter
names. This is the same style used in initializers, i.e.,
init withCString(cstr: CString) encoding(Encoding)
Swift SVN r15140
This means that we accept type attributes in a much broader
range of places where we previously required a <type>. <type>
was already a production that demanded a grammatically
unconstrained context because of all the possible continuations;
reducing the number of independent productions makes it easier
to choose one and thus not accidentally limit the range of
possible types parsed.
In particular, we want to be able to parse @unchecked T? pretty
much anywhere you can write a type.
Swift SVN r14912
Collect the identifiers for the selector pieces we parsed and use them to build a compound DeclName for the func decl. Currently this only manifests when __FUNCTION__ is used inside a selector-style function definition, where we now correctly produce the compound 'foo:bar:' name.
Swift SVN r14717
