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
This was part of the original weak design that
there was never any particular reason to rush the
implementation for. It's convenient to do this now
so that we can use it to implement Unmanaged<T> for
importing CF types.
Swift SVN r16693
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
This is meant to be utilized for a narrow set of scenarios specific to dogfooding our pre-1.0 compiler, so please do not take any dependencies on this. In fact, I'll be removing this in the next milestone. (See rdar://problem/16380797.)
Also included - improve error recovery when parsing broken build configuration clauses.
Swift SVN r15694
The @objc attribute can now be provided with a name (in parentheses),
which names the corresponding entity in Objective-C. The name will
either be a selector (for anything that maps down to an Objective-C
method) or a single identifier (for classes and protocols).
The extra information is not used for anything yet.
Swift SVN r15626
The parsing here for @availability isn't real yet; but it provides
scaffolding. Intended grammar:
@availability(*, unavailable, message="...")
@availability(*, unavailable)
@availability(ios, unavailable)
and so on.
Much of this doesn't work yet in a general way, but I wanted something
basic to work with to start with to wire up the functionality
for @availability end-to-end (at least for 'unavailable').
As part of this, extend DECL_ATTR to include whether or not an
attribute supports multiple declarations, and use this for
@availability.
Also hardwire darwin platforms, which we will need to have this
list come from somewhere. The checking could be done at parsing
or elsewhere.
Swift SVN r15491
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
Namely, nested structs, class, enum and other protocol declarations within protocols should raise a parse error, but not crash the type checker.
Also, protocol methods may not have bodies.
The fact that we weren't catching these issues resulted in a number of crasher bugs:
rdar://problem/15811382
rdar://problem/16290458
rdar://problem/16299208
rdar://problem/16316944
Swift SVN r15093
* replaced yet another variant of isWhitespace with the version from
clang/Basic/CharInfo.h. The major difference is that our variant used to
consider '\0' whitespace.
* made sure that we don't construct StringRefs that point after the end of the
buffer. If the buffer ends with "#", then MemoryBuffer will only guarantee
that there is one additional NUL character. memcmp(), OTOH, is allowed to
access the complete span of the provided memory. I colud not actually get
this to crash on OSX 10.10, but I do remember similar crashes we fixed in Clang.
* added checks to reject extra tokens at the end of the build configuration
directive -- see tests, that code used to compile without diagnostics. The
lexer tried to do this, but in a self-referential way -- by checking the
NextToken variable (which is actually the previous token, when viewed from
the point of lexImpl()). The checks I added are a little too strict, they
reject comments at the end of the directive, but at least we don't accept
strange constructs. Allowing comments would not be hard, just requires
factoring out lexer's routines to skip comments so that they accept a pointer
to the buffer and return the comment end point. Filed
<rdar://problem/16301704> Allow comments at the end of bulid configuration directives
for that.
Found by inspection... I was grepping the codebase for 'isWhitespace'.
Swift SVN r14959
This names the implicit argument "oldValue". Whether we keep implicit arguments or not
is a subject of debate, tracked by rdar://16268361.
Swift SVN r14819
Lex a backtick-enclosed `[:identifier_start:][:identifier_cont:]+` as an identifier, even if it's a Swift keyword. For now, require that the escaped name still be a valid identifier, keyword collisions notwithstanding. (We could in theory allow an arbitrary string, but we'd have to invent a mangling for non-identifier characters and do other tooling which doesn't seem productive.)
Swift SVN r14671
