Under -enable-infer-default-arguments, the Clang importer infers some
default arguments for imported declarations. Rather than jumping
through awful hoops to make sure that we create default argument
generators (which will likely imply eager type checking), simply
handle these cases as callee-side expansions.
This makes -enable-infer-default-arguments usable, fixing
rdar://problem/24049927.
Correct format:
```
//===--- Name of file - Description ----------------------------*- Lang -*-===//
```
Notes:
* Comment line should be exactly 80 chars.
* Padding: Pad with dashes after "Description" to reach 80 chars.
* "Name of file", "Description" and "Lang" are all optional.
* In case of missing "Lang": drop the "-*-" markers.
* In case of missing space: drop one, two or three dashes before "Name of file".
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.
Rather than plumbing a "has missing required members" flag all the way
through the LazyResolver's loadAllMembers and its implementations,
just eagerly update the "has missing required members" flag in the
Clang importer when it happens. More NFC cleanup.
Objective-C instance methods of root classes can also be used as class
methods, which we handle by performing a redundant import, the code
for which was scattered. Centralize this import as part of importing
the original (instance) method, and record it as an alternate
declaration to the original instance method. This eliminates a number
of special cases in the Clang importer.
Various interface-printing facilities use getTopLevelDecls to
enumerate the top-level declarations of a given module. For modules
imported from Clang, this walked a giant cached list of all
declarations known from Clang, then filtered out those that didn't
fit. Instead, just use the information provided by the Swift name
lookup tables, which is inherently module-specific and complete.
In C, macros can be redefined so long as the redefinitions are
tokenwise equivalent. Provide the Clang importer with the same ability by
determining when tokenwise equivalent macros would be imported as
different Swift declarations, and collapse them into a single
declaration.
When we're omitting needless words and building Swift name lookup
tables, make sure to use the proper Clang
Sema/Preprocessor/ASTContext. This still needs to be properly
detangled, but at least now we can handle omit-needless-words for
builtin Clang types (e.g., SEL) properly.
As part of this, put OmitNeedlessWords and InferDefaultArguments into
the module file extension hash for the Swift name lookup tables, since
those settings will affect the results.
There are some Clang declarations that end up being imported as
multiple declarations in Swift, e.g., CF types get imported both with
and without the "Ref" suffix, subscript getters get imported both as a
method and as a subscript, etc. Track this explicitly so it's easy to
query the alternate declaration of a given declaration for name
lookup.
In many of these cases, the alternate declarations should simply go
away, because they're bloating the API. But that's a Swift 3 change
that requires review. For now, we want parity between the behavior
without and with Swift name lookup tables.
Omitting needless words while importing the full name function
involves inference of default arguments, so we can get here while
building Swift name lookup tables. It takes a lot of machinery to
trigger this problem; tests forthcoming.
There *must* be a better way to ensure this never happens, but it
requires a bit more refactoring in the Clang importer.
We decided not to support "implicit" properties, where we import
getter/setter pairs as properties. Rather, we only import a property
when there is an explicit "@property" in Objective-C. Remove the flag
and supporting code for implicit properties.
The recently-introduced module file extensions functionality in Clang
allows us to piggy-back the Swift name lookup tables in Clang's module
files. When the Swift name lookup tables are enabled, introduce such a
module file extension, and wire it into the SwiftLookupTable.
The actual contents of the extension block are simple: a single
on-disk hash table mapping base names to "full entries", which store
the context (e.g., a class, protocol, tag, or TU) and the set of
declarations.
Allow lazy resolution of declaration IDs deserialized from the
extension block to Clang declarations, to try to minimize the set of
declarations we must deserialize. Name lookup itself is only used to
dump the Swift name lookup tables and ensure we're round-tripping
properly.
Ensures that the Swift lookup tables get transformed name for imported
CF types, including original name (which is still
available). Otherwise, this is an NFC refactoring that gets the last
of the naming tricks into importFullName.
The translation from the Objective-C NSError** convention into Swift
throwing methods alters the names of methods. Move that computation
into importFullName. This should be NFC refactoring for everything
except the Swift name lookup tables, which will now correctly reflect
this name translation.
Centralize the mapping of C names to Swift names further by including
enumerator prefix stripping, rather than having that as a separate
path. The actual logic and code for computing the prefix is unchanged
(despite moving from one file to another). This corrects the name
computed for the Swift lookup tables, but is an NFC refactoring for
everything else.
With this, kill off importName(), because it's been entirely
superseded by importFullName().
This places enumerators that will become either cases of a Swift enum
or options in a Swift option into the context of the C enum type for
the name lookup table.
This is needed for member lookup via the Swift lookup tables, although
the lookup part is not yet implemented. Note also that the results are
currently wrong for C enumerations mapped into Swift enums or option
sets. That will come shortly.
The sole remaining caller to importName is for enumerators, which may
have prefixes that need stripping. That refactor will come in a
subsequent commit.
The Swift lookup tables are the primary client and test vehicle right
now. This change adds the capability to use the swift_name attribute
to rename C functions when they are imported into Swift, as well as
handling the swift_private attribute more uniformly.
There are a few obvious places where I've applied this API to
eliminate redundancy. Expect it to broaden as the API fills out more.
When we parse a bridging header, start building a mapping from Swift
names (both base names and full names) to the Clang declarations that
have those names in particular Clang contexts. For now, just provide
the ability to build the table (barely) and dump it out; we'll grow
it's contents in time.
This is functional for arbitrary Objective-C properties and methods
(the subject of rdar://problem/22214302), as well as for changing the
argument labels of C functions. However, it does not work when the
name of a global is changed because name lookup initiated from
Swift goes through the Swift lookup table. Fixes
rdar://problem/22214302 but is only a step toward
rdar://problem/17184411.
Swift SVN r32670
Instead, when mapping a Clang type to its name for omission purposes,
map CF types to their appropriate names. This more directly mirrors
what will happen on the Swift side, but is otherwise NFC.
Swift SVN r32140
