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.
Until now, only indirect fields that didn't belong to a C union (somewhere
between the field declaration and the type in which it is indirectly
exposed) were imported in swift. This patch tries to provide an approach
that allows all those fields to be exposed in swift. However, the downside
is that we introduce new intermediate fields and types, some of the fields
may already have been manually defined in type extension (as seen with the
GLKit overlay).
The main idea here is that we can simply expose the anonymous
struct/unions from which the indirect types are taken and then use swift
computed properties to access the content of those anonymous
struct/unions. As a consequence, each time we encounter an anonymous
struct or union, we actually expose it at __Anonymous_field<id> (where id
is the index of the field in the structure). At this point, we use the
existing mechanism to expose the type as
__Unnamed_<struct|union>_<fieldname>. Then, each indirect field is exposed
as a computed property.
The C object:
typedef union foo_t {
struct {
int a;
int b;
};
int c;
} foo_t;
Is imported as
struct foo_t {
struct __Unnamed_struct___Anonymous_field1 {
var a : Int32
var b : Int32
}
var __Anonymous_field1 : foo_t.__Unnamed_struct___Anonymous_field1
var a : Int32 {
get {
return __Anonymous_field1.a
}
set(newValue) {
__Anonymous_field1.a = newValue
}
}
var b : Int32 {
get {
return __Anonymous_field1.b
}
set(newValue) {
__Anonymous_field1.b = newValue
}
}
var c : Int32
}
This has the advantage to work for both struct and union, even in case we
have several nested anonymous struct/unions. This does not require to know
the size and/or the offset of the fields in the structures and thus can be
properly implemented using front-end data.
Signed-off-by: Florent Bruneau <florent.bruneau@intersec.com>
Fixes SR-2757.
Variables in capture lists are treated as 'let' constants, which can
result in misleading, incorrect diagnostics. Mark them as such in order
to produce better diagnostics, by adding an extra parameter to the
VarDecl initializer.
Alternatively, these variables could be marked as implicit, but that
results in other diagnostic problems: capture list variables that are
never used produce warnings, but these warnings aren't normally emitted for
implicit variables. Other assertions in the compiler also misfire when
these variables are treated as implicit.
Another alternative would be to walk up the AST and determine whether
the `VarDecl`, but there doesn't appear to be a way to do so.
There's really not that much code shared between the accessor and
non-accessor cases in importMethodType, so split them up.
The one change here is that previously a method could /think/ it was
an accessor, but not be treated as one if the property decl has a
different getter or setter. Now such a method is just dropped by the
importer completely. It's intended that this is not a behavioral
change in that no real code should have such an AST.
This is building towards always having a consistent type for property
setters added in handlePropertyRedeclaration, which is
rdar://problem/29422993.
Once upon a time this was agnostic of the declaration being imported
(and possibly even still merged with importFunctionType) but that
hasn't been true for a while. If we're passing the ObjCMethodDecl
and ImportedName anyway, we don't need to separately pass the result
type, whether it's noreturn, and the Swift name as separate arguments.
No intended functionality change.
