Fix Issue 23241 - Consider types with no symbol (e.g. int) to have no…

[maxhaton]

… attributes

not completely convinced about this

[dlang-bot]

Thanks for your pull request, @maxhaton!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	23241	blocker	__traits getMember breaks compilation when hit an alias

⚠️⚠️⚠️ 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#14298"

[thewilsonator]

This is a blocker, should it target stable?

[BorisCarvajal]

I think the trait should accept anything semantically correct and just return an empty tuple if no uda is available,
it would avoid this repetitive pattern:

static if (__traits(compiles, __traits(getAttributes, arg)))
	alias udas = __traits(getAttributes, arg);

[RazvanN7]

This patch seems to address a symptom of a larger issue: eager substitution of alias. For example, this patch ignores the UDA for:

@("hi2") alias MyEnum = int;

Maybe semanticTiargs can be modified as to not substitute the alias in this situation. However, this may be complicated since you may have an alias to a symbol that also has an UDA. I think that getAttributes should only get the UDA of the alias, not for the aliased symbol.

[maxhaton]

This patch seems to address a symptom of a larger issue: eager substitution of alias. For example, this patch ignores the UDA for:

@("hi2") alias MyEnum = int;

Maybe semanticTiargs can be modified as to not substitute the alias in this situation. However, this may be complicated since you may have an alias to a symbol that also has an UDA. I think that getAttributes should only get the UDA of the alias, not for the aliased symbol.

That's a much bigger change of behaviour that would probably break quite a lot of code if done wrong

[maxhaton]

This patch seems to address a symptom of a larger issue: eager substitution of alias. For example, this patch ignores the UDA for:

@("hi2") alias MyEnum = int;

Maybe semanticTiargs can be modified as to not substitute the alias in this situation. However, this may be complicated since you may have an alias to a symbol that also has an UDA. I think that getAttributes should only get the UDA of the alias, not for the aliased symbol.

@RazvanN7 I have fixed the code. Please remove your requested changes as it has nothing to do with this PR and constitutes a large change in behaviour which would have to be decided somewhere else.

[ibuclaw]

I offer a suggestion, and still it's spelled wrong.

[RazvanN7]

Well, I am not convinced that this is the right fix. It seems to me that this PR is like giving painkillers to a cancer patient. Sure, it makes it better, but it's not actually addressing the real issue. However, I don't want to block this if others agree that it should get in.

.

[maxhaton]

@ibuclaw

Requested change applied

[PetarKirov]

Looks good me. Even if the right thing to do is not resolve aliases too early, this change is still a step in the right direction as __traits(getAttributes, int) should return an empty value sequence, instead of failing to compile (expressed differently: all types should be symbols, including built-in ones).