I think doctests would also benefit from a mechanism like this, since I believe they currently use fake line numbers
8 Likes
I think if you specified a source map, that generally means you want to use it by default, so i think it would be better to have a compiler flag to opt-out of using a source map
Yeah we may want to make it default eventually but I was thinking that the parsing, tracking, and other computation needed for sourcemapping could slow down compilation even if no sourcemaps are used, so we might not want to do it for everyone.
But thinking about it some more, we could just make it default for debug builds but not release builds.
the problem with that logic is that, for most reasonable designs, any slowdown you get due to looking for the source-map attribute and enabling it if you find it will be basically identical to the slowdown you get with the compiler flag turned off -- you still need a bunch of if source_map_enabled branches either way
1 Like
As opposed to compiler directives that just overwrite the fields for file, line & column. No overhead at all, if you don't do that. And minimal overhead just at the point where you do reset them.
OTOH, @CAD97 raised interesting points: when the generated code comes from a template 1:1, rustc would advance line & column in the normal way. But when 10 lines of code are specified by one word in the meta source, it would be nice (at the price of an extra if, or two) to optionally freeze the counters.
1 Like
One cheap way to do this would be for rustc not to change the way it counts at all. Only when a position resetting directive is seen, would it be only added to a list, referencing the real position in the file. And then only when line!() or column!() is seen or an error message is to be output, would it look at the list and calculate the virtual position to report.
As a bonus this would make it easy (if they differ) to report both the virtual position and in parens the real position. That would allow to correlate the source with the generated Rust. All the more important, if we allow freezing the position (i.e. all following characters report the same virtual position.)
What if I have code that is generated from code that is generated (say, some descriptor generated from C++ headers via an AST tool that then gets used to generate Rust code)? Can there be a stack of these positions that apply to a span?
Just came across this in The Little Book of Rust Macros:
So Rust already has pretty much what I had in mind.
This should follow the syntax of this only "compiler directive" existing so far. Spaces are optional, except after setting column. I quite like the last variant for brevity and because it can't collide with an existing macro name:
meta! file {"stuff.json"}meta! line {49}meta! column {27}
set! file ("stuff.json") set! line (49) set! column (27)
_!file("stuff.json")_!line(49)_!column(27)
Either a keyword along with the numbers, or e.g. a negative number could mean to freeze it, i.e. all following code reports the same virtual location.
macro_rules is hardly prior art for compiler directives. It's more like a definition and mirrors the way normal rust definitions work (ignoring the module system implications). The fact that it's like a compiler directive is hardly the feature and more of a side effect or even implementation detail.
The sourcemap slow down would only occur in the rare cases, where a position is needed, i.e. errors, warnings and line!() / column!().
Or debuginfo generation.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.