Better error reporting

[antoyo]

That would require the ability to set positions (spans) in the proc macro and the ability to spans errors.

[antoyo]

To have that right now, I could implement something that will run when an environment variable is set. It will do the following:

• Try to compile the source code.
• If there's an error within a #[widget] attribute:
  • Generate the source code annotated by this attribute and compile it.
  • Match the errors of the generated code with the original one.
  • Show these errors instead of the one produced by the compiler.

That will be slow, but still faster that doing that by hand.

[Geobert]

This is really needed, especially for noobs like me in Rust and you get this kind of error:

error: borrowed value does not live long enough
  --> src\widgets\daywidget.rs:34:9
   |
34 | #[widget]
   | --------^
   | |       |
   | |       temporary value dropped here while still borrowed
   | temporary value created here
   |
   = note: values in a scope are dropped in the opposite order they are created

I think I'll give up on relm for the moment :(

[antoyo]

I think that I'll soon be able to fix this issue (at least on nightly) since syn was fixed.
However, I think I need this pull request to be merged, but hopefully it will happen soon.

Until then, you can enable the log when you use relm by doing:

export RUST_LOG=warn

and you'll see the generated code.
Then, you can try the generated code to have a better error but it is annoying to do that.

[Geobert]

Oh cool, I'm gonna give this a shot to see if I can understand which value causes this error :)

Thank you. And to be fair, I know the whole Rust sphere is very young and still craving its way to provide all the tools needed to make a language successful :) So kudo to you for relm, it makes gtk way less ugly to use in Rust!

[antoyo]

Oh, I've just noticed that this logging feature is only in the feature/futures-glib branch (which contains many breaking changes).
Do you want that I add it in the master branch?

[Geobert]

If the PR needed to makes thing right by managing the current ticket is merged soon, don't bother, I can wait :)

[superlou]

Looks like the pull-request was merged. Is it something we need to update on our end, or does the library need to be updated?

[antoyo]

@superlou: Unfortunately, this PR was merged with a hack, so it does not work right now.
Also, that will need to update the code to switch to proc-macro2.

[antoyo]

@zmitchell I talked to you about the idea of using (sy)nom, but I'm not sure we can use it for the whole thing.
I think we will only be able to parse the content of the view! macro with it.

[zmitchell]

I agree, I think it's the only part that it needs to be used for. I don't think I implied otherwise, did I?

[antoyo]

@zmitchell No, but I did :) .

[antoyo]

@zmitchell: I started to fix this and have some basic examples (like buttons-attribute) working.
You can see my work in branch fix/better-error (see this giant commit).
Hopefully, I'll finish the work in 2-3 weeks.

[antoyo]

Fixed by PR #90.