Better error messages

[dsawardekar]

The #11 issue got me thinking about error messages. In it's current state the compiler works quite well. But as I've started to explore a bit more I am seeing syntax errors that don't quite reflect the cause correctly.

One low hanging fruit I can think of is, reporting the file and line number that the error originated in. A good example of this is the Clang compiler. Here's a sample error message with an invalid printf.

format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument
    printf("%.*d")
              ^

To start with, the error shown in #11 could be reported as something like,

hello.riml:2:4: error: parse error on value "end" (END)

Another small improvement would be to hide the stacktrace by default. The ruby stacktrace doesn't convey anything meaningful to the user, and will give new users a wrong initial impression, One that doesn't really reflect the actual state of the compiler. A stacktrace like that suggests something broke in the compiler even when that isn't the case.

A --verbose or --debug flag could enable the stacktrace for debugging purposes.

For further reading, Clang Expressive Diagnostics

[luke-gru]

I totally agree with you on every point 👍 I'll create a branch and start working on these issues.

[dsawardekar]

Hey @luke-gru, I've noticed some improved error reporting in 0.3.6. Can you clarify the format you are using to do this? I have done some initial work in riml.vim on a syntastic plugin, but it's very experimental at the moment. If your error formats are working I can fix up the plugin to better highlight syntax errors.

[luke-gru]

Hey @dsawardekar, sorry for the long delay. Been super busy 😄

I've just pushed a new release, 0.3.8. Since 0.3.7, there has been a new format for error messages. The format is like this https://github.com/luke-gru/riml/blob/master/lib/riml/errors.rb#L11

Riml::ParserError
location: /full/path/to/file.riml:100
message: single or multi-line error message

If the location can't be deteremined, it outputs location: <unknown> on the second line. This should be rare, and I would consider it a bug if you encounter it.

There is a debug flag now for riml, it's --debug or -D. In this case, the full stacktrace is shown.

The error messages are still a work in progress, so I'll keep this ticket open for now.

Thanks again!

[dsawardekar]

@luke-gru Np, I've been a bit busy and haven't followed up with this. This error format looks good, I'll try to incorporate it into the syntastic plugin.

[dsawardekar]

Hey Luke,

Happy 2014! I'll be getting back to this in the next few days. Will report back if I find any pesky stacktraces. 😄

[luke-gru]

Hey @dsawardekar, happy new year to you too!

Let me know if you need any help while you're working on this. Also, I just released a new version, 0.3.9 today. The main changes are that the compiles are faster and there's a new feature called 'splat arguments', that works like Ruby's splatting in a function call context, so for instance:

args = ['arg1', 'arg2']
some_func(*args)

is equivalent to:

some_func('arg1', 'arg2')

Thanks!

[dsawardekar]

@luke-gru I've upgraded most of my stuff to 0.3.9. Every thing looks ok. The syntastic plugin api appears to have changed, riml.vim's syntax checker is currently broken as a result. Need to rethink some of my assumptions.

The splats syntax look handy, but the generated code is a bit involved. Could it be moved to a call call invocation? Something like below,

function! Some_Func(...)
  echomsg string(a:000)
endfunction

let args = ['a', 'b']
call call('Some_Func', args)

[luke-gru]

@dsawardekar I agree the generated code is not ideal, I was wondering what the best way to do it would be. That looks much easier! I'll make the change some time this week for sure.

Thanks!

[dsawardekar]

@luke-gru I took another look at the Syntax checker. Vim's errorformat needs to match a %f against a filename to work. Currently the compiler errors don't include the filename in the returned error. Can you add a file line to the output?

Riml::ParseError
file: lib/foo.riml
location: <String>:3
message: parse error on value "\n" (NEWLINE)

Currently for the following code,

class Foo
  defm foo(
  end
end

The error output is,

Riml::ParseError
location: <String>:3
message: parse error on value "\n" (NEWLINE)

[luke-gru]

Hi @dsawardekar, sorry for the delay on this issue.

I'll have time from no on to dedicate more time to this project. Are you compiling this from the commandline, or are you using the Ruby API (Riml.compile)?

Thanks,

[dsawardekar]

Now worries @luke-gru. As much as I like Vim, it doesn't put food on the plate. 😄

I'm using the the command line in this case, so basically a riml -c. Not sure if it makes any difference but the riml executable is called by syntastic.

[luke-gru]

Hey @dsawardekar, I can't reproduce the error for some reason.

I put the code (class Foo ...) in a file called test.riml and ran the command riml -c test.riml, and got this output:

Riml::ParseError
location: test.riml:3
message: parse error on value "\n" (NEWLINE)

I get this for versions 0.3.9 and the newly released 0.4.0 (:tada:). Can you try this again?

Also, in 0.4.0, your suggestion for using call('function_name', args_list) is in the release, so there's no more of that awkward code generation, and it makes the rewriter much easier to understand! 👍 Thanks!

[dsawardekar]

That's odd I can't reproduce this anymore, I'll investigate further. 0.4.0 looks really good, I have some upgrading to do! 😄