Turn off PCM validation by default.

[adrian-prantl]

These diagnostics are useful when debugging LLDB and project configurations, but in a live debug session they mostly get in the way. Especially when using explicit modules mismatches in warning options caused by implicitly triggered imports are not really actionable fo users outside of clearing their module cache and trying again.

rdar://130284825

[adrian-prantl]

@swift-ci test

[kastiglione]

In our conversation last week, I thought it was said that validation would be on by default. If the default is to be disabled, should it only be disabled for explicit modules?

Another thought: the validation checks warning/diagnostic flags, which we know we want to disable, but also checks language options (and target options, etc), which I'm not sure we want to disable. Should we add logic into the validation so that we can take the safer action of disabling only warnings/diagnostics validation?

[kastiglione]

This is from memory, but I believe pch validation gates the module relocation checks. In other words, disabling pch validation should make it unnecessary to explicitly disable module-check-relocated.

[JDevlieghere]

Would it make sense to keep "on" in debug/assert builds, an defaulting to "off" for release builds?

[adrian-prantl]

I think I addressed everyone's review comments. It's now set to auto by default, which means on iff explicit modules are on, or if we are in an asserts build. Because of that the test got weaker.

[adrian-prantl]

@swift-ci test

[adrian-prantl]

@swift-ci test windows

[JDevlieghere]

LGTM. I don't mind the AutoBool but I wonder if we don't have "better" support for LLDB's LazyBool.

[adrian-prantl]

LGTM. I don't mind the AutoBool but I wonder if we don't have "better" support for LLDB's LazyBool.

Great question, I basically copied & pasted this from another setting assuming that that's the way.