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

Generic ppx driver #576

Merged
9 commits merged into from Jun 5, 2018
Merged

Generic ppx driver #576

9 commits merged into from Jun 5, 2018

Conversation

ghost
Copy link

@ghost ghost commented Mar 3, 2018

This PR removes the hard-coded knowledge of ppx_driver and ocaml-migrate-parsetree and their specific details. Instead we know have this in the jbuild files of ocaml-migrate-parsetree and ppx_driver:

(library
 ((name migrate_parsetree)
  [...]
  (ppx.driver
   ((main       Migrate_parsetree.Driver.run_main)
    (flags      (--dump-ast))
    (lint_flags (--null))))))

(library
 ((name ppx_driver)
  [...]
  (ppx.driver
   ((main       Ppx_driver.standalone)
    (replaces   (ocaml-migrate-parsetree))
    (flags      (-corrected-suffix ${corrected-suffix} -diff-cmd - -dump-ast))
    (lint_flags (-corrected-suffix ${corrected-suffix} -diff-cmd - -null    ))))
  ))

This makes things a bit cleaner and in particular we no longer have to synchronise the releases of Dune and these packages when adding new features.

To test, it is necessary to use the generic-ppx-driver branch of ocaml-migrate-parsetree and ppx_driver

@ghost ghost requested a review from rgrinberg March 3, 2018 13:44
@rgrinberg
Copy link
Member

Looks good but it's a shame the error when the driver is missing is so opaque. Previously, we'd tell the user they needed to install something. It would be nice to have something more helpful than "No ppx driver found"

@ghost
Copy link
Author

ghost commented Mar 5, 2018

Indeed. Technically, we should only get this error in two cases:

  1. when the (pps ()) list is empty.
  2. when none of the listed preprocessor depends on a driver
  3. the user updated jbuilder but not ocaml-migrate-parsetree or ppx_driver

For (1), no pps should simply not be allowed. We can make the switch when we switch to Dune. For (2) maybe we can say something like: none of the listed name is a ppx rewriter.

@ghost
Copy link
Author

ghost commented Mar 5, 2018

BTW, I'm trying to think what is the best way to release this. We need to add dependency constraints on released ppx_driver and ocaml-migrate-parsetree packages, but then we have the choice between:

option1:

  • releasing jbuilder beta19
  • releasing new versions of ppx_driver and ocaml-migrate-parsetree

and in between, users won't be able to upgrade to jbuilder beta19

option 2:

  • releasing jbuilder beta19 that only accept the new ppx.driver field but ignores it
  • releasing a version of ppx_driver and ocaml-migrate-parsetree with the updated jbuild files
  • releasing jbuilder beta20 with this PR in

@rgrinberg
Copy link
Member

I think option #1 is doable if we batch together the releases of jbuilder, omp, and driver. But we'd also like to avoid delaying beta19 as it contains some important fixes. So unless those other releases are imminent, I'd favour #2.

@ghost
Copy link
Author

ghost commented Mar 5, 2018

Yh, the other releases are ready

@ghost
Copy link
Author

ghost commented Mar 5, 2018

But maybe 2 is better anyway. For instance the latest ppx_driver is not compatible with older version of OCaml so we will need multiple minor releases of ppx_driver.

@rgrinberg
Copy link
Member

Let's go with #2 then

| None ->
Error (Loc.exnf loc "%S is not an %s" name
(desc ~plural:false))
| Some t -> Ok t))
Copy link
Member

Choose a reason for hiding this comment

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

Would it be possible to move these changes into their own PR if possible?

Copy link
Author

Choose a reason for hiding this comment

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

Ok, I'll cherry-pick directly some of the simpler commit to master directly, since we can't create dependent PRs on github

Copy link
Author

Choose a reason for hiding this comment

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

Done: #632

@rgrinberg
Copy link
Member

@diml what's the status of this? You think you'll have enough time to polish this for the next release?

@ghost
Copy link
Author

ghost commented Apr 18, 2018

I improved the error messages, now it suggests to upgrade ocaml-migrate-parsetree, ppxlib or ppx_driver if the pps depend on them. Otherwise it suggests that they are not compatible with jbuilder.

@ghost
Copy link
Author

ghost commented Apr 18, 2018

But we need to wait for a new version of ppxlib

@ghost ghost mentioned this pull request Apr 23, 2018
@ghost
Copy link
Author

ghost commented May 15, 2018

The recent problems we had with ppx_sexp_conv makes me think that this is going to cause more pain than I expected. I think I will change this feature so that the new behavior is only activated in dune projects. This way nothing will change for existing released projects.

@ghost ghost added this to the 1.0.0 milestone Jun 2, 2018
@ghost ghost mentioned this pull request Jun 2, 2018
4 tasks
@ghost ghost self-assigned this Jun 2, 2018
@ghost
Copy link
Author

ghost commented Jun 2, 2018

I added a commit on top of the previous changes to restore the old behavior when the file is a jbuild file. To know if the file is a jbuild file, we pass a dir_kind value around that is either Dune or Jbuild. The old ppx drivers are stored in _build/default/.ppx/jbuild.

The code is not exactly the same as what we had before, but it should work for all existing projects.

We shouldn't need to do anything special for the next release. Existing projects will continue to work, and if there is an issue with a pure dune project because ppxlib or omp was reinstalled, Dune prints an error message inviting the user to reinstall omp or ppxlib.

@rgrinberg could you review the last changes? I think this is now safe to merge.

match Preprocessing.get_ppx_driver sctx ~scope ~dir_kind pps with
| Ok x -> [x]
| Error _ ->
[Preprocessing.get_ppx_driver_for_public_lib sctx ~name ~dir_kind]
Copy link
Member

Choose a reason for hiding this comment

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

Could you explain this bit? What kind of errors are we ignoring here?

Copy link
Author

Choose a reason for hiding this comment

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

Looking at the code again, I believe the only possible failure is if ppxlib.runner or ppx_driver.runner doesn't exist. This might be the case at some point in the future and this code is not very clear anyway. I reworked it to make things more explicit and avoid the error case here.

@rgrinberg
Copy link
Member

Those last (recent) commits look good. Btw, how would this work for mixed setups with both dune and jbuild files? So we're not going to be able to use both the new and old drivers in the same workspace?

@ghost
Copy link
Author

ghost commented Jun 4, 2018

It should work fine. Basically when we are in a jbuild directory, the new driver stuff is not used at all and we still use the hardcoded values. The old drivers are built in a separate directory .ppx/jbuild, so it should be possible to use both method without issues.

@ghost
Copy link
Author

ghost commented Jun 4, 2018

I changed the message in case of error to:

No ppx driver found.
It seems that these ppx rewriters are not compatible with jbuilder.
It seems that these ppx rewriters are not compatible with Dune.
Hint: Examples of ppx rewriters that are compatible with Dune are
ones using ocaml-migrate-parsetree, ppxlib or ppx_driver.

Jeremie Dimino and others added 6 commits June 4, 2018 16:26
- remove hard-coded knowledge of ocaml-migrate-parsetree and ppx_driver
- get the exact driver parameters directly from the driver itself

Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
I just spent an hour debugging a stupid bug caused by this...

Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
@@ -203,7 +203,9 @@ let no_driver_error pps =
| None ->
sprintf
"No ppx driver found.\n\
It seems that these ppx rewriters are not compatible with jbuilder."
It seems that these ppx rewriters are not compatible with Dune.\n\
Copy link
Member

Choose a reason for hiding this comment

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

Rather than "these", should we just include the pps here in the error message (which also has locs)

Copy link
Author

Choose a reason for hiding this comment

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

Indeed. We don't always have the location at this point because we might reach this program point when generating the rules for _build/default/.ppx/<key>/ppx.exe.

I'm refactoring a bit this code because it's becoming messy.

@ghost
Copy link
Author

ghost commented Jun 5, 2018

I improved the error messages and added tests.

Signed-off-by: Jeremie Dimino <jdimino@janestreet.com>
@ghost ghost merged commit ec6ca4b into ocaml:master Jun 5, 2018
@ghost
Copy link
Author

ghost commented Jun 5, 2018

I'm glad to have finished this one!

This pull request was closed.
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.

2 participants