Alternative fix to issue 17548 - [REG2.072.0] Forward reference error with scope function parameters

[Syniurge]

Previous PR: #6934

This one line fix ensures that if a StructDeclaration.semantic() call has to defer itself, semanticRun is set to PASSsemantic, because it may already have been set to PASSsemanticdone if a second StructDeclaration.semantic() call on the same struct happened while semantic'ing its members (see how in the Bugzilla issue) and then the deferred call would immediately return.

[dlang-bot]

Thanks for your pull request, @Syniurge! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.

Some tips to help speed things up:

• smaller, focused PRs are easier to review than big ones

• try not to mix up refactoring or style changes with bug fixes or feature enhancements

• provide helpful commit messages explaining the rationale behind each change

Bear in mind that large or tricky changes may require multiple rounds of review and revision.

Please see CONTRIBUTING.md for more information.

Bugzilla references

Auto-close	Bugzilla	Description
✓	17548	[REG2.072.0] Forward reference error with scope function parameters

[Syniurge]

I have a question about this code in StructDeclaration.semantic:

    else if (symtab && !scx)
    {
        semanticRun = PASSsemanticdone;
        return;
    }

What's the rationale? Is it assuming that this may only happen if there was a previous StructDeclaration.semantic call which failed with:

        if (!determineFields())
        {
            assert(type.ty == Terror);
            sc2.pop();
            return;
        }

which is why it sets semanticRun to PASSsemanticdone?

If yes the assumption's wrong, and a proper fix would probably be to get rid of that assignment?

[Syniurge]

So this works too:

         else if (symtab && !scx)
 -        {
 -            semanticRun = PASSsemanticdone;
              return;
 -        }

         (...)

         if (!determineFields())
          {
              assert(type.ty == Terror);
              sc2.pop();
 +            semanticRun = PASSsemanticdone;
              return;
          }

and I think this is the proper fix.

Why isn't the auto-tester running though?

[CyberShadow]

@braddr Here's another instance of the autotester apparently ignoring a PR.

[braddr]

In this case, it's easy.. new user, not approved yet for builds to be processed. Just look here:
https://auto-tester.puremagic.com/pulls.ghtml?projectid=14

[CyberShadow]

Aah, forgot about that, thanks!

Edit: Approved @Syniurge.

[UplinkCoder]

@WalterBright this looks okay at a glance.

[Syniurge]

Ping?

[MartinNowak]

Looks good, so the problem was that we set this to done here, even though we might be in a recursive call to StructDeclaration.semantic, with the outer semantic still ongoing on it's members, hence providing wrong semanticRun state info for any further members.