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
In order for Xcode to use these completions, we complete "?.member" when the
user has typed "anOptional.", but we also say that in order to apply this
result, N bytes to the left of the cursor should be erased first.
rdar://16579657 rdar://15233283
Swift SVN r16409
class A {
init(a: Int) {}
}
A(#^HERE^#
In its current state, this is a hack that I am not proud of. There is
potential here to provide such completions for all function calls:
class A {
func foo(a: Int) {}
func foo(a: Double) {}
}
A().foo(#^HERE^#
but this requires code completion doing its own name lookup, since the type
checker will give us an error type due to ambiguity of overloaded functions.
Type checker also sometimes gives up in cases like these:
struct A {
func foo() {}
}
A().foo
which is understandable, since we disallow partial applications of functions on
values, but returning the correct type here is useful for code completion.
rdar://16597372
Swift SVN r16367
Import a selector into a Swift method name, performing splitting at
that point. Use the resulting method name to determine the argument
names of the parameters, rather than trying to chop up the selector
again. There's more refactoring to do here.
This fixes a longstanding bug where the first argument of an
Objective-C method got the internal parameter name when it should
have gotten no name at all.
Swift SVN r15850
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
Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
Allow a form of 'case is T' that matches the cast result to a subpattern, 'case <pattern> as T'. This exposes an issue in switch destructuring with casting into complex class hierarchies <rdar://problem/16401831> but works for common cases.
Swift SVN r15396
Continue parsing operators after 'as <type>' or 'is <type>', which allows cast chains like 'x as Derived! as Base' or '1 as UInt8 + x' without parens, finishing <rdar://problem/15640006>.
Swift SVN r15357
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
Look for a postfix '!' after an 'as' production, and if we see it, carry it along in the CheckedCastExpr so we can wrap the cast in a ForceValueExpr once sequence folding resolves the LHS of the cast. Implements part of <rdar://problem/15640006>.
Swift SVN r15307
Resolve selector references using compound name lookup, pushing DeclNames a bit deeper through the type-checker and diagnostics as necessary.
Swift SVN r14791
Add __FUNCTION__ to the repertoire of magic source-location-identifying tokens. Inside a function, it gives the function name; inside a property accessor, it gives the property name; inside special members like 'init', 'subscript', and 'deinit', it gives the keyword name, and at top level, it gives the module name. As a bit of future-proofing, stringify the full DeclName, even though we only ever give declarations simple names currently.
Swift SVN r14710
Factor an IdentityExpr base class out of ParenExpr, and migrate most of the logic to see through ParenExprs to see through IdentityExprs instead. Add DotSelfExpr as a new subclass of IdentityExpr, produced by parsing 'x.self'.
Swift SVN r14381
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
attributes on the didSet/willSet declaration. This fixes:
<rdar://problem/16076758> Attributes on didSet/willSet + property initializer completely confuse the parser
Swift SVN r13936
outside of debugger-support mode. Rip out the existing special-case
code when parsing expr-identifier.
This means that the Lexer needs a LangOptions. Doug and I
talked about just adding that as a field of SourceMgr, but
decided that it was worth it to preserve the possibility of
parsing different dialects in different source files.
By design, the lexer doesn't tokenize fundamentally differently
in different language modes; it might decide something is invalid,
or it might (eventually) use a different token kind for the
same consumed text, but we don't want it deciding to consume more or
less of the stream per token.
Note that SIL mode does make that kind of difference, and that
arguably means that various APIs for tokenizing need to take a
"is SIL mode" flag, but we're getting away with it because we
just don't really care about fidelity of SIL source files.
rdar://14899000
Swift SVN r13896
Not sure this is really testable with the restrictions I've
put on it, but presumably the debugger's own test suite will
quickly grow a number of relevant tests.
rdar://14899000
Swift SVN r13880
Implement several rules that determine when an identifier on a new
line is a continuation of a selector-style call on a previous line:
- In certain contexts, such as parentheses or square brackets, it's
always a continuation because one does not split statements in
those contexts;
- Otherwise, compare the leading whitespace on the line containing
the nearest enclosing statement or declaration to the leading
whitespace for the line containing the identifier.
The leading whitespace for a line is currently defined as all space
and tab characters from the start of the line up to the first
non-space, non-tab character. Leading whitespace is compared via a
string comparison, which eliminates any dependency on the width of a
tab. One can run into a few amusing cases where adjacent lines that
look indented (under some specific tab width) aren't actually indented
according to this rule because there are different mixes of tabs and
spaces in the two lines. See the bottom of call-suffix-indent.swift
for an example.
I had to adjust two test cases that had lines with slightly different
indentation. The diagnostics here are awful; I've made no attempt at
improving them.
Swift SVN r13843
This can be used as, for example
self.init withRed(0.5) green(0.5) blue(0.5) alpha(1.0)
which mimics the declaration. THe same goes for super.
Note that this does not yet support
NSColor.init withRed(0.5) green(0.5) blue(0.5) alpha(1.0)
due to a limitation in the type checker.
Swift SVN r13825
This allows code such as
obj.closure { return 0 } onError { println("error") }
to parse appropriately. The only other functionality change here is
that we no longer allow the use of a trailing closure within the
condition of a C-style for loop, because it did awful things to
recovery. I doubt we'll miss it.
Swift SVN r13823
We don't want to parse the expr-call-suffix as a general
postfix-expression; rather, we only want it when we're directly naming
a method. This doesn't matter so much in the current model, but it
becomes important when we move over to the newer keyword argument model.
Swift SVN r13819
