[6.0] SILGen: Ignore placeholders and missing methods during conformance emission #72915
Conversation
…ission. Builds on swiftlang#72286. Use a more forgiving strategy when handling potentially invalid conformances during SILGen. Conformances may be erroneously marked invalid during witness resolution, even when they can still be successfully emitted, so we can't bail out of witness table emission if the invalid bit is set. Instead, just ignore placeholders and missing methods in the witness table emitter and trust that if an error was diagnosed during resolution that compilation will be aborted. Resolves rdar://125947349
|
@swift-ci please test |
| // discovers and invalid conformance. The diagnostics emitted during witness | ||
| // resolution should cause compilation to fail. | ||
| void addPlaceholder(MissingMemberDecl *placeholder) {} | ||
| void addMissingMethod(SILDeclRef requirement) {} |
There was a problem hiding this comment.
Can we add asserts about that lazy type checking is enabled in these function bodies?
There was a problem hiding this comment.
I think such an assert would be a liability in the future as we move towards more laziness by default in the compiler. In my opinion we should not assert unless we can guarantee that there is a fatal problem. We often have trouble building real-world projects with asserts compilers because of ambitious asserts, and this feels to me like it would be such an assert.
There was a problem hiding this comment.
this feels to me like it would be such an assert.
IIUC, are you saying that we may already step on the llvm_unreachable case nowadays?
There was a problem hiding this comment.
No, I'm saying that I think leaving an assert in here predicated on a flag would be too fragile to be worth it. This is not the appropriate stage of compilation to decide whether or not this condition is unexpected and crash the compiler. The condition that ought to be checked is "did we fail to emit this witness and also not emit a diagnostic?". That would be better done at a later stage, where we can assume that if we've made it that far we didn't emit any fatal diagnostics during SILGen.
There was a problem hiding this comment.
OK. I'm just a little bit concerning about the potential loss of the qualification and documentation capability of an unreachable statement without providing alternatives back in place.
release/6.0that is reproducible with a handful of projects.