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>
When importing a property as accessor methods (rather than as a
property), we were still importing the type of the accessor methods as
if they were Swift getters and setters of a property, which
(necessarily) homogenizes the types. The homogenization is unnecessary
when importing as accessor methods, because the methods are
independent, so just import the accessor method types as if the
property did not exist. This is particularly useful for maintaining
Swift 3 source compatibility for cases where Swift 4 turns a
getter/setter pair into a null_resettable property.
Fixes rdar://problem/30075571.
Following PR #6531 there is a position mismatch in the final loop between
the position of the member in the members arrays and the position in the
valueParameters array.
As a consequence, a structure containing indirect fields before a computed
properties (like a bitfield) caused an invalid access in the
valueParameters array resulting in a crash of the compiler.
This patch maintains a separate position for accessing valueParameters. A
non-regression test is also added.
Signed-off-by: Florent Bruneau <florent.bruneau@intersec.com>
Instead of creating an archetype builder with a module---which was
only used for protocol conformance lookups of concrete types
anyway---create it with a LookupConformanceFn. This is NFC for now,
but moves us closer to making archetype builders more canonicalizable
and reusable.
Resolves https://bugs.swift.org/browse/SR-2394.
The 'returns_twice' attribute is used to denote a function that may return more
than one time. Examples include `vfork` and `setjmp`. The Swift
compiler, however, cannot ensure definitive initialization when
functions such as these are used.
Mark 'returns_twice' functions as unavailable in Swift.
In turn, this removes the need to explicitly mark `vfork` as unavailable on
Darwin platforms, since it is now unavailable everywhere.
For code that relies upon `vfork`, `setjmp`, or other 'returns_twice'
functions, this is a backwards-incompatible, source-breaking change.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
