importer::findOptionSetEnum() uses some fragile heuristics to determine
whether a typedef is involved in the construction of a CF_OPTIONS or
NS_OPTIONS type. This patch adds an explicit check that the typedef is
expanded from either of those macros, to prevent, e.g., an unavailable
NS_ENUM, from being mistakenly recognized as an NS_OPTIONS.
Note that doing this is still kind of fragile, and prevents users from
building {NS,CF}_OPTIONS with their own macros. The right thing to do is
probably specifically look for the flag_enum attribute, but that is not
currently what we're doing for reasons whose discovery is left as
an exercise to the future git archaeologist.
This patch also removes (part of) a test case that builds
a CF_OPTIONS-like type with the "SOME_OPTIONS" macro, which is no longer
supported as of this patch.
rdar://150399978
The NS_OPTIONS macro sometimes uses a pattern where it loosely
associates a typedef with an anonymous enum via a shared underlying
integer type (emphasis on "loosely"). The typedef is marked as
unavailable in Swift so as to not cause name ambiguity when we associate
the anonymous enum with said typedef. We use unavailability as
a heuristic during the import process, but that conflates NS_OPTIONS
with NS_ENUMs that can be marked as unavailable for entirely unrelated
reasons.
That in and of itself is fine, because the import logic is general
enough to handle both cases, but we have an assertion that seems to be
unaware of this scenario, and trips on unavailable NS_ENUMs. (In those
cases, the typedef points to the enum rather than the underlying integer
type.) This patch fixes the assertion to be resilient against such cases
by looking through the enum a typedef refers to.
rdar://150399978
It's at home there alongside other ObjC enum-specific logic, rather than
in the middle of ImportDecl.cpp (since it isn't directly or exclusively
related to importing decls).
Also renames it to findOptionSetEnum() to make it a bit clearer at face
value that the returned ImportedType will contain a Swift enum.
Also refactors some nearby instances of
if (auto e = dyn_cast<ElaboratedType>(t))
t = e->desugar();
into a helper function, desugarIfElaborated().
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Clang recently started wrapping more types in `clang::ElaboratedType` after this change: https://reviews.llvm.org/D112374
This broke some assumptions in ClangImporter, specifically in enum handling logic. This change adjusts those.
Fixes these tests in rebranch:
* `Interop/Cxx/enum/anonymous-with-swift-name-module-interface.swift`
* `Interop/Cxx/enum/anonymous-with-swift-name-objc-module-interface.swift`
* `Interop/Cxx/enum/anonymous-with-swift-name.swift`
* `Interop/Cxx/enum/c-enums-NS_OPTIONS-NS_REFINED_FOR_SWIFT.swift`
* `Interop/Cxx/enum/c-enums-NS_OPTIONS.swift`
* `Interop/Cxx/enum/c-enums-withOptions-omit.swift`
* `Interop/Cxx/class/inheritance/fields-module-interface.swift`
* `Interop/Cxx/class/inheritance/fields.swift`
* `Interop/Cxx/class/inheritance/functions-module-interface.swift`
* `Interop/Cxx/class/inheritance/sub-types-module-interface.swift`
* `Interop/Cxx/class/inheritance/type-aliases-module-interface.swift`
Simply treat scoped enums as (pre-existing) "non frozen enums". C++
scoped enums are actually imported as Swift enums (unlike other enums)
and no global variables need be created (given their "scoped" nature).
The getLocStart API is deprecated and slated for removal from LLVM
very soon. Switch to use getBeginLoc instead. I did not see any uses
of the corresponding getLocEnd API.
LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
Since NS_ENUM has an enum_extensibility(open) in it already, we want
to allow people to undo that by sticking enum_extensibility(closed) on
the end of their enum.
Still to do: test and fix up the use of multiple enum_extensibility
annotations, possibly with API notes. This is important because the
definition of NS/CF_ENUM /includes/ enum_extensibility(open) as of
Xcode 9.0; there should be a convenient out people can use to declare
exhaustive enums in C that's backwards-compatible.
They're all kept alive by Clang's ASTContext already. Since the enum
info is only accessible through the Clang importer, that's a
sufficient lifetime. (Note that this only works because all of the
strings are derived from text actually present in the C sources:
either attribute arguments or names of declarations.)
Fixes a small TODO and probably saves a tiny bit of memory usage.
*** Depends on Clang change "[APINotes] Record what version caused ***
*** an annotation to get replaced." Update your Clang checkout! ***
More generally, change the meaning of the SwiftVersions section in API
notes to be "this version or earlier" rather than "exactly this
version". We mostly get this behavior for free from the Clang-side
changes, but for SwiftName and the enum annotations we look at inactive
attributes as well. The latter is simple, but the former means being
careful about finding the annotation we /would/ have picked, i.e. the
one closest to the version we requested.
This would fail later down the line anyway, meaning this does not
change the ultimate behavior of the importer, but since I added an
assertion that we're expecting a definition here in 2c68f8d49d, we
need to avoid even asking the question.
Also fix up a few other places where we aren't sure we'll have a
definition when calling these functions.
rdar://problem/33784466
(and similar for flag_enum)
This commit prepares the importer for a world in which NS_ENUM and
NS_OPTIONS have adopted the new Clang attributes 'enum_extensibility'
and 'flag_enum', but API notes are used to reverse the effect. Without
this there would be no transition path for adopting the standard Cocoa
macros, which have applied unconditionally up to now.
rdar://problem/18744821
These new Clang attributes identify whether an enum is intended to
represent an option set or not, and whether the set of cases listed in
the enum declaration is exhaustive. (Swift doesn't currently have a
closed/open distinction for enums, so treat any C enum with
enum_extensibility as a proper closed Swift enum, like we do with
NS_ENUM.)
Enums with neither attribute will continue to be imported as unique
types.
rdar://problem/28476618
Now that we have a EnumInfoCache per NameImporter which is per Clang
instance, we can just cache our EnumInfo based off of Clang decl,
rather than using a faux-USR technique. This greatly speeds up and
simplifies enum imports.
EnumInfos are requested about 200k times when building the module
cache for Foundation, and thousands of times for simple tests during
normal import, so efficiency here is important. While building module
caches, the EnumInfoCache is hit 99% of the time, and it is hit 98% of
the time during normal import with pre-built module caches.
NFC.
Introduces new files ClangAdapter.h/cpp, which will serve as a
convenient place to put code reasoning about Clang details. Refactors
out most Clang-related is*, has*, and get* methods from the
ImporterImpl. In the future, an adapter class could help serve to
seperate the concerns of the importer from the details of how to
correctly use Clang APIs.
Pull off the caching code from the Impl and onto a new EnumInfoCache
class, that will be useful as we decouple import naming from the Impl
class state.
The Clang attribute allows one to state that a particular enumeration
type describes an error, and associates it with a particular domain
constant. However, due to lack of API notes support, this attribute
wasn't actually getting used. Instead, we had a number of explicit
extensions to enum types to make them conform to the _BridgedNSError
protocol explicitly.
Now that we have API notes, use them to make these enums into error
enums with the appropriate domain, so that the Clang importer will
synthesize the _BridgedNSError conformances. Then, remove all of the
explicit conformances---and with them, the overlays for 12 frameworks.
There is a small fix to more eagerly consider these conformances as
"used" if an expression is formed with the error enum as a value
type. This better ensures that the conformances will be available at
runtime when needed.
This cleanup is needed to implement SE-0112 (NSError bridging),
although it is useful by itself.
Rather than do whole-word common-word stripping, we only strip common
prefixes. This is not as powerful as what was originally intended, but
much less magical in the mapping into Swift.
Test case adjusted, and common utility functions exposed.
This is more of rdar://problem/24869070; StringRefs are leaking out of
importFullName still, in a DenseMap that can get deallocated. When we
cache this data, put them in "permanent" (Swift ASTContext) storage.
ns_error_domain can now be used to communicate with the ClangImporter
when an enum has an associated error domain string. In this case, when
we import it as a Swift enum, we can also synthesize a conformance to
_BridgedNSError.
This allows the creation of something like NS_ERROR_ENUM, in which the
developer can declare an enum for the purposes of error handling. Adds
Sema and executable tests demonstrating this funcionality.
In order for the imported ns_error_domain bridging to work, we have to
at some point forcibly pull in a _BridgedNSError conformance, as one
will not be pulled in normally. This is a problem, and is explicitly
signaled in the provided test case
Introduces new class, EnumInfo, just for the implementation of the
ClangImporter to encapsulate various computed information about the
enum we're importing.
This helps refactor some functionality, aids clarity, and also
prevents us from repeating calculations multiple times, as we were
doing with classifyEnum's macro-expansion tracking. Provides a base
where we can add more heavy lifting in classifyEnum in the future.
