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

WIP: Use new parser API #4

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

WIP: Use new parser API #4

wants to merge 6 commits into from

Conversation

c42f
Copy link
Member

@c42f c42f commented Apr 21, 2020

These changes allow CSTParser to be connected up as the main Julia parser.

To use it, you currently need both a branch of the Julia runtime and of CSTParser:

Then run FancyDiagnostics.enable!(), and we can have errors such as:

asciicast

Dev notes

Early screenshot:

sshot_1

Note that the current implementation is pretty rough and diagnostic printing will still crash at the drop of a hat (I still need to understand how CSTParser uses ErrorToken a lot better and figure how to cleanly deal with offsets at EOF which are very common)

TODO:

  • Better understand how ErrorToken is used to encode the span, and what the deal is with nested error tokens.
  • Make handling errors at EOF actually work
  • Detect incomplete expressions and return Expr(:incomplete)
  • Much better error messages. The above example is not really representative in that CSTParser has only a handful of very generic error states. (Perhaps the CST itself will provide the context for more useful messages, or perhaps we'll need to put messages back into CSTParser itself.)

else
string(chars[1], chars[2]^(width-2), chars[3])
end
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are probably aware but I'll mention there is printstyled(io, str, color=:underline)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that's an interesting option - perhaps worth doing, especially for multi-line errors. We could use underline, red,bold or some other styling. (It's even an option to have syntax highlighting combined with error reporting - Tokenize + CSTParser gives us more than enough tooling for that.)

The thing which I find nice about the box chars is that they work in black and white, and they can be colored separately from the source code. But the need to format multi-line errors may override that consideration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you can see in the screencast, I've tried in-situ highlighting in the latest version which is an easier option when the error spans multiple lines.

c42f added 2 commits May 3, 2020 07:38
Hightlight errors in situ, rather that with separate text.

This won't work well without ANSI highlighting.
@c42f c42f changed the title Very WIP: Use new parser API WIP: Use new parser API May 4, 2020
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

Successfully merging this pull request may close these issues.

None yet

2 participants