1

Working through some of the last remaining stdlib/Interpreter test failures, I'm finding that one of the choices that is causing problems is the use of the ClangImporter to import headers in some interesting tests (like unions-and-bitfields).

The problem is that #import is a keyword that conflicts on Windows as it is traditionally used for TLB (type library) imports for (D)COM. However, clang will treat it as the normal #import as per ObjC if we change the language to Objective-C rather than C.

The approaches that I see to handle this is:

  1. always use objective-c as the language irrespective of the platform
  2. change the importer to use #include
  3. change the importer to switch between #include and #import based on whether ObjC interop is enabled

Personally, I think that option 2 is the nicest as it provides the most consistent behaviour, but, I can see it causing some problems with some of the tests.

CC: @jrose

2

(1) is dangerous on Linux, so I don't think we can do it right away. However, there is actually a semantic effect of #import that's relied upon in some cases (specifically, in unit test bridging headers that import an app's bridging header): the target header is only included once. We haven't really supporting bridging headers anywhere but Apple platforms, though, and we've also long wanted to kill the "implicitly import a bridging header to match what the debugger does" behavior (but haven't figured out how). So we might have to go with (3).