www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Any way to get file/line for symbol declaration?

reply Manu <turkeyman gmail.com> writes:
I have some reflection-heavy validation code, it's necessary that I
emit meaningful error messages to the user explaining when inputs
don't meet expectation.

I'm finding that emitting an FQN along with the error messages is not
super productive.
I'd REALLY like to emit the error with the proper file and line prefix
so that you can click and code editors will go to the problem
declaration.

I can't find any way to dig the Loc of the declaration from the symbol
reference. Does anyone know any tricks? Should I make a PR to expose
the symbol Loc as a traits?
Jun 09
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 9 June 2019 at 21:26:52 UTC, Manu wrote:
 I have some reflection-heavy validation code, it's necessary 
 that I emit meaningful error messages to the user explaining 
 when inputs don't meet expectation.

 I'm finding that emitting an FQN along with the error messages 
 is not
 super productive.
 I'd REALLY like to emit the error with the proper file and line 
 prefix
 so that you can click and code editors will go to the problem
 declaration.

 I can't find any way to dig the Loc of the declaration from the 
 symbol reference. Does anyone know any tricks? Should I make a 
 PR to expose the symbol Loc as a traits?
I have a very similar use case. I need for a module name the filename. I also thought about s.th. like __traits(file, "module name") The idea is, the return value is the same like __FILE__ in the scope of the module. Anything which would enable it would be very welcome. Kind regards Andre
Jun 09
parent reply Manu <turkeyman gmail.com> writes:
On Sun, Jun 9, 2019 at 2:40 PM Andre Pany via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Sunday, 9 June 2019 at 21:26:52 UTC, Manu wrote:
 I have some reflection-heavy validation code, it's necessary
 that I emit meaningful error messages to the user explaining
 when inputs don't meet expectation.

 I'm finding that emitting an FQN along with the error messages
 is not
 super productive.
 I'd REALLY like to emit the error with the proper file and line
 prefix
 so that you can click and code editors will go to the problem
 declaration.

 I can't find any way to dig the Loc of the declaration from the
 symbol reference. Does anyone know any tricks? Should I make a
 PR to expose the symbol Loc as a traits?
I have a very similar use case. I need for a module name the filename. I also thought about s.th. like __traits(file, "module name") The idea is, the return value is the same like __FILE__ in the scope of the module. Anything which would enable it would be very welcome.
I'm thinking something like: __traits(getLoc, symbol) == AliasSeq!(file, line, column) for the declaration of the symbol specified.
Jun 09
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 9 June 2019 at 22:17:08 UTC, Manu wrote:
 I'm thinking something like: __traits(getLoc, symbol) ==
 AliasSeq!(file, line, column) for the declaration of the symbol
 specified.
https://github.com/dlang/dmd/pull/10013
Jun 09
next sibling parent Guillaume Piolat <contact+spam spam.org> writes:
On Monday, 10 June 2019 at 01:04:42 UTC, Nicholas Wilson wrote:
 On Sunday, 9 June 2019 at 22:17:08 UTC, Manu wrote:
 I'm thinking something like: __traits(getLoc, symbol) ==
 AliasSeq!(file, line, column) for the declaration of the symbol
 specified.
https://github.com/dlang/dmd/pull/10013
I read a Twitter post from Adam about it and initially thought it was for getting the "lines of code" (LoC) of a function. Would that also make sense as a trait?
Jun 16
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Monday, 10 June 2019 at 01:04:42 UTC, Nicholas Wilson wrote:
 On Sunday, 9 June 2019 at 22:17:08 UTC, Manu wrote:
 I'm thinking something like: __traits(getLoc, symbol) ==
 AliasSeq!(file, line, column) for the declaration of the symbol
 specified.
https://github.com/dlang/dmd/pull/10013
This is awesome, didn't saw the pr before. I am going to use it to create css sourcemaps.
Jun 16
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-06-10 03:04, Nicholas Wilson wrote:

 https://github.com/dlang/dmd/pull/10013
Seems we should have a form of Compiler object to query this information and a lot more. Something like the Context parameter of AST macros [1]. [1] https://wiki.dlang.org/DIP50#The_Context_Parameter -- /Jacob Carlborg
Jun 16
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Sunday, 16 June 2019 at 19:31:38 UTC, Jacob Carlborg wrote:

 Seems we should have a form of Compiler object to query this 
 information and a lot more. Something like the Context 
 parameter of AST macros [1].

 [1] https://wiki.dlang.org/DIP50#The_Context_Parameter
Yes, we should. Mike
Jun 16
prev sibling next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Sunday, 9 June 2019 at 21:26:52 UTC, Manu wrote:

 I'd REALLY like to emit the error with the proper file and line 
 prefix
 so that you can click and code editors will go to the problem
 declaration.

 I can't find any way to dig the Loc of the declaration from the 
 symbol reference. Does anyone know any tricks? Should I make a 
 PR to expose the symbol Loc as a traits?
This is actually a very good idea, IMO. I actually see a lot of potential in the D's traits system for exposing more information like this from the compiler to users' programs. I'd like to the traits feature set judiciously expanded with such things. So thumbs up from me. Mike
Jun 09
parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Monday, 10 June 2019 at 01:58:37 UTC, Mike Franklin wrote:

 This is actually a very good idea, IMO.  I actually see a lot 
 of potential in the D's traits system for exposing more 
 information like this from the compiler to users' programs.  
 I'd like to the traits feature set judiciously expanded with 
 such things.  So thumbs up from me.
Man! The more I wordsmith my writing the worse it gets. Here's what I meant to say. This is actually a very good idea, IMO. I see a lot of potential in D's traits system for exposing more information like this from the compiler to users' programs. I'd like to see the traits feature set judiciously expanded with such things. So thumbs up from me. Mike
Jun 09
parent Atila Neves <atila.neves gmail.com> writes:
On Monday, 10 June 2019 at 02:02:29 UTC, Mike Franklin wrote:
 On Monday, 10 June 2019 at 01:58:37 UTC, Mike Franklin wrote:

 This is actually a very good idea, IMO.  I actually see a lot 
 of potential in the D's traits system for exposing more 
 information like this from the compiler to users' programs.  
 I'd like to the traits feature set judiciously expanded with 
 such things.  So thumbs up from me.
Man! The more I wordsmith my writing the worse it gets. Here's what I meant to say. This is actually a very good idea, IMO. I see a lot of potential in D's traits system for exposing more information like this from the compiler to users' programs. I'd like to see the traits feature set judiciously expanded with such things. So thumbs up from me. Mike
+1
Jun 10
prev sibling parent SeanArbogast <marilyn.christian yandex.com> writes:
Symbols are very important in many points of view, beginning from 
the start of the work.
Jun 11