[Call for testing] Catching debug info violations at -Onone

I would like to discuss the path towards enabling a new debug info verifier pass by default.
This should improve the debug experience of users at `-Onone`.

## Problem Description
Mandatory passes which run at `-Onone` can attach a wrong scope when they create instructions.
This may result in wrong debug informations generated and degraded debugger experience.

Examples of bugs of this kind recently fixed:

## Proposed solution

There’s currently nothing preventing compiler writers to attach the wrong scope, so, I’m going to check in a verifier pass to find holes in SIL debug scopes at -Onone.
Reference: https://github.com/apple/swift/pull/13491 , which contains the code and a description of the heuristic used.

## Plan to enable this by default

I fixed all the bugs that have been found on the testsuite, but this seems to find still issues on larger projects (most notably, swiftpm), so for now this is disabled (but can be enabled using a flag [-Xllvm -verify-di-holes]). I’m working to

I would really appreciate if the community can test their swift projects with this flag enabled and report bugs.
I would also appreciate general feedback on the path forward.




Enabling this verifier by default sounds like a good idea, as long as we only do it in +Asserts builds to avoid any compile time overhead in the -Asserts builds. After you’ve gotten people to try it out and fixed as many problems as you can, I am up for giving this a try.

The swift.org downloadable toolchains are built with assertions, so this would affect those builds. Can you make the verifier failures print out really clear directions for what a user should do if they hit that? I’m thinking that should include (1) filing a bug report with a testcase (if possible), and (2) instructions to recompile with an option to disable the verifier. Is there such an option?

Hi @Bob_Wilson,
I agree this should print proper instructions on how to disable the flag (yes, there's one). I'll send a PR.
In the meanwhile, I tried the swift source compatibility test suite as Michael G recommended and it came out clean

I found another bug today on a larger project https://bugs.swift.org/browse/SR-6838 which I'm going to fix soon, but other than that, it seems to be clean on large part of the code I've experimented with.

Once the outstanding bug is fixed & I'll merge the patch for improved instructions on how to report bugs/disable the verification, I'll follow-up on this post.



I would like to make this happen so that we can prevent regressions from happening in the future.
If you want to help, you can probably download a nightly toolchain and pass to swiftc invocations -Xllvm -verify-di-holes to enable the verifier (and report bugs, if any).

If you have any comments/feedback, please let me know!