Real-time syntax checking (even if you're not using Bucklescript)

[jfehrle]

plugin version: 0.81

I build coq from the command line. It would be quite helpful for ReasonML to highlight some syntax errors/questionable constructs in real time. It doesn't have to be 100% comprehensive, but I find I make certain mistakes over and over due to OCaml's odd syntax for certain constructs. Better to find them while I'm editing before I start the real compile. (Maybe you already support this for Bucklescript.)

For example, fairly frequently I end up with semicolons where I should have "in" (too much Java coding, perhaps), such as the first line in the code below. The compiler unhelpfully reports the error at the beginning of the last line.

let foo = x;

let parse_color_config str =
  let styles = Terminal.parse str in
  init_tag_map styles

let dump_tags () = CString.Map.bindings !tag_map

Perhaps you could also compare indentation to the block structure (à la Python) and have the real-time parsing show squiggly red lines for errors. For example if you have cases in match or with constructs, they need to be parentheses or in begin..end--otherwise they may include subsequent (unindented) statements.

It would also be very cool to highlight places where functions are partially applied; this isn't used all that often so I frequently misread these as regular calls, especially when I'm reading someone else's code. For example:

let myfunc a b c = a+b+c

let yourfunc = myfunc 5  (* just provides the "a" argument *)

If you want to support this, let me know and I'll come up with a more complete list of troublesome OCaml syntax. Or if these examples aren't completely clear.

[giraud]

I've been reluctant to add parser errors because I'm afraid to introduce an incorrect error message on a perfectly valid file.
With bucklescript, the errors are always returned from compilation. Not possible yet with native project.

But if you have a list of really easy to spot errors, you can publish it here, maybe some of them can be implemented. For ex, the warning on partially applying parameters doesn't seem a good idea, it could cause too many false positives.

by the way, thank you for your issues, they really force me to continue working on the ocaml side of this project..

[jfehrle]

It would make sense to start with things that don't parse (assuming your parser matches the compiler's parser faithfully when it reports an error or warning). For example:

let x () =
  if true then
    dump_tags (); dump_tags ()
  else
    ()

It would be neat if the parser could usefully resynchronize after an error so it could find multiple parse errors in one pass, but just finding the first error automatically and within at most a few seconds would be a big help.

I admit, the partial-application check is a stretch. How about this?

let foo () =
  let x = 1;
  let y = 2  ...

Indentation suggests that let x = 1 should be followed by in and not ;. Here, it appears that let y = 2 should be indented less:

let foo () =
  let x = 1 in
    let y = 2 ...

Or here, the indentation suggests that bar is called in the else, which is not the case. Sometimes I get these when I add conditionals:

let x () =
  if true then
    f ()
  else
    foo (); bar ()

Other checks could look at indentation of match and try constructs and whether they are missing begin..end or (..). (One case for a construct followed by a less-indented statement, another for nested match/try-with where a | <pattern> after the inner construct is less-indented.) I can spell out in more detail if you like. These are the ones that come to mind right now. Maybe just 4-6 checks total.

On the other hand, while it would be useful and user-friendly to compare syntax against indentation, I'm not sure these examples justify spending a lot of time to implement them. What do you think?

As for false positives, I believe IJ lets you report both errors and warnings. I expect they could be user-configurable inspections. Right-clicking in the scroll bar gives you this menu:

then "Customize Highlighting Level" shows:

by the way, thank you for your issues, they really force me to continue working on the OCaml side of this project..

My pleasure. It's gratifying to see improvements after submitting issues. Frequently I don't get a response, let alone a resolution, to issues I submit to other open source projects. Also, I enjoy crafting clear and useful reports.