Fix Hack: Remove hasCheckedAttrs from VarExp

[JinShil]

hasCheckedAttrs was a member variable of VarExp introduced in #8404 to avoid having the deprecation message printed multiple times as expressionSemantic could have been called on the same VarExp multiple times.

While working on a bug fix recently, I discovered that we could avoid that hack by checking for deprecation in EnumMember.GetVarExp, as is done with checkDisabled.

This PR removes the hack and makes the code more consistent with the existing implementation.

[dlang-bot]

Thanks for your pull request, @JinShil!

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 "master + dmd#8644"

[PetarKirov]

Took me a little while to see that DeprecatedDeclaration._scope is used here:

dmd/src/dmd/dsymbolsem.d

Lines 410 to 428 in 58fde67

	const(char)* getMessage(DeprecatedDeclaration dd)
	{
	if (auto sc = dd._scope)
	{
	dd._scope = null;
	sc = sc.startCTFE();
	dd.msg = dd.msg.expressionSemantic(sc);
	dd.msg = resolveProperties(sc, dd.msg);
	sc = sc.endCTFE();
	dd.msg = dd.msg.ctfeInterpret();
	if (auto se = dd.msg.toStringExp())
	dd.msgstr = se.toStringz().ptr;
	else
	dd.msg.error("compile time constant expected, not `%s`", dd.msg.toChars());
	}
	return dd.msgstr;
	}

which is called from here:

dmd/src/dmd/dsymbol.d

Lines 300 to 324 in ce5e177

	final bool checkDeprecated(const ref Loc loc, Scope* sc)
	{
	if (global.params.useDeprecated != 1 && isDeprecated())
	{
	// Don't complain if we're inside a deprecated symbol's scope
	if (sc.isDeprecated())
	return false;
	const(char)* message = null;
	for (Dsymbol p = this; p; p = p.parent)
	{
	message = p.depdecl ? p.depdecl.getMessage() : null;
	if (message)
	break;
	}
	if (message)
	deprecation(loc, "is deprecated - %s", message);
	else
	deprecation(loc, "is deprecated");
	return true;
	}
	return false;
	}

[PetarKirov]

From #8645 (comment):

Hmm. Looks suspiciously familiar (#8644). I'd like to wait for that to make it to stable first.

@JinShil Did you intend to target stable with this PR? (If this PR is merged to master, you'll need to wait until the next merge from master to stable, which is after ~2 months.)

[JinShil]

Did you intend to target stable with this PR?

No, it's not a critical PR. I know my other PR is waiting on it, but I think it can wait until the next master --> stable merge. I'm not even sure if there's a real dependency yet.

[PetarKirov]

Alright, thanks for confirming.