Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
we used to say:
error: expected '{' for subscripting
we now say:
error: subscript in protocol must have explicit { get } or { get set } specifier
and produce a fixit to insert { get set }
This patch improves error recovery for malformed operator declarations,
previously we'd stop parsing the operator decl and try to parse the
body as an expression, hilarity (and a pile of horrible errors) would
ensue.
An invalid `case` construct would incorrectly return a successful status, causing `parseDecl` to crash later when it assumed there were valid decls in the `Entries` vector.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
Before this commit, for a var decl at top level, code completion engine assumes the code
completion token contained in this decl is the end point of the delayed parsing, i.e. the
second pass of code completion. This may lead to incomplete ASTs during the second pass, for
instance, when the code completion token lies at the second argument of a call expr that takes
three arguments. We fix the issue by allowing the first pass to pre-register the end location of
a top-level var decl since the first pass is a more error-tolerant and holistic parsing, and the second
pass to reuse this loc.
Swift SVN r32729
This TypeRepr should be used sparingly, where we have some fixed type
that cannot otherwise be expressed in the language. It's better than
faking up an IdentTypeRepr.
Swift SVN r32372
<rdar://problem/22856386> Changing a private stored property (in a
struct or class) or a private method (in a class) /should/ force other
files to recompile
Swift SVN r32239
This configuration clause will suppress lex diagnostics and skip parsing
altogether if the code under the clause isn't active - the compiler must
have a repository version greater than or equal to the version given to
_compiler_version.
This option is only meant to be used sparingly and not to track the
Swift *language* version.
Example, if using a compiler versioned 700.0.28:
#if _compiler_version("700.0.23")
print("This code will compile for versions 700.0.23 and later.")
#else
This + code + will + not + be + parsed
#endif
Included are new diagnostics for checking that the version is formatted
correctly and isn't empty.
New tests:
- Compiler version comparison unit tests
- Build configuration diagnostics
- Skipping parsing of code under inactive clauses
rdar://problem/22730282
Swift SVN r32195
After parsing a private decl, reset the token hash state to what it was
before the decl was parsed. This way, adding a private decl or editing
its type or name will not trigger a rebuild of downstream files.
<rdar://problem/22239821> Modifying private APIs shouldn't cause dependents to recompile
Swift SVN r31358
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
(Undoing revert r30961 of r30957, which just required lockstep commit to
SourceKit -- cwillmore)
Swift SVN r30962
This reverts r30957 because it broke the following tests on Jenkins:
SourceKit :: CodeComplete/complete_open.swift
SourceKit :: CodeComplete/complete_test.swift
<rdar://problem/22120345> swift-incremental-RA #8289 failed to build
Swift SVN r30961
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
Swift SVN r30957
More progress on rdar://problem/21578832. A property access off of a reference type may still require an lvalue base if it's a protocol extension implementation with a mutating setter. This gets us another step toward correct type-checking behavior, but the resulting AST still improperly loads the base reference, which leads to SILGen breakage.
Swift SVN r30837
Requiring a variadic parameter to come at the end of the parameter
list is an old restriction that makes no sense nowadays, and which we
had all thought we had already lifted. It made variadic parameters
unusable with trailing closures or defaulted arguments, and made our
new print() design unimplementable.
Remove this restriction, replacing it with a less onerous and slightly
less silly restriction that we not have more than one variadic
parameter in a given parameter clause. Fixes rdar://problem/20127197.
Swift SVN r30542
Compute the hash of all interface tokens when parsing; write the
interface hash to the swiftdeps file, or if the -dump-interface-hash
option is passed to the frontend. This hash will be used in incremental
mode to determine whether a file's interface has changed, and therefore
whether dependent files need to be rebuilt in response to the change.
Committed on ChrisW's behalf while he gets his setup unborked.
rdar://problem/15352929
Swift SVN r30477
This prevents us from seeing a less useful error message from SILGen
further down the line.
Also fix a bug where @objc without importing Foundation was not diagnosed
after the first top-level form. Some tests were relying on this behavior,
so fix those tests, either by splitting off the objc parts of the test, or
just by passing the -disable-objc-attr-requires-foundation-module flag.
Fixes <rdar://problem/20660270>.
Swift SVN r29359
initializer has been type-checked, rather than a bit for the entire
PatternBindingDecl.
<rdar://problem/21057425> Crash while compiling attached test-app.
Swift SVN r29049
And for "try return", "try throw", and "try let", get even more specific,
with a fix-it to suggest moving the "try" onto the expression.
rdar://problem/21043120
Swift SVN r28862
Allow availability attributes of the form:
@available(iOS 8.0, OSX 10.10, *)
func foo() { }
This form is intended for use by third-party developers when annotating their
own declarations and uses the same syntax as #available(). This annotation
says that on iOS foo() is available on version 8.0 and newer; on OSX it is
available on 10.10; and on any other un-mentioned platform it considered
available on the minimum deployment target and greater. Just like with
For now, we support this form during parsing by synthesizing multiple implicit
long-form @available attributes. So, for example, the above annotation will
synthesize two implicit attributes:
@available(iOS, introduced=8.0)
@available(OSX, introduced=10.10)
func foo() { }
Synthesizing attributes in this way is not ideal -- it makes for a poor Fix-It
experience, among other things -- but it exposes the short-form syntax with
minimal invasiveness.
rdar://problem/20938565
Swift SVN r28647
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Now that we don't have generic parameter lists at arbitrary positions
within the extended type of an extension declaration, simplify the
representation of the extended type down to a TypeLoc along with a
(compiler-synthesized) generic parameter list.
On the parsing side, just parse a type for the extended type, rather
than having a special grammar. We still reject anything that is not a
nominal type (of course), but it's simpler just to call it a type.
As a drive-by, fix the crasher when extending a type with module
qualification, rdar://problem/20900870.
Swift SVN r28469
We no longer allow extensions to provide generic parameters, and the
ability to parse the syntax
extension Array<String> { ... }
is causing confusion. Fixes rdar://problem/20873336.
Swift SVN r28468
Rather than swizzle the superclass of these bridging classes at +load time, have the compiler set their ObjC runtime base classes, using a "@_swift_native_objc_runtime_base" attribute that tells the compiler to use a different implicit base class from SwiftObject. This lets the runtime shed its last lingering +loads, and should overall be more robust, since it doesn't rely on static initialization order or deprecated ObjC runtime calls.
Swift SVN r28219
we parsed, otherwise the type checker gets confused later. This fixes these
regressions:
Swift :: compiler_crashers_fixed/0725-swift-type-walk.swift
Swift :: compiler_crashers_fixed/0742-swift-metatypetype-get.swift
Swift :: compiler_crashers_fixed/1501-swift-diagnosticengine-flushactivediagnostic.swift
Swift :: compiler_crashers_fixed/1705-vtable.swift
Also, that patch fixed 0791-swift-type-walk.swift, so mark it as not crashing.
Swift SVN r28108