Bug: Off-by-one Index Build can cause issues with Xcode background indexstore generation

[BalestraPatrick]

Describe the bug

When editing code in a test target, the following error is displayed in the code editor:

Malformed compiled module: /Users/me/Library/Developer/Xcode/DerivedData/ProjectName-gycnzekyazbslbeaqlxvvzaelfei/Index/Build/Products/bazel-out/ios-sim_arm64-min13.0-applebin_ios-ios_sim_arm64-dbg-ST-8e7a2d80b97f/bin/directory/ModuleName.swiftmodule/arm64-apple-ios-simulator.swiftmodule

Reproduction steps

I tried to reproduce this in a sample project but couldn't. I digged a bit and found the following information in the indexing logs.

The swiftmodule referenced in the error is an empty one, which is created by rules_xcodeproj on purpose to satisfy Xcode. I don't think it should be picked by any build though, so there's a flag that is likely misconfigured. In the invocation for the file that is displaying the error, I see the following flags that could cause the compiler to pick up the path to the malformed module:

-I /Users/me/Library/Developer/Xcode/DerivedData/ProjectName-gycnzekyazbslbeaqlxvvzaelfei/Index/Build/Products/bazel-out/ios-sim_arm64-min13.0-applebin_ios-ios_sim_arm64-dbg-ST-8e7a2d80b97f/bin/directory
-F /Users/me/Library/Developer/Xcode/DerivedData/ProjectName-gycnzekyazbslbeaqlxvvzaelfei/Index/Build/Products/bazel-out/ios-sim_arm64-min13.0-applebin_ios-ios_sim_arm64-dbg-ST-8e7a2d80b97f/bin/directory
-Xcc -I/Users/me/Library/Developer/Xcode/DerivedData/ProjectName-gycnzekyazbslbeaqlxvvzaelfei/Index/Build/Products/bazel-out/ios-sim_arm64-min13.0-applebin_ios-ios_sim_arm64-dbg-ST-8e7a2d80b97f/bin/directory/include

I noticed that after some time (couple of minutes), the error goes away automatically. The invocations are exactly the same in both cases, so something is changing on disk which fixes the issue?

Expected behavior

Indexing builds should work as expected and no indexing errors should appear in the code editor.

Versions

• Bazel:5.3.0
• rules_xcodeproj: 62f31d5c84f7e2927db5239942d3c6738d6aed88
• rules_apple: c27224cbe4988718dd0694c34d9366acc34ac8dd
• rules_swift: cec0b742fead1e183e8b2b04a8d1c63b0f0f8048

[brentleyjones]

Is the module in question a sibling module to the test target? That was one of the things supposedly fixed by this overlay, as it's supposed to map /Users/me/Library/Developer/Xcode/DerivedData/ProjectName-gycnzekyazbslbeaqlxvvzaelfei/Index/Build/Products/bazel-out/ to the actual bazel-out/. We need that because:

1. SwiftUI Previews need to find "themselves"
2. Blank sibling modules were accidentally getting picked up by that include

[brentleyjones]

Got a lead offline. Believe that the overlay only starts to work once the main project is built, since the full directory doesn't exist and the fallback behavior kicks in.

[brentleyjones]

I'm not sure I can fix this for BwB, though BwBvP might be able to:

• The compiler is still looking in $BUILD_DIR, even though we remapped it, because the output directory doesn't exist in bazel-out/
• So why is it compiling something that doesn't have its outputs yet? That's because of the off-by-one nature of Index Build currently. We don't get the scheme target ids and the buildRequest.json mentions every target, so we instead build the previously requested target. this means we can get a green result for a target which signals to Indexing that its good to go. Index-while-building will help a bit here, but not make it perfect.

[brentleyjones]

@BalestraPatrick I think 727681df4f91e2e2f38c35f78cea9f6f001430e3 actually fixed this, since the first bullet above no longer applies. We might still have issues because of the off-by-one "this target is green, everything is good to go", but it should be a lot less. Can you report your findings here? Regardless I think we should leave the issue open, since I would like to remove the off-by-one if possible, and keeping it open will remind me of that.