[DO NOT MERGE] Implement PoC DFA engine for nullability and truthiness

[rikkimax]

Throwing the experimental fast DFA engine at CI to see what happens, this PR is not going to be merged can be ignored.

[dlang-bot]

Thanks for your pull request and interest in making D better, @rikkimax! 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

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

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#21494"

[rikkimax]

Ugh isBinExp doesn't work for EXP.loweredAssignExp flags are not set for it even though the hierarchy matches.

[benjones]

---

__stdin.d(14): Error: Assert can be proven to be false
assert(a is b);

shouldn't a and b both be null at that point?

[rikkimax]

__stdin.d(14): Error: Assert can be proven to be false
assert(a is b);

shouldn't a and b both be null at that point?

Yes, it's a false positive and needs fixing on my end.

[rikkimax]

True positives:

• dmd/compiler/test/runnable/template9.d

  Line 3408 in 2a47e88

  immutable int[][] mat;

runnable\template9.d(3410): Error: Argument is expected to be non-null but was null
    mat.map_front12186!((in r) => 0);              // OK
       ^
runnable\template9.d(3400):        For parameter `r` in argument 0
    auto map_front12186(Range)(Range r)

• dmd/compiler/test/compilable/test21299d.d

  Line 25 in 2a47e88

  moveToEnd([], hook);

compilable\test21299d.d(25): Error: Argument is expected to be non-null but was null
        moveToEnd([], hook);
                 ^
compilable\test21299d.d(16):        For parameter `array` in argument 0
    void moveToEnd(T, Pred = DefaultPredicates.IsEqual!T)(T[] array, T element, Pred pred = Pred.init)

• dmd/compiler/test/compilable/test22916.d

  Line 28 in 2a47e88

  scope char** _errors;

compilable\test22916.d(29): Error: Argument is expected to be non-null but was null
    g = front_p(_errors);   // should pass
               ^
compilable\test22916.d(21):        For parameter `p` in argument 0
   ref char* front_p(ref return scope char** p) { return *p; }

#21941

Overall the interprocedural nullability analysis looks to be working. Although unit-threaded will need to be analysed (can't be bothered to do it atm).

[rikkimax]

Waiting on this PR to go green and the following PR's to be merged.

• Fix null deref in optional_methods test #21963 Refix null deref in optional_methods test to not new an interface #21966
• Fix null dereference in expressionsem #21964

Will follow with final PR after this.

[thewilsonator]

Grammar?
Is any symbol this scope is applied [to?] known to have a compile time only accessible context.

bool knownACompileTimeOnlyContext; feels like it should be
knownCompileTimeOnlyContext or knownAtCompileTimeOnlyContext

[rikkimax]

Singular is correct, it may not be exclusive to CT.

So something like knownToHaveANonExclusiveCompileTimeOnlyContext.

However this isn't the right way to solve it long term. The right solution is to have something like @__ctfe and tell people to annotate their code appropriately rather than letting the compiler ignore problems. I sent Walter and Atila an email requesting that they think about where they want to go here, but that doesn't appear to have gone anywhere.

The adding of to will happen on follow up PR.

[thewilsonator]

FuncDeclaration.parameters index?

[rikkimax]

Yes, updated for next PR.

[thewilsonator]

Data Flow Analysis. also feel free to add more events (if there are logical places to put them) if it makes producing statistics for how much time this consumes.

[rikkimax]

It is enough for the fast DFA.

Having only like 8 instances show up on 100k LOC codebase is pretty telling and they are 1-2ms each.

I'm sure it'll need adjusting for the error pass, and slow DFA, but we aren't there right now.