Function for getting source location inside string macros

[Keno]

For error reporting purposes, it would be convenient to expose line/column information to _str macros. This could either be done by passing them extra arguments in addition to the body of the string (in particular file/line/column of the start of the string) or adding a function that returns this information if inside a string macro.

[timholy]

Do we really need a special case here, or would this be handled by fixing #1334?

[Keno]

Possibly, though it doesn't quite seem to be the same thing. The goal here, is e.g. to be able to report syntax errors for embedded DSLs with accurate line information.

[simonster]

#8066 seems related. One can imagine adding a function that returns the source location from inside any macro, which would make @__LINE__ trivial, although I'm not sure what other use this would have once #1334 is fixed. Alternatively we could have __LINE__"" but that seems ugly.

[ihnorton]

How about adding an implicit first argument to every macro call where we pass a LineNumberNode representing the invocation site? That would allow IMHO a cleaner fix for this issue than #9579, would allow cleaner @__LINE__ and @__FILE__ implementations as trivial cases, and would be more extensible/flexible than the current parser special case for @__LINE__ (@IainNZ and @StefanKarpinski expressed a desire for more flexibility).

[mlubin]

Yes please

[StefanKarpinski]

What do we call it? __CALLER__? Implicitly defined inside of macros?

[ihnorton]

__LOCATION__?

Implicitly defined inside of macros?

Effectively, transform every macro from
macro Foo(my, args...) to
macro Foo(__LOCATION__, my, args...)

and change the parser so that @Foo passes the invocation site line info as the first argument. This does seem like a fairly large hammer to apply to the problem, so it might be a terrible idea.

[mlubin]

Useful error reporting is a huge issue with macros, not sure if the hammer is really that large.

[ihnorton]

Instinctively, this feels like a horrible band-aid, but I haven't come up with a practical downside yet (or better alternative -- my last idea was worse). So I'm hoping someone shoots it down and saves me an ~evening... If not, I'll give it a try.

[vtjnash]

rather than modifying every macro ever written to accommodate a new first argument, would it be practical to have a special functions (only callable from a macro), that returns these values?

[ihnorton]

Yikes, no. The additional argument would be added automatically in parsing and lowering, so it should be totally transparent to the user. Still might be a bad idea, but not that drastic.

would it be practical to have a special functions (only callable from a macro), that returns these values?

I was wondering about this. How does that special function know where the macro was invoked? The line information needs to be stored somewhere that is accessible at expansion time. The only idea I've come up with so far is:

• parser adds an extra line info expression to every macrocall argument list
• fl_invoke_julia_macro pops that line info and stores it in a global (?) before calling the macro-function
• (some book-keeping to restore the location after nested expansions)

[vtjnash]

was this fixed now that @__LINE__ exists?

[ihnorton]

@JeffBezanson any chance this could be bumped to a 0.5 target? #16335 seems to provide everything necessary at the AST level, but AFAICT we would still need a way to access that info from inside of macro-functions.

[StefanKarpinski]

#9577, #13339, #21746