Fix 20674, 23208, 23300 - improve scope inference

[dkorpel]

Remove the complex and broken eliminateMaybeScopes system for parameters, and use a simpler scheme for both parameters and local variables. When you assign va = v, then add a link from va to v and when va becomes return scope or notMaybeScope, then do the same for v.

It's not complete yet, I still need to go the other way and test more thoroughly, but I'm already opening a PR to get feedback from the test suite, and so that I can link to this central PR when making smaller PRs.

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20674	enhancement	[DIP1000] inference of `scope` is easily confused
✓	23208	normal	[dip1000] missing return scope inference after parameter assignment
✓	23294	normal	[dip1000] parameter to parameter assignment leads to incorrect scope inference
✓	23300	normal	std.array : array wrongly propagates scopeness of source

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14492"

[nordlow]

Thank you for doing this. This, as far as the comment goes, seems much easier to reason about.

[nordlow]

Will this refactoring make it easier to implement automatic scope inference of variables? Even including parameters of function templates? An idea Walter has approved of.

[dkorpel]

Will this refactoring make it easier to implement automatic scope inference of variables?

This is not a refactoring, it is the new implementation of automatic scope inference on function parameters.

Currently scope parameter inference fails in two ways:

• On assignment to another parameter: it's too permissive; doesn't consider relative lifetime (23294) and neglects return scope (23208)
• On assignment to a local variable: it's pessimistic, it gives up immediately (20674)

The new system treats both the same, and puts every 'maybe scope' variable in a set. When one maybe scope variable is assigned to another, it joins the two sets. As soon as any of them is inferred return scope or considered 'not maybe scope', then the set collapses and all variables in it become return scope / 'not maybe scope'. This system passed the test suite in my first implementation using an array of neighbors, but I'm now in the process of switching to a Disjoint-set data structure and currently it's red again.

The new system is still a bit pessimistic, but:

• It's relatively simple
• It has almost linear time complexity (Walter does not want to do Data Flow Analysis in the frontend because it's slow)
• It fixes the most common reason of scope inference failure: assignment to a temporary variable.

Even including parameters of function templates?

Scope inference of parameters is only enabled in templates, nested functions and auto returning functions.

[nordlow]

src/dmd/frontend.h needs update as per https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=5352408&isPull=true.

To update frontend.h and fix this error, run the following command:

../../generated/build cxx-headers-test AUTO_UPDATE=1

[dkorpel]

src/dmd/frontend.h needs update

I know, see the WIP tag ;)

I'm currently focusing on making my test case for return scope inference after assignment pass.

[nordlow]

I'm currently focusing on making my test case for return scope inference after assignment pass.

Ahh, sorry.

[rikkimax]

This work appears to be much more important than just scope inference.

Having a way to tie a variable to its lifetime root, means we have a way to ensure the correct order of destruction of memory; this means we can very easily do a "borrow checker" with only the owner being able to be destroyed automatically. 😄