`module.map` as a module map name has been discouraged since 2014, and
Clang will soon warn on its usage. This patch renames all instances of
`module.map` in the Swift tests to `module.modulemap` in preparation
for this change to Clang.
rdar://106123303
Lazy loading checked if the ClangDecl was hidden, but loading all
members did not. Let's make loadAllMembers() behave like the lazy
path, and fix some of the mock SDKs in the test suite.
These include memberwise initializers for pointer properties and enum
case constructors for pointer payloads. In both cases, the pointer is
being immediately escaped, so don't allow the user to pass a temporary
pointer value.
Turns out self-type-stripping /always/ operates on a type without
prefixes rather than /never/. Neither of these behaviors are really
what we'd want, but we'll live with it!
rdar://problem/56334797
This module was specified in the IDE and SILGen testing module maps,
which causes a failure. Remove the duplicated declaration in the
SILGen inputs and use IDE's definition.
When trying to figure out errors from an import failure, the nullability
completeness warnings would clutter the output making it difficult to
identify the errors. Sprinkle the declaarations with
`_Null_unspecified` to maintain the current nullability semantics and
silence the warnings. NFC.
When forming the Swift name lookup tables, import-as-member'd
declarations can precede the declaration of the context into which
they'll be imported as a member. In such cases, we already had logic
to delay the resolution until the end of the model (when the context
must be complete).
However, we would only delay when there is a swift_name attribute on
the declaration, which is... conceptually correct. If the swift_name
exists but is versioned (e.g., it is present only for Swift 4+), and
we're building before the swift_name took effect (e.g., in Swift 3
mode), the swift_name is buried under a "versioned" attribute in the
Clang AST. Therefore, we would end up dropping the declaration from
the name lookup table, which almost doesn't matter, except...
Serialization records the newest names for such declarations (e.g.,
Swift 4+ name in this case), so deserialization would fail to find the
declaration that had been dropped, causing a crash.
Eliminate the "optimization" that looks for the swift_name attribute
before delaying the resolution of such a declaration, so we'll visit
these later. Fixes rdar://problem/39115605.
This can come up when we use import-as-member to turn top-level functions
into methods in an @objc class. Previously dynamic lookup would find
these, causing a SILGen crash.
Fixes <rdar://problem/36492980>.
Use the modern spelling for the nullability attributes in the test mock
headers. Currently, this was relying on the predefined macros from
clang to work. However, those are only available on Darwin targets.
This is needed to make the mock environments more portable.
This is not really the right fix if we want to have physically
addressed lvalues support bridging in general, but doing so
requires adding a new LValue component type and doing a bunch
more refactoring, so just hack in a narrow fix for now since
it only seems to occur in one case.
Fixes <rdar://problem/34913892>.
Previously, we did not properly handle levels of indirection for
swift_newtype-ed typedefs of pointer types. We imported them in a way
that tried to present the value semantics of the pointee rather than
of the pointer. We then tried (sometimes incorrectly) to detect and
fix this up during SILGen.
Instead, model with the value semantics of the pointer itself. SILGen
can then be simplified to just pass swift_newtypes the same as any
other struct: directly for non-mutating and indirectly for mutating
(i.e. inout self). Tests added.
That is, the stubs we generate when you rename a C global function
imported as a type member using the SwiftName API note. (See the
test case changes.) Previously we hit an assertion.
For good measure, also fix versioned stubs for types-as-members,
which were always added to their original context rather than the
new context.
rdar://problem/31435658
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.
We could support this in the future but right now it's causing problems.
There's also a potential ambiguity issue here where a protocol and class
could have the same name.
In addition to updating the importer, remove the two entries from the
CryptoTokenKit API notes that were trying to use this feature.
rdar://problem/27990168
In the code that makes sure to pair up getters/setters only from the
same top level module, we were accidentally skipping the final
validity checks (e.g. do the number of parameters line up). This fixes
that.
Due to swift_name and swift_newtype, we are frequently importing onto
different contexts. This was confusing the fixit logic for unavailable
swift2 names, as we were trying to use Clang names when the Swift name
might be totally different (and even a nested type). This change has a
two-fold effect:
1) Globals who are imported onto swift_newtype-ed typedefs should be
considered ImportAsMember.
2) When printing out the name of an ImportAsMember Swift 3 decl, we
need to print out a fully qualified context, which also uses the
Swift names, not the Clang names.
Adds an unlabeled rawValue init for swift_newtype(struct), which
expresses the extensibility theme better. This makes the use and
creation of new instances of that type more succinct.
swift_newtype(enum) still requires the explicit label, as it is
non-extensible.
A swift_wrapper/swift_newtype'd type can wrap a bridged type. In such
cases, we need to report both the unbridged type (which is the
unbridged underlying type) and the bridged type (which is the
importer-created wrapper type). This fixes a problem where Objective-C
generic specializations would use the wrapper types on type parameters
with "AnyObject" constraints, which... doesn't work.
Fixes rdar://problem/26340353.
More generally, an unavailable initializer shouldn't stomp on an
available initializer, because it's possible that (for example) a
designated initializer will be unavailable but a factory initializer
will be available, so one still construct objects of that type.
Fixes rdar://problem/26238032.
Otherwise, the lookup table for "CGColor" has two entries, because of
this:
typedef struct CGColor *CGColorRef;
and that interferes with our ability to import things as members of
"CGColor" (as opposed to "CGColorRef"), which affects the fix-its we
generate when you try to use the non-member form.
This isn't necessarily the best long-term solution (as noted in the
FIXME) but it is expedient and won't break any current users.
More rdar://problem/26347297
Teach isClangTypeMoreIndirectThanSubstType about swift_newtype-ed
typedefs, which may be of CF foreign class type. In these cases, we
should reason about the underlying, wrapped type. Includes
refactoring of common logic and tests.
Sema was dutifully tracking conformances that were "used" as part of
type checking, so it could make sure that those conformances got
completed for SILGen to use. However, this information never actually
made it to SILGen, which included its own (more conservative, not
broad enough) heuristics for finding "used" conformances. Teach Sema
to record conformances within the appropriate source file, and have
SILGen reference the conformances when it emits SIL for the source
file.
Special case logic for CF types, which may be coming in as
unmanaged. In this case, we will use audit information if present to
import with the new type, otherwise we have to fall back to
Unmanaged<CF...>.
We still import global variables that must be unmanaged onto the new
type, though they keep their unmanaged types. This helps to
consolidate the definitions, as well as make future migration easier
if they get audited.
Test cases included.
We now specially import global decls who we identify as fitting the
notification pattern: extern NSStrings whose name ends in
"Notification". When we see them, we import them as a member of
NSNotificationName and, if NSNotificationName is swift_newtype-ed, we
use that new type.
Test cases included.
For swift_newtype structs that we create, we sometimes need to provide
a bridged type interface. In these cases, we use the original
non-bridged type as an underlying stored value, and create a computed
rawValue of bridged type. We similarly create an init() taking the
bridged type, and cast it appropriately to/from storage.
Tests updated.
This is a temporary solution that implements swift_newtype(enum) as
though it were written swift_newtype(struct). This is to work around
to the fact that a String-backed enum does not actually have a String
stored, and a struct is closer to reflecting that storage
properly. Struct provides most of the functionality and appearance for
now, though it does not allow for switching over the values.
Full support for swift_newtype(enum) as a Swift enum is forthcoming.
This introduces support for swift_newtype(struct) attribute (also
known as swift_wrapper). The Clang importer will create a brand new
struct corresponding to the annotated typedefs, which has a backing
raw value. Globals of that type are imported as static members on the
struct.
Additionally, this interacts seamlessly with prior import-as-member
work, meaning that the newly created type can be imported onto. Tests
included.
