fix Issue 20072 - [2.087.0] Mixin templates: no property somevar for type some.Type, did you mean some.Type.__anonymous.somevar?

[tgehr]

I'm not sure if it is even possible that a ForwardingAttribDeclaration is stored in some declaration's parent field, but I'm leaving it in for now, to avoid creating a regression.

[dlang-bot]

Thanks for your pull request and interest in making D better, @tgehr! 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 fetch digger
dub run digger -- build "stable + dmd#10214"

[WalterBright]

This has introduced a regression: https://issues.dlang.org/show_bug.cgi?id=20308

[tgehr]

@WalterBright This PR fixes a bug that would sometimes lead to frame pointer access not being checked at all, such as in John's example (because parent resolution would get stuck at the anonymous scope of static foreach). The following helpful comment is on the stack trace I get when instrumenting the frame access error with an assert(0):

            // TODO: If fd isn't yet resolved its overload, the checkNestedReference
            // call would cause incorrect validation.
            // Maybe here should be moved in CallExp, or AddrExp for functions.
            if (fd.checkNestedReference(sc, e.loc))
                return setError();

https://github.com/dlang/dmd/blob/master/src/dmd/expressionsem.d#L3850

[WalterBright]

What do you suggest as a fix?

[tgehr]

As that comment says, the frame pointer check needs to happen after overload resolution/template instantiation instead of before. (I think for John's code, the problem is that checkNestedReference doesn't know that the handler lambdas are static and therefore do not need access to the frame pointer.) This bug was in DMD before this pull request was merged, it was just accidentally masked by the initial static foreach implementation in some circumstances and now occurs again after the fix.