Skip to content
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

error locations and IDE diagnostics support #885

Open
OmarTawfik opened this issue Dec 21, 2023 · 4 comments
Open

error locations and IDE diagnostics support #885

OmarTawfik opened this issue Dec 21, 2023 · 4 comments

Comments

@OmarTawfik
Copy link

OmarTawfik commented Dec 21, 2023

Thank you for the awesome crate. I have been slowly integrating it in a few projects, and it is proving to be incredibly useful.

However, one thing that we are struggling with as this scales up is debugging errors when a variable/functios is renamed or removed. Our solution right now is to panic!("{tera_error}"), rerun the build in CLI, and read through the build logs.

It would be great if we can thread these diagnostics to the editor directly. For example, projects can easily print these errors information (message, file, line, column) on stdout, and VS Code will pick it up and render it diagnostics/squiggly lines. Large projects often define multiple matchers for different frameworks they are using:

image

But unfortunately doing so for Tera (like the example above) is proving to be difficult, since there is no consistent output format for these errors, and not all of them include the relevant information. I wonder if this is something that can be added/supported in Tera, so that users can propagate it correctly?

For example, file/range information can be added to tera::Error:

#[derive(Debug)]
pub struct Error {
    pub kind: ErrorKind,

    pub file: Option<PathBuf>,
    pub range: Option<Range<LineColumn>>,

    source: Option<Box<dyn StdError + Sync + Send>>,
}

Thank you!

@Keats
Copy link
Owner

Keats commented Dec 21, 2023

That's coming in v2! Have a look at an error: https://github.com/Keats/tera2/blob/master/src/tests/snapshots/tera__tests__rendering__rendering_errors%40unknown_var.html.snap.
Can VSCode read that file/line/col format? I can change it

@OmarTawfik
Copy link
Author

Great news! thank you!
What is the timeline for a beta/preview release of v2?

re: the format: VS Code matchers are just regex with capture groups. So, I think we have two options here:

  1. Have an output format that is really easy to parse, for example, all the above values joined by a common separator (:):
// A problem matcher definition in VS Code:

{
  "fileLocation": ["relative", "${workspaceFolder}"],
  "pattern": {
    // foo/bar.jinja2:10:1:10:22:error:Failed to parse this expression.’
    "regexp": "^([^:]+):([^:]+):([^:]+):([^:]+):([^:]+):([^:]+):(.+)$",
    "file": 1,
    "line": 2,
    "column": 3,
    "endLine": 4,
    "endColumn": 5,
    "severity": 6,
    "message": 7,
  }
}
  1. Or the more configurable/extensible option, exposing these properties on the error types returned, and the user can format/print it however they think is useful. So that Tera doesn't need to be forced to support a specific format, or worry about breaking it in the future.

@Keats
Copy link
Owner

Keats commented Dec 21, 2023

What is the timeline for a beta/preview release of v2?

No timeline yet. I'll try to add functions/tests/filters soon so people can try with some real templates but can't say when I will have time

@OmarTawfik
Copy link
Author

Thank you for your efforts!

github-merge-queue bot pushed a commit to NomicFoundation/slang that referenced this issue May 14, 2024
Closes #863

- The entirety of "runtime" codegen is now following a strict MVC model,
and the source code is rendered from the same model object. We should be
able to further improve/refactor this model object in #638
- Complex model construction can be strongly-typed in Rust, while
rendering is left to templates, as they are much easier to read and
modify, and also have powerful macros/imports/callbacks, etc...
- I also (partially) improved the DX when working with templates in
terminal, by rendering their errors as an `ariadne` report, with
best-guess source location in the template. A temporary workaround
waiting for Keats/tera#885
- Now both stubs and output crates are rendered from the same source
templates, removing a few internal hacks and the need for
`![allow(dead_code)]` and `![allow(unused)]` everywhere (will follow up
on this cleanup separately).
- We no longer have to maintain explicit paths and copy files around in
the code generator. All templates generate their output file relative to
their location, which means we can split and refactor code into as many
templates/sub-modules as needed, following standard rust idioms.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants