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

Implement source maps support to locate JavaScript errors in code blocks #93

Open
tslocke opened this issue Jun 18, 2012 · 10 comments
Open

Comments

@tslocke
Copy link

tslocke commented Jun 18, 2012

For example:

$ pegjs syntax.pegjs 
Unexpected token |
@dignifiedquire
Copy link

👍

@dmajda
Copy link
Contributor

dmajda commented Apr 20, 2014

The line numbers would be nice to have but I won't spend time on this before 1.0.0. Patches welcome.

@dmajda dmajda modified the milestones: post-1.0, 0.9 Apr 20, 2014
@Mingun
Copy link
Contributor

Mingun commented Apr 20, 2014

I realize this in #225.

@dmajda
Copy link
Contributor

dmajda commented Apr 26, 2014

I realize this in #225.

I don't think so. This issue is about JavaScript syntax errors in actions/predicates/initializer. These currently cause SyntaxError without any positioning information to be thrown when generated parser source code is evaluated.

This was somewhat more important in the past (when this issue was reported) because PEG.buildParser and bin/pegjs did this evaluation, so you got an error in anonymous eval'd code when generating the parser. Now they don't evaluate (unless you set the output option to "parser" in case of PEG.buildParser), so the SyntaxError pops up when the parser is used, which means you are usually pointed to the exact location in generated code by node or the browser. What should happen however is that you are pointed to a location in the original .pegjs file. This should be solvable by implementing source maps support.

@dmajda dmajda changed the title Syntax errors in JavaScript blocks do not provide a line number JavaScript syntax errors in code blocks are missing a line number Aug 14, 2015
@StoneCypher
Copy link

👍

@StoneCypher
Copy link

I hit this for the first time yesterday. It was rough sorting out how to fix it, and the error I got, while correct, was deeply counter-intuitive.

I had intended to write { term: 'whatever', value, location: location() } as the rule. Instead, I wrote { term: 'whatever', value, location() } (the location key is missing,) and received as an error Unexpected token }.

Strictly speaking that's correct, but I went off on a fruitless search for aberrant close-braces. I ended up finding it with a differ ☹️

With a line number, this would have been trivial. Pls halp ❤️

@futagoza futagoza changed the title JavaScript syntax errors in code blocks are missing a line number Implement source maps support to locate JavaScript errors in code blocks Nov 3, 2017
@futagoza
Copy link
Member

futagoza commented Nov 3, 2017

I'll look into this after 0.11, but as I haven't done much with source maps before (which is the only way to track error's like this), I can't guarantee a date or version. In the meantime, if anyone is inclined to, they're welcome to send a PR for this 😄

@michael-brade
Copy link

Yes! I just started working with source maps since they are broken in LiveScript. And now I'm missing them in pegjs 😄

A popular lib for implementation: https://github.com/mozilla/source-map and a tutorial: https://hacks.mozilla.org/2013/05/compiling-to-javascript-and-debugging-with-source-maps/

Here is a nice tool to help during development: http://sokra.github.io/source-map-visualization/
And for quick usage: https://github.com/lydell/source-map-visualize

@deostroll
Copy link

👍

Would want source maps not just for stacktrace, but also debugging in, say, vs code or chrome dev tools...since I write my initialization logic separately (in another file) and concat them before parser build.

@StoneCypher
Copy link

I like the idea of sourcemaps.

While we wait, if you actually need them, there's an easy way to get them: parse your handlers in something that does sourcemaps, like typescript, then staple it to the front with string editing as if it was a peg preamble, then do a tiny amount of offset math to find the corrected location

That's super ugly and hacky, but it's also durable and something you can do in an hour until this is done properly

Also, I'm looking at my 2017 comment, and I realize in retrospect that for what I was doing, there was a much easier solution: the handlers should have been enforcing the things I was trying to trace with exceptions. I was just not javascripting effectively at that time.

I have no idea how sourcemaps actually work, so I have no opinions on proper implementation.

dmajda was wrong to cite i don't want your code at @Mingun . That is the same thing Mingun is doing to me, now, in trying to resurrect the library.

The library has needs, the userbase has needs, and we're more interested in our personal intent than solving those needs.

That's why in 2020 the es() function that allows use by packagers, compilers, and transcompilers, which was added in 2017, still hasn't been released.

Because two maintainers "didn't want the code."

It's time for a maintainer that does want the code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants