remove filename from line number nodes

[JeffBezanson]

@carnaval is this what you want?

[vtjnash]

we could probably also just generally generically cache these in jst->struct_decl

[toivoh]

I use the filenames (and line numbers) in line number nodes in Debug.jl to keep track of source location. How would I do that going forward?

[JeffBezanson]

File names are available in LambdaInfo, and also (in theory, hopefully soon to be in practice) via backtraces.

[toivoh]

But LambdaInfo is for compiled methods, right? There will be no way for a macro to determine which source files went into creating the AST that was given to it?

[carnaval]

Ah. That may be a problem. The frontend could insert a '(meta push_lambda ,linfo) around blocks that are passed to macros (like we are trying to do for inline functions) ?
or maybe a meta push/pop_file because we don't have the linfo yet.

Or we could still have those filenames in there as before, just seemed weird to me to have the same information duplicated everywhere.

[JeffBezanson]

We could put (meta file x.jl) in surface ASTs I suppose. Macros are a difficult case though because they can expand to a mix of code from different locations.

[toivoh]

Also, different lines in functions can come from different files, after macro expansion. Would that information still be representable?

[carnaval]

yes I think you would need to have such a pair of node in every "toplevel" block, meaning the outer most block of a quote, including implicit quotes such as the argument to a macro. Feels a little better to me than having the file name everywhere but might not be worth the effort.

As an added benefit, those nodes could specify that the code is being quoted/macroed so we could display that in the backtrace maybe. Just thinking out loud.

[JeffBezanson]

Filename push/pop per outer quote block sounds pretty reasonable to me.

[toivoh]

Sure, that would be fine.

[JeffBezanson]

Hmm, adding "pop" at the end of blocks is actually tricky, since the last expression in a block determines its value. We might be able to handle this later in lowering, e.g. inserting "pop" only when merging one block into another in a non-final position.