RFC: Pass file/column/line information to custom string literals (#9577)

[Keno]

This is one possible way to handle #9577, but I'm not sure if it's ideal, because it forces people to declare the arguments to every _str macro even if they have no intention of doing anything with it. The other alternative I mentioned in #9577 is to save this information in a global variable that can be retrieved through a function call. That alternative seems more hacky though as it adds new global state and I'm not sure what would happen with quoted string literals. Alternative thoughts appreciated.

[Keno]

Alternatively it occurs to me, we could pass a LineNumberNode as the second argument. That would feel more macro-y.

[Keno]

@JeffBezanson I'm still very interested in getting location information for my string macros. Any new ideas as to the best way to do that?

[StefanKarpinski]

It seems like having a mandatory additional StringLiteralInfo argument that includes all of this as a single object might be easier and allow for more info to be added without breaking code in the future.

[Keno]

Yes, that would be nice to have.

[ScottPJones]

Does it need to be a mandatory argument (which would break all current string macros)?
Does it need to be limited to string macros?
Instead, for all macros, could it have a local symbol bound to an object with all that information?
(file name, line number, enclosing module, enclosing type or method...)
That would not break anything at all, and would be more generally useful to boot.

[Keno]

String macros can't have optional arguments, so it either needs to be mandatory (though it's generally possible to do define the macros in a backwards compatible way) or some more fancy mechanism needs to be used. I suppose it would be possible to do this for all macros, though I haven't found any use for it yet. I worry that exposing too much scope information would open the door to macros that are extremely context sensitive. Right now, macros nicely only operate on the syntax they are passed. I'm sure @JeffBezanson has strong opinions here.

[ScottPJones]

@Keno What I've suggested is no different that C/C++ code being able to use __LINE__ and __FILE__, in macros or in the source code. I'm saying that it should be an explicit argument, but rather, something that gets bound implicitly (like __FILE__ and __LINE__), could be something like: __LOCATION__, that wouldn't even have anything created if it isn't referenced within the macro.
This isn't really about making extremely context sensitive macros, but it allows macros to be able to save away information for debugging or error reporting, for example, or for documentation purposes.
It would be easy to document that all macros implicitly get passed this argument.

[Keno]

I'm fine with line and file that seems useful, I have a problem with enclosing module, enclosing type or method....

[ScottPJones]

@Keno Those are very useful (necessary?) if you want to try to associate documentation with particular fields within a type, for example. What are you concerned about in particular with having the extra information?
Also, what do you think about the approach I came up with for handling this without breaking anything?

[ihnorton]

Related: Laurence Tratt's recent post about "Debugging Layers" in Converge (h/t @jakebolewski).

[vtjnash]

i think this has been resolved (via introduction of @__LINE__) and can be deleted?

[Keno]

This is not resolved. @__LINE__ is resolved during parsing, so not useful here.

[vtjnash]

Rebased as jn/kf-linecolstr. But need to fix the column numbers for macros to point at the the first symbol of the first argument for this to be useful for its original purpose. (currently, it tries to describe the @ sign, but I think pointing at the first symbol of the first argument is reasonable, given that we aren't planning on describing the line/column ranges for the entire parse tree).