Add __traits(getLocation)

[thewilsonator]

https://forum.dlang.org/thread/mailman.9439.1560115627.29801.digitalmars-d@puremagic.com

[TurkeyMan]

Oh wow, perfect. Thanks!!

[thewilsonator]

Oh wow, perfect. Thanks!!

No probs, you're writing the test suite for it though!

Specifically all the cases that look like symbols but actually end up as something else e.g. DsymbolExp is an expression (i've no idea how to get one of them though), structs and classes are types (their declarations are dsymbols, but they aren't). There's probably a whole lot more edge cases like that.

[thewilsonator]

And things like overload sets.

[WalterBright]

use the void*,size_t overload.

[thewilsonator]

should the string be mem.xdup'ed too? I wasn't sure if e.g. ctfe screws with the contents.

[jacob-carlborg]

• Would be nice to have a test that tests all elements returned and not just first one
• Needs a changelog as well.

changelog added, test for line and column added

[dlang-bot]

Thanks for your pull request and interest in making D better, @thewilsonator! 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 annotated coverage diff directly on GitHub with CodeCov's browser extension
• 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 "master + dmd#10013"

[PetarKirov]

What happens if the module name is not explicitly specified? I would expect the module name to be inferred from the file name and things to just work.

[thewilsonator]

I think so, this was just out of habit to add a module declaration.

[thewilsonator]

I checked, you get verbatim what was passed on the command line .././../foo/./../file.d and all.

[PetarKirov]

Thanks for checking, indeed we should use an explicit module name here in that case.

[ghost]

Please add handling of overloads. A mention in the changelog is not enough and will be forgotten soon.

Test case accompanying the suggested changes:

module trait_loc_ov_err;
/*
TEST_OUTPUT:
---
fail_compilation/trait_loc_ov_err.d(25): Error: cannot get location of an overload set, use `__traits(getOverloads, ..., "ov1")[N]` to get the Nth overload location
fail_compilation/trait_loc_ov_err.d(26): Error: cannot get location of an overload set, use `__traits(getOverloads, ..., "ov2")[N]` to get the Nth overload location
fail_compilation/trait_loc_ov_err.d(27): Error: cannot get location of an overload set, use `__traits(getOverloads, ..., "OvT(T)")[N]` to get the Nth overload location
---
*/

void ov1(){}
void ov1(int){}

void ov21(){}
void ov22(int){}
alias ov2 = ov21;
alias ov2 = ov22;

template OvT(T){}
template OvT(T, U){}

enum e1 = __traits(getLocation, ov1);
enum e2 = __traits(getLocation, ov2);
enum e3 = __traits(getLocation, OvT);

[thewilsonator]

Done.

[thewilsonator]

Hmm, so

template OvT(T, U){}
template OvT(T){}
enum e9  = __traits(getLocation, __traits(getOverloads, trait_loc_ov_err, "OvT", true)[1]);
enum e10 = __traits(getLocation, __traits(getOverloads, trait_loc_ov_err, "OvT", true)[0]);

will always give an error because it seems that using templates with __traits(getOverloads) doesn't remove the symbol from the overload set, that is td.overnext is always non-null for the first template.

I'm tempted to just define it to always return the first overload of the set, or even just add an integer option to select which overload as part of the trait.

Any thoughts, ideas, opinions?

[ghost]

Any thoughts, ideas, opinions?

Yes, my suggestion would be to comment the handling of td and leave a note : FIXME:td.overnext is always set, even when using an index on it. I've tried to set overnext to null in expressionsem for IndexExp but that does not work so far (or create bounds CT error), although it would be the place to do that. The problem is that it's possible that the overload set would be something not to touch, i.e I'm not sure it's rebuild each time a symbol lookup is made...

[ghost]

@thewilsonator : abandoning the detection of template overloads is the way to go.

[thewilsonator]

Finally got around to it.

[adamdruppe]

is this in the new release? looks like no...

[Geod24]

No it did not make the cut.

[baryluk]

Hi, that is amazing and super useful. Could we also get a simple wrapper in std.traits for this? I was looking at std.traits, and could find info, and I almost finished writing a bug report to report filename / line for the symbol, but there is mechanism for it in compiler, just not in std.traits, which makes it harder to find. Maybe the wrapper could format it into "filename:line:column" string automatically, and make a note about using __traits directly to get structured info?