lwt.ppx reports incorrect locations

[copy]

This causes problems with merlin, for example MerlinTypeOf fails in the below example on the second let statement.

let _ =
  let%lwt a = Lwt.return 5 in
  let b = 6 in
  Lwt.return_unit

See https://github.com/ocaml/merlin/issues/633.

[let-def]

(If you have questions, I can provide some help to improve compatibility).

[Drup]

@let-def IIUC, the problem is not that the locations are wrongly located, but that some of them should be marked as ghost ?

[let-def]

(we talked on IRC, I summarize here)
@Drup Merlin no longer uses loc_ghost as this wasn't reliable.
The problem here is that, in the code provided as an example (see below), the pattern that binds the right-hand-side of a binding (of type int Lwt.t) is given a location that spans the whole expression. Merlin find this node and thinks it is the correct answer for anything between let%lwt and the end of the expression.

let _ =
  let%lwt a = Lwt.return 5 in
  let b = 6 in
  Lwt.return_unit

[Khady]

I have created a bounty for this issue https://www.bountysource.com/issues/43966981-lwt-ppx-reports-incorrect-locations

[Armael]

I'm not sure I understand @let-def's explanation.

On a slightly simpler example:

let _ =
  let%lwt x = Lwt.return 5 in Lwt.return 10

is expanded by the ppx to:

let _ =
  let __ppx_lwt_0 = Lwt.return 5  in
  Lwt.backtrace_bind (fun exn  -> try raise exn with | exn -> exn)
    __ppx_lwt_0 (fun x  -> Lwt.return 10)

In the generated code, what would be the expected locations for the __ppx_lwt_0 pattern, and for Lwt.backtrace_bind (fun exn -> try raise exn with | exn -> exn) __ppx_lwt_0?

[aantron]

Btw now that there is a bounty, if anyone (@Armael?) wants to work on this, please claim it explicitly. This is for the benefit of not disappointing anyone else who might start working.

[aantron]

...aaand I added $100 https://www.bountysource.com/issues/43966981-lwt-ppx-reports-incorrect-locations/backers.

Again, please claim if you want to work on this, to prevent any disappointments for others :)

[Armael]

I'm a bit uneasy about this. I just started looking into this issue out of curiosity; I now have basic understanding of the PPX (as many others I assume), and would be happy to work on a fix, but I will probably need input from @let-def and/or @Drup for that.

So yea, if someone else knows how to fix this, please do so and claim the bounty; my current (non-)understanding on this problem is summed up in my previous post.

[aantron]

Alright, thanks for letting us know @Armael. I'll advertise this issue and bounty. You're still welcome to claim it, perhaps at a later time if nobody else has?

This bounty thing is basically an experiment for me (and I think @Khady) at this point. Community and success of the project are still the most important things. I will offer a normal level of help to contributors, even if this issue has money attached now. So it's actually not a bad issue for a new-ish contributor, as long as they can be reasonably effective working on a PPX and investigating locations semi-independently.

[copy]

I'm looking into this issue, I think I have an idea how to fix it.

[Khady]

BTW, it might be possible to look at ppx_let (IIRC the name) from janestreet that provides the same kind of syntax but without the location problem in my experience.

Would be nice to check the locations not only for the let but also for match/try/finally

[copy]

Would be nice to check the locations not only for the let but also for match/try/finally

I checked these and fixed another minor issue.