-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle file
directive correctly
#18
Comments
Code isn't pushed just yet |
If the |
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. View Module
EEx Template
Expanded Byte Code
BEAM Bytecode without
|
It's not just the debug-info (i.e. |
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 However, for compilation and runtime stacktraces/metadata, we'll want to use whatever is provided by the 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.The text was updated successfully, but these errors were encountered: