Refactors out some definitions and types from the
ClangImporter::Implementation into a new component ImportName. Future
work will include more separation and finally some redesigning of name
determination components.
This patch fixes an importer problem which occurred for macros defined
in terms of two other macros which might not have been imported before.
For example, the macro CPU_TYPE_X86_64 (defined as CPU_TYPE_X86 |
CPU_ARCH_ABI64) in Foundation wasn't imported although the importing
logic was implemented.
importMacro is now called for each of the constituents before checking
the constant value.
Fix an assertion which is triggered when the operands of a bitwise operator have different signedness.
This is done by promoting the operands to the largest bit width (taking sign/zero extension into account) and ignoring the signedness for the operation itself.
Addresses SR-1509 by adding a heuristic to import numeric literals with a
type cast. Two new cases have been added for macros with 4 or 5 tokens
to cover cases with or without sign tokens.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
In C, macros can be redefined so long as the redefinitions are
tokenwise equivalent. Provide the Clang importer with the same ability by
determining when tokenwise equivalent macros would be imported as
different Swift declarations, and collapse them into a single
declaration.
These are contexts where we have enough information to bridge /back/
properly; that is, where we can distinguish CBool, ObjCBool, and
DarwinBoolean. In cases where we can't, we keep the three separate;
only CBool is really the same type as Bool.
This also affects current import behavior for ObjCBool, which was previously
incorrectly conflated with CBool in certain cases.
More rdar://problem/19013551
Swift SVN r30051
...and add one extra check for invalid macro info.
This reinstates the tests that were disabled in my previous commit, now that the
Clang issue has been fixed.
Finishes rdar://problem/21480635.
Patch by Jordan Rose.
Swift SVN r29705
- Macros that aren't visible won't have macro info.
- Making a module visible to Sema doesn't make it visible to the Preprocessor.
Part of rdar://problem/21480635
Patch by Jordan Rose.
Swift SVN r29703
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
instead of importing them as _Nil (which will be going away when nil becomes an expr).
You now get an error saying:
error: 'NULL' is unavailable: use 'nil' instead of this imported macro
This is pretty cool all around, except for the GCD macros that need to be fixed, I'll
handle that as a follow-up.
Swift SVN r18747
This improves the -import-objc-header option to read decls from the header
as well. Any declaration that is not from a module will be considered to be
part of the "header module". Conversely, forward-declarations appearing in
the header will be resolved by looking through all modules responsible for
importing a header.
More of <rdar://problem/16702101>
Swift SVN r17492
Also, look through one layer of parentheses in general for macros, rather
than special-casing it for each token count.
<rdar://problem/16198517>
Swift SVN r17460
and only later adjust the type for the manner in which
it is actually being used.
This gives us a foundation on which to build a consistent
and defensible model for importing typedefs.
Also fix a subtle problem with typedefs imported from
multiple clang modules.
Swift SVN r17079
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
Apply the same prefix-chopping logic as for NS_ENUM to produce static property names to put inside the Swift type we create. For now, continue importing NS_OPTIONS as structs with a single integer field; in the short term it's easy to put a C-like interface over them this way.
Swift SVN r10434
That is, 1234 is a CInt, 1234U is a CUnsignedInt, and 1234LL is a CLongLong.
Oh, and 3.14F is a CFloat.
One caveat here is that it is not actually possible in C to write a literal
INT_MIN:
-0x80000000 is two tokens and the literal part is unsigned
(-INT_MAX - 1) is several tokens
I've simply dropped this test for now, but it might be confusing in the rare
case where an INT_MIN-like value is used as a sentinel.
<rdar://problem/13839025>
Swift SVN r7639
This makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
The importer has always imported types differently in different
places, e.g., function parameter types have special rules for C++
references. Formalize this notion a bit, and make it work properly
when dealing with typedefs where the underlying type itself might be
imported differently in different contexts.
As part of this, limit the import of C's 'void' type to the result of
a function type.
Swift SVN r5055
