| // RUN: not %target-swift-frontend -F %S/Inputs/defer-supermodule-import -enable-objc-interop -import-objc-header %S/Inputs/defer-supermodule-import/Some-Bridging-Header.h -typecheck %s 2>&1 | %FileCheck -check-prefix=HEADER-ERROR %s |
| // HEADER-ERROR: Some-Bridging-Header.h:4:13: error: expected a type |
| // HEADER-ERROR: Some-Bridging-Header.h:7:10: error: declaration of 'TYPE' must be imported from module 'Some' before it is required |
| |
| // The bug we're testing here is that: |
| // |
| // - Given a supermodule defining some types |
| // - Given a submodule of that supermodule |
| // - Given an _erroneous_ bridging header that imports the _submodule_ and tries |
| // to use the _supermodule's_ types |
| // |
| // That we emit an error. Previously we did not: Swift's "implicit supermodule |
| // import" rule would fire _eagerly_, so by the time the submodule import was |
| // complete the supermodule was also imported and the bridging header would pass |
| // through without flagging the error. This made it possible to write textual |
| // bridging headers that would not, themselves, be considered valid objc code as |
| // far as clang (or more importantly: clang's PCH-generating pass) was |
| // concerned. |
| |
| print(bar(foo())) |
