Open hansihe opened 5 years ago
Code isn't pushed just yet
If the -file
directive maps directly to the file used in the Line chunk for the BEAM byte code line
opcode, then the -file
needs to be used at runtime also. It is how EEx templates in Phoenix report the error coming from the *.html.eex
file instead of the View module's file even though the EEx generated function is put into the View module.
Yeah, that sounds about right. That is more or less what I mean when I say it has to be referenced when generating debug info for the runtime
Here's an example of the PageView module for a template Phoenix project.
defmodule EExTestWeb.PageView do
use EExTestWeb, :view
end
A productive web framework that
does not compromise speed and maintainability.
A productive web framework that
does not compromise speed and maintainability.
line
expandedA productive web framework that
does not compromise speed and maintainability.
It's not just the debug-info (i.e. Dbgi
chunk). The stacktrace needs to also reference the .eex
files. Unless you're going to have the stacktrace support read the debug-info.
I am not really using BEAM terminology here, by debug info I mean everything used at runtime used to refer back to originating source code.
This issue is really more about internal implementation than that stuff though.
So for stepping through code, we'll want to reference the actual source spans when generating debug info (i.e. DWARF). We always want to ignore -file
there.
However, for compilation and runtime stacktraces/metadata, we'll want to use whatever is provided by the -file
directive, since as pointed out, this is used intentionally to provide source errors in a way more useful to users of some module/header. In Erlang this is primarily used in -include
'd files so that errors point to the included header, not the source file doing the including. In Elixir, this is used in situations like the one @KronicDeth shared, i.e. with macros, to make sure that location information points users to their own module rather than whatever module the macro came from.
As for how to store these diagnostics, I agree that we need a way to store both, but don't have a specific implementation in mind. Ideally we could access both from a single span, but that is probably overly expensive in the general case, since only a subset of code will have overridden source positions.
That said, might make sense to store both initially, and worry about optimizing it later.
The 'file' compiler directive is often used in generated code to specify a location in an origin file where the code was generated from. This needs to interact properly with diagnostics.
I'm thinking the best way of doing things would be to show compiler errors in the actual file, but display runtime errors in the origin file.
Unless you already had an implementation in mind, I think a decent way of doing things would be to store source span => origin file line mappings in an auxiliary data structure outside of the diagnostics itself, and reference that when generating debug information for the runtime.
Thoughts @bitwalker?
I implemented a stub implementation in
preprocessor.rs
in order to get code compiling.