[ClangImporter] Don't expect unmodularized structs to appear in 2 modules

[xymus]

The clang fix at swiftlang/llvm-project#3497 implements better decl merging, this affects how unmodularized types are imported. This fix triggers an old test explicitly supporting unmodularized code. We believe this test should be updated as the new behavior will prevent possible miscompilations.

We should add an expected error here once the clang fix lands, until them just makes sure the test works both with and without the clang fix.

[xymus]

Let's test with the clang fix first.

swiftlang/llvm-project#3497

@swift-ci Please smoke test

[xymus]

@swift-ci Please smoke test

[beccadax]

I'm having trouble reasoning about this change. What will the test eventually look like once we're relying on the clang change?

[xymus]

With the clang fix the test should be updated with the following for both importation order.

let viaStruct: Redeclaration.FooStruct1 = AppKit.FooStruct1() // expected-error {{module 'AppKit' has no member named 'FooStruct1'}}

The type FooStruct1 is defined in both modules in a unmodular fashion and clang will merge them. It's not ideal as it does break some clients relying on poorly modularized code but it prevents miscompiles that have been previously observed.

[beccadax]

I think it'd be better to leave the code unchanged and add a modified version of the error expectation:

expected-error * {{module 'AppKit' has no member named 'FooStruct1'}}

Along with a comment explaining that the "*" is transitional (and maybe referencing a relevant bug). That will accept either behavior for now.

[xymus]

That makes sense, thank you @beccadax for the suggestions. I've applied the changes, testing again.

swiftlang/llvm-project#3497
@swift-ci Please smoke test

[xymus]

The swift-corelibs-foundation failure on Linux is expected with the clang fix.

@swift-ci Please smoke test