# ClangImporter including files

**URL:** <https://forums.swift.org/t/clangimporter-including-files/19119>\
**Category:** Compiler\
**Tags:** windows\
**Created:** [December 28, 2018, 7:55am UTC](https://forums.swift.org/t/clangimporter-including-files/19119 "2018-12-28T07:55:32Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\
**Post date:** [December 28, 2018, 7:55am UTC](https://forums.swift.org/t/clangimporter-including-files/19119/1 "2018-12-28T07:55:32Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [January 7, 2019, 7:42pm UTC](https://forums.swift.org/t/clangimporter-including-files/19119/2 "2019-01-07T19:42:47Z")

</div>

(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).