Swift string literals are only permitted to contain well-formed UTF-8, but C does not share this restriction, and ClangImporter wasn't checking for that before it created `StringLiteralExpr`s for imported macros; this could cause crashes when importing a header. This commit makes us drop these macros instead.
Although invalid UTF-8 always *did* cause a segfault in my testing, I'm not convinced that there isn't a way to cause a miscompile with a bug like this. If we somehow did generate code that fed ill-formed UTF-8 to the builtin literal init for Swift.String, the resulting string could cause undefined behavior at runtime. So I have additionally added a defensive assertion to StringLiteralInst that any UTF-8 string represented in SIL is well-formed. Hopefully that will catch any non-crashing compiler bugs like this one.
Fixes rdar://67840900.
This patch introduces new diagnostics to the ClangImporter to help
explain why certain C, Objective-C or C++ declarations fail to import
into Swift. This patch includes new diagnostics for the following entities:
- C functions
- C struct fields
- Macros
- Objective-C properties
- Objective-C methods
In particular, notes are attached to indicate when any of the above
entities fail to import as a result of refering an incomplete (only
forward declared) type.
The new diangostics are hidden behind two new flags, -enable-experimental-clang-importer-diagnostics
and -enable-experimental-eager-clang-module-diagnostics. The first flag emits diagnostics lazily,
while the second eagerly imports all declarations visible from loaded Clang modules. The first
flag is intended for day to day swiftc use, the second for module linting or debugging the importer.
This addresses the follow up test case discussed in PR23651. Windows
will not promote a macro literal suffixed with `ll` or `i64` to an
unsigned long long even upon an overflow. This tests that the corner
case behaviour for importing a long long literal matches the platform
expectations.
Windows will keep the imported type as `signed long long` rather than
`unsigned long long` as per the Microsoft compiler behaviour. This
breaks the tests for this case. Unfortunately, this is one of those
areas which must differ.
The importer handles these by first trying to look up the type by name
using Clang's Sema, but that lookup can cause diagnostics to be
emitted (usually availability diagnostics). We could try to figure out
how to propagate that to the macro when we import it, but for now just
drop the macro instead if there are any diagnostics emitted when
looking up the type.
This will be a small source compatibility break if anyone was using a
macro defined in terms of a type that's deprecated or that has partial
availability; the macro will now silently not be imported instead of
producing an unsilenceable warning.
rdar://problem/36528212
Rather than being smart about this, just record an import failure when
we start importing a particular macro and update it at the end. Also
add a PrettyStackTrace to make this a little easier to track down in
the future.
The old logic for importing macros that just aliased other macros
managed to handle this in a clever way, but that was never tested for
the newer logic that evaluates expressions (fa834e2f80). Macro
importing in general probably deserves some cleanup, but meanwhile we
should make sure not to crash!
rdar://problem/34986930
integer constants, and to always look through macro definitions for them.
Also, logical comparisons now return a Boolean.
New operations: +, -, *, /, ^, >>, ==, >, >=, <, <=
These are too close to "true" and "false" for comfort; they add confusion and
mess up code completion. If the names appear in other contexts, though (such
as enumerator names), we should still bring them through.
<rdar://problem/17080279>
Swift SVN r18670
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
