Fix Issue 22054 - Referencing a fwd-declared field results in many error messages

[RazvanN7]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @RazvanN7! 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
✓	22054	regression	Referencing a fwd-declared field results in many error messages

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

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

[MoonlightSentinel]

Note that your branch is missing #12671. That PR is related because it fixes ClassDeclaration.search (and others) to adhere to IgnoreErrors used during symbol resolution.

This patch suffices for current master and produces a somewhat better error message:

diff --git a/src/dmd/dclass.d b/src/dmd/dclass.d
index 9c5f0da2f..f9b4aba37 100644
--- a/src/dmd/dclass.d
+++ b/src/dmd/dclass.d
@@ -498,7 +498,7 @@ extern (C++) class ClassDeclaration : AggregateDeclaration
         if (!members || !symtab) // opaque or addMember is not yet done
         {
             // .stringof is always defined (but may be hidden by some other symbol)
-            if (ident != Id.stringof && !(flags & IgnoreErrors))
+            if (ident != Id.stringof && !(flags & IgnoreErrors) && semanticRun < PASS.semanticdone)
                 error("is forward referenced when looking for `%s`", ident.toChars());
             //*(char*)0=0;
             return null;

Error: no property `what` for type `test22054.exception`

[MoonlightSentinel]

Also would be good to test the behavior for opaque structs and enums (the latter won't work with your current patch - unless it's already handled another way)

[RazvanN7]

@MoonlightSentinel Your patch is superior, so I implemented that, however, I added a supplemental error for aggregated types.

[MoonlightSentinel]

D does not support forward declarations, this should probably refer to an opaque type.
Also, can this error message be triggered for an actual forward reference error?

[RazvanN7]

D does not support forward declarations, this should probably refer to an opaque type.

changed.

Also, can this error message be triggered for an actual forward reference error?

Sorry, I don't understand what you mean.

[MoonlightSentinel]

symtab might be null if this error occurs early into in the semantic of exception. But i think it's currently impossible to write code that could trigger such scenarios. (e.g. base classes/interface for opaque classes are rejected by the parser).

class Opaque : Check!Opaque;

class Check(T)
{
    // Try to access T's members
}

[RazvanN7]

Typically, forward reference errors are issued before noMember is called.

[thewilsonator]

Is this good to go?

[RazvanN7]

I would say so.

[MoonlightSentinel]

Otherwise LGTM

[RazvanN7]

@MoonlightSentinel done.