We can still get into circular import cases that result in us trying
to import the members of a category before we've finished with the
members of the original class. I need to fix that, but for now disable
the assertion to unblock some Apple-internal bots.
rdar://problem/31374687
Previously we were checking if a declaration was a redeclaration by
looking at the contextual type, but it should be looking at the
interface type in order to handle categories of classes using
Objective-C lightweight generics.
This also fixes a mistaken reuse of 'containerTy' after I changed its
meaning in the last commit. Doug's review comment was right: it /is/
bad to use an existing name for a new purpose!
More rdar://problem/30785976.
This ensures that any @property redeclarations that appear in class
extensions (a special kind of category in ObjC) do not affect the
primary type of the property as declared in the class itself.
To accomplish this, lookups in importDecl that are checking for
conflicts now no longer pull in new categories/extensions if the
current context is a ClassDecl.
rdar://problem/30785976
A more general solution to ae458a84ad: import all versions of a name
that are going to show up as members, ignore those that aren't.
Further work on <rdar://problem/29170671> Import APIs under their
Swift 3 names.
If a top-level declaration is imported as a member in Swift 4 but not
in Swift 3, it would still show up in the lookup table for the
containing type in Swift 3 mode. We would import it, and then try to
add the top-level declaration to the containing type.
I'm about to redo this anyway so that the versioned stub will show up
(the one for the Swift 4 name) but this is the narrow fix that avoids
the assertion failure we were seeing.
rdar://problem/31161489
If this had a default, it should be the effective language version,
not the compiler language version. That is, in the Swift 4 compiler's
Swift 3 mode, we want to be acting like Swift 3, not Swift 4.
New GenericTypeParamDecls should always be created with an
InvalidDepth, to prevent canonicalization before the generic
parameter list has been type checked.
The protocol conformance checker verifies that all of the requirements
in the protocol's requirement signature are fulfilled. Save the
conformances from that check into the NormalProtocolConformance,
because this is the record of how that concrete type satisfies the
protocol requirements.
Compute, deserialize, and verify this information, but don't use it
for anything just yet. We'll use this to eliminate the "inherited
protocol map" and possibility some redundant type-witness
information.
Previously some decls (TypeAliasDecl and ExtensionDecl) had bits
explicitly marking whether they've been validated, while other decls
just deduced this from hasInterfaceType. The doing the latter doesn't
work when the interface type can be computed before doing full
validation (such as protocols and associatedtypes, which have trivial
interface types), and so an explicit bit is adopted for all decls.
The compiler itself no longer uses this API but the debugger does,
in order to pretty-print option sets.
The normal way to test this would be to add an LLDB-side test that
uses a framework with versioned API notes. Unfortunately I can't
think of a straightforward way to test it Swift-side.
Unlike values, we can't import multiple copies of types under
different names and get good results. Instead, we make a typealias
that points back to the original type. Make sure this typealias is
flagged with whatever version is appropriate, rather than always using
"Swift 2".
When a C declaration is marked unavailable with a replacement, we look
for the replacement to see how it would be imported into Swift. Make
sure we do that with respect to the active language version.
This doesn't actually have any effect yet, but if we start importing
both Swift 3 and Swift 4 versions of protocol requirements and the
non-active one is unavailable, we might mistakenly mark the protocol
un-implementable even when the requirements that are needed are all
there. (Hopefully we would never make a protocol /less/ available in a
newer release, of course.) The test case is designed to catch that.
...and Swift 4 versions in Swift 3, and Swift 2 and "raw" versions in
both. This allows the compiler to produce sensible errors and fix-its
when someone uses the "wrong" name for an API. The diagnostics
certainly have room to improve, but at least the essentials are there.
Note that this commit only addresses /top-level/ decls, i.e. those
found by lookup into a module. We're still limited to producing all
members of a nominal type up front, so that'll require a slightly
different approach.
Part of rdar://problem/29170671
This allows a previously-working case of Objective-C forward-declaring
a type in a /different/ Swift module to continue working, as long as
the Swift context being compiled manages to import the other module
properly (including its generated header). This isn't really our
recommended pattern---that would be to @import the module in the
bridging header and forego the forward declaration---but it doesn't
cost much to keep it working. It's also a place where textual and
precompiled bridging headers behaved differently, because precompiled
ones are processed much earlier.
https://bugs.swift.org/browse/SR-3798
The list of directly inherited protocols of a ProtocolDecl is already
encoded in the requirement signature, as conformance constraints where
the subject is Self. Gather the list from there rather than separately
computing/storing the list of "inherited protocols".
Specifically, a forward-declaration of one struct inside another.
This isn't a field, so it doesn't affect whether or not the struct
has addressable storage, nor whether it should get a memberwise
initializer.
This change matches Swift 3.0 behavior. I'm not exactly sure why,
because as far as I can tell Swift 3.0 should have also been leaving
out the memberwise initializer. But it doesn't appear to have been
doing so, and including it is more correct anyway.
rdar://problem/30449400
Or rather, when the name importer decides that the name it /would/
have should start with a number, and gives up. We should probably
fix that separately, but meanwhile don't crash.
> Roses are red
> Prefix-stripping can create an invalid remainder
> assert(!member->NextDecl &&
> "Already added to a container")
rdar://problem/30401506
We can also avoid walking the members of said protocols in the
archetype builder and when looking for nested types, because of course
there are no associated types in imported Objective-C protocols.
Storing this separately is unnecessary since we already
serialize the enum element's interface type. Also, this
eliminates one of the few remaining cases where we serialize
archetypes during AST serialization.
The AST verifier is unhappy when an accessor's imported name gets
selector-split but its parameters don't have that recorded. Although
we're not using this for anything today, it seems best to keep the
two in sync.
rdar://problem/29889051
...and avoid making aliases from one unavailable declaration to another.
If it's unavailable, we can just import it as a normal case and not
worry about it. This fixes an issue where Sema would try to diagnose
the body of an "alias" for referring to unavailable declarations.
(Background: enum cases in Swift have to have unique values, so we
import any duplicate values as static properties. Pattern matching
logic has a hack to recognize these particular static properties as
being "case-like".)
This commit also sinks enum element uniqueness checking into importing
the enum, instead of keeping a global map we never consult again. This
should save a small bit of memory.
rdar://problem/30025723
integer constants, and to always look through macro definitions for them.
Also, logical comparisons now return a Boolean.
New operations: +, -, *, /, ^, >>, ==, >, >=, <, <=
Following a13c134521, constructors of structures/unions containing
anonymous structures/unions fields include those field in their parameter
list, using the generated field name as parameter name:
typedef struct foo_t {
union {
int a;
int b;
};
} foo_t;
Generates:
struct foo_t {
init(__Anonymous_field0: foo_t.__Unnamed_union__Anonymous_field0)
}
let foo = foo_t(__Anonymous_field0: .init(a: 1))
One important downside here is that the generated field name get exposed
in the API.
An idealistic approach would be to generate the constructors that expose
the fields indirectly inherited from those structures:
struct foo_t {
init(a: Int32)
init(b: Int32)
}
However, this approach requires the generation of a constructor per valid
combination of indirect fields, which might start having a huge
cardinality when we have nested anonymous structures in nested anonymous
unions...
typedef struct bar_t {
union {
struct {
int a;
int b;
};
struct {
int c;
int d;
};
};
union {
int e;
int f;
};
} bar_t;
In this examples, we have 4 constructors to generates, for (a, b, e), (a,
b, f), (c, d, e) and (c, d, f).
The proposed approach is to use a nameless parameter for anonymous
structures/unions, still forcing the user to build that sub-object by
hand, but without exposing the generated field name. This is very similar
to what can be done in C:
foo_t foo = { { .a = 1 } };
let foo = foo_t(.init(a: 1))
Or
bar_t bar = { { { .a = 1, .b = 2 } }, { .e = 1 } };
let bar = bar_t(.init(.init(a: 1, b: 2)), .init(e: 1))
Signed-off-by: Florent Bruneau <florent.bruneau@intersec.com>
