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.
- The DeclContext versions of these methods have equivalents
on the DeclContext class; use them instead.
- The GenericEnvironment versions of these methods are now
static methods on the GenericEnvironment class. Note that
these are not made redundant by the instance methods on
GenericEnvironment, since the static methods can also be
called with a null GenericEnvironment, in which case they
just assert that the type is fully concrete.
- Remove some unnecessary #includes of ArchetypeBuilder.h
and GenericEnvironment.h. Now changes to these files
result in a lot less recompilation.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
- TypeAliasDecl::getAliasType() is gone. Now, getDeclaredInterfaceType()
always returns the NameAliasType.
- NameAliasTypes now always desugar to the underlying type as an
interface type.
- The NameAliasType of a generic type alias no longer desugars to an
UnboundGenericType; call TypeAliasDecl::getUnboundGenericType() if you
want that.
- The "lazy mapTypeOutOfContext()" hack for deserialized TypeAliasDecls
is gone.
- The process of constructing a synthesized TypeAliasDecl is much simpler
now; instead of calling computeType(), setInterfaceType() and then
setting the recursive properties in the right order, just call
setUnderlyingType(), passing it either an interface type or a
contextual type.
In particular, many places weren't setting the recursive properties,
such as the ClangImporter and deserialization. This meant that queries
such as hasArchetype() or hasTypeParameter() would return incorrect
results on NameAliasTypes, which caused various subtle problems.
- Finally, add some more tests for generic typealiases, most of which
fail because they're still pretty broken.
So when sorting, don't just jump directly to the Clang decl and get
its name, because there might not be a Clang decl; instead, use the
'objc' attribute if there is one and the protocol's base name if
not. We're not using ProtocolType::compareProtocols because we'd
rather not depend on knowing for sure which Clang module a protocol
lives in.
This wasn't caught until now because it required adopting a protocol
in Objective-C that itself adopted (directly or indirectly) at least
two protocols, at least one of which originally came from Swift.
rdar://problem/26232085
Objective-C classes that originally came from Swift use swift_name to
map /back/ to Swift, and of course lookup to resolve the native
declaration needs to use this. However, we're /already/ using this due
to the name coming from the general name-importing logic. Once upon a
time looking for a native decl probably ran before general
name-importing, but that's no longer true, so we can just delete this
with no expected change in behavior.
Remove all occurrences of a "useSwift2Name" bool, and replace it with
version plumbing. This means that ImportDecl is now entirely
version-based, and the importer Impl knows versions. This will be
needed for marking Swift 3 names as deprecated, when there is a new
Swift 4 name.
NFC.
In the case of the nullability change, this snuck all the way past the
type checker to result in an assertion failure in SILGen; if
assertions were turned off, it continued all the way through IRGen
before the LLVM verifier caught it.
We get in this situation because ObjCPropertyDecls in Clang aren't
considered "redeclared" like most other entities. Instead, they're
just matched up by name in a few places. At first I considered trying
to handle such canonicalization post hoc in Swift's importer, but that
would have turned into plenty of work for something that rarely comes
up at all. Instead, this patch just drops the setter from such a
redeclared property if it doesn't match up.
Clang itself should diagnose these kinds of mismatches; that's been
filed as rdar://problem/29536751 for nullability and a similar
rdar://problem/29222912 for changing types in general.
rdar://problem/29422993
Change the interfaces to ImportedName to be method based, rather than
direct struct field accesses. We're going to be changing how these are
used in the future. Also, we will be storing large quantities of
these, so we will soon want to crunch down on their size.
