digitalmars.D - Any way to get file/line for symbol declaration?
- Manu (11/11) Jun 09 2019 I have some reflection-heavy validation code, it's necessary that I
- Andre Pany (9/22) Jun 09 2019 I have a very similar use case. I need for a module name the
- Manu (5/27) Jun 09 2019 I'm thinking something like: __traits(getLoc, symbol) ==
- Nicholas Wilson (2/5) Jun 09 2019 https://github.com/dlang/dmd/pull/10013
- Guillaume Piolat (4/9) Jun 16 2019 I read a Twitter post from Adam about it and initially thought it
- Sebastiaan Koppe (3/8) Jun 16 2019 This is awesome, didn't saw the pr before. I am going to use it
- Jacob Carlborg (6/7) Jun 16 2019 Seems we should have a form of Compiler object to query this information...
- Mike Franklin (3/7) Jun 16 2019 Yes, we should.
- Mike Franklin (7/14) Jun 09 2019 This is actually a very good idea, IMO. I actually see a lot of
- Mike Franklin (9/14) Jun 09 2019 Man! The more I wordsmith my writing the worse it gets. Here's
- Atila Neves (2/16) Jun 10 2019 +1
- SeanArbogast (2/2) Jun 11 2019 Symbols are very important in many points of view, beginning from
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 2019
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 2019
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'm thinking something like: __traits(getLoc, symbol) == AliasSeq!(file, line, column) for the declaration of the symbol specified.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.
Jun 09 2019
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 2019
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 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?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 16 2019
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:This is awesome, didn't saw the pr before. I am going to use it to create css sourcemaps.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 16 2019
On 2019-06-10 03:04, Nicholas Wilson wrote:https://github.com/dlang/dmd/pull/10013Seems 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 2019
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_ParameterYes, we should. Mike
Jun 16 2019
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 2019
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 2019
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:+1This 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 10 2019
Symbols are very important in many points of view, beginning from the start of the work.
Jun 11 2019