I found this by inspection (also, I found that newer
clang versions also warns for this under -Wall). While here,
convert to static_cast<> for a more idiomatic C++.
This patch allows Parser to generate a refined token stream to satisfy tooling's need. For syntax coloring, token stream from lexer is insufficient because (1) we have contextual keywords like get and set; (2) we may allow keywords to be used as argument labels and names; and (3) we need to split tokens like "==<". In this patch, these refinements are directly fulfilled through parsing without additional heuristics. The refined token vector is optionally saved in SourceFile instance.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
...finally breaking the dependency of Parse on Sema.
There are still some unfortunate dependencies here -- Xi's working on
getting /AST/ not dependent on Sema -- but this is a step forward.
It is a little strange that parseIntoSourceFile is in ParseSIL, and
therefore that that's still a dependency for anyone trying to, well,
parse. However, nearly all clients that parse want to type-check as
well, and that requires Sema, Serialization, and the ClangImporter...
and Serialization and SIL currently require each other as well
(another circular dependency). So it's not actively causing us trouble
right now.
In today's Swift, only non-optional function parameters can be
non-escaping (and are by default). An optional function parameter uses
a function type as a generic argument to Optional, and like any other
generics that's considered an opaque and therefore possibly escaping
use of the type. This is certainly unfortunate since it means a
function parameter cannot be both Optional and non-escaping.
However, this "unfortunate" becomes a concrete problem when dealing
with Objective-C, which /does/ allow applying its 'noescape' attribute
to a callback block marked 'nullable'. This is fine for /uses/ of
methods with such parameters, but prevents anyone from /overriding/
these methods.
This patch pokes a very narrow hole into the override checking to
accomodate this: if a declaration comes from Objective-C, and it has
an optional, non-escaping closure parameter, it's okay to override it
in Swift with an optional, escaping closure parameter. This isn't
strictly safe because a caller could be relying on the
non-escaping-ness, but we don't have anything better for now. (This
behavior will probably be deprecated in the future.)
(Some people have noted that the old 'noescape' type attribute in
Swift still works, albeit with a warning. That's not something people
should have to type, though---we want to remove it from the language,
as described in SE-0103.)
rdar://problem/32903155
In anticipation of future attributes, and perhaps the ability to
declare lvalues with specifiers other than 'let' and 'var', expand
the "isLet" bit into a more general "specifier" field.
The previous logic accidentally propagated the "is parameter" flag
into any number of nested tuples. Fix this by differentiating between
"input of a function type" and "member of a tuple that's the input of
a function type".
Fixes SR-2757.
Variables in capture lists are treated as 'let' constants, which can
result in misleading, incorrect diagnostics. Mark them as such in order
to produce better diagnostics, by adding an extra parameter to the
VarDecl initializer.
Alternatively, these variables could be marked as implicit, but that
results in other diagnostic problems: capture list variables that are
never used produce warnings, but these warnings aren't normally emitted for
implicit variables. Other assertions in the compiler also misfire when
these variables are treated as implicit.
Another alternative would be to walk up the AST and determine whether
the `VarDecl`, but there doesn't appear to be a way to do so.
