Git Product home page Git Product logo

ocaml-migrate-parsetree's People

Contributors

aantron avatar adrieng avatar bryphe avatar ceastlund avatar djs55 avatar dra27 avatar hhugo avatar jeremiedimino avatar jonludlam avatar kit-ty-kate avatar let-def avatar nathanreb avatar pitag-ha avatar rgrinberg avatar vbmithr avatar xclerc avatar yomimono avatar yunxing avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ocaml-migrate-parsetree's Issues

support for upcoming OCaml 4.10 ?

As of this week, the versions of ocaml-migrate-parsetree available on opam are incompatible (or at least marked incompatible) with the upcoming 4.10 release. Would it be possible to ensure compatibility with the current 4.10 branch, and have a version available on opam that enables it, or at least a clear reference to pin? This would unlock testing of user code when we make our first beta releases (expected in a few weeks).

(We do not expect to change the parsetree now that the release branch has been created, but there is a small chance that it could happen, for example thanks to m-o-p dogfooding the changes and suggesting fixes. I still think having an opam release is nicer than pinning, especially for people doing release Q/A with opam testing tools.)

Thanks!

example ppx rewriter not compatible with dune "No ppx driver were found" error

I've tried to use the examples in examples/omp_ppx_here/ to build my own ppx rewriter.
However after a make install in this directory, I tried to use the ppx in one of my project using dune
with
(preprocess (pps omp_ppx_here))

but then I got the following error:
ile "matching/dune", line 4, characters 13-31:
4 | (preprocess (pps omp_ppx_here))
^^^^^^^^^^^^^^^^^^
Error: No ppx driver were found. It seems that omp_ppx_here is not compatible
with Dune. Examples of ppx rewriters that are compatible with Dune are ones
using ocaml-migrate-parsetree, ppxlib or ppx_driver.
Makefile:3: recipe for target 'all' failed

What do I need to get omp_ppx_here usable from dune?

failures in ppx_deriving after upgrade from 1.5.0 to 1.6.0

ocaml-migrate-parsetree was upgraded from v1.5.0 to v1.6.0. All packages which depend on this package were rebuilt automatically. For some reason ocaml-ppx_deriving now fails to build. It runs ppxfind -legacy, which is now "suddenly" an unknown cmdline option.

I reverted back to v1.5.0 get the prj devel:languages:ocaml back into state succeeded. The build log of ppx_deriving indicates ppxfind -legacy is working, Not sure how migrate-parsetree influences the behavior of ppx_deriving

Issues about ocamlbuild plugin

First of all it should be

    let () =
      Ocamlbuild_plugin.dispatch (fun hook ->
        Migrate_parsetree_ocamlbuild.dispatch hook;
        <other dispatch functions>
  )

and not

    let () =
      Ocamlbuild_plugin.dispatch (fun hook ->
        Ocaml_migrate_parsetree_ocamlbuild.dispatch hook;
        <other dispatch functions>
      )

After fixing this I compile files and get error like this:

➜  threads_test git:(master) ✗ make
PATH=`pwd`/../../src/:$PATH OCAMLPATH=`pwd`/../../lib/_build/bundle \
ocamlbuild -use-ocamlfind -plugin-tag "package(ocaml-migrate-parsetree-ocamlbuild)" src/moc_controller.c src/qrc_resources.c src/libcppstubs.a src/program.native
Finished, 1 target (0 cached) in 00:00:00.
+ ocamlfind ocamlc -g -thread -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtQuick -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtQml -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtGui -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtCore -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -cc g++ -ccopt '-std=c++0x' -ccopt -fPIC -ccopt '-Dprotected=public' -package lablqml -ccopt -I. -c src/controller_c.c
findlib: [WARNING] Package lablqml has multiple definitions in /home/kakadu/prog/lablqml-bluddy/demos/threads_test/../../lib/_build/bundle/lablqml/META, /home/kakadu/.opam/4.04.0+fp+flambda/lib/lablqml/META
+ ocamlfind ocamlc -g -thread -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtQuick -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtQml -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtGui -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -ccopt -I/usr/include/x86_64-linux-gnu/qt5/QtCore -ccopt -I/usr/include/x86_64-linux-gnu/qt5 -cc g++ -ccopt '-std=c++0x' -ccopt -fPIC -ccopt '-Dprotected=public' -package lablqml -ccopt -I. -c src/moc_controller.c
findlib: [WARNING] Package lablqml has multiple definitions in /home/kakadu/prog/lablqml-bluddy/demos/threads_test/../../lib/_build/bundle/lablqml/META, /home/kakadu/.opam/4.04.0+fp+flambda/lib/lablqml/META
+ ocamlfind ocamlopt -predicates ppx_driver -linkpkg -o omp-driver-lablqml.ppx.native -package lablqml.ppx driver-main/migrate_parsetree_driver_main.cmxa
findlib: [WARNING] Package lablqml has multiple definitions in /home/kakadu/prog/lablqml-bluddy/demos/threads_test/../../lib/_build/bundle/lablqml/META, /home/kakadu/.opam/4.04.0+fp+flambda/lib/lablqml/META
File "_none_", line 1:
Error: Cannot find file driver-main/migrate_parsetree_driver_main.cmxa
Command exited with code 2.
Compilation unsuccessful after building 9 targets (0 cached) in 00:00:01.
Makefile:11: ошибка выполнения рецепта для цели «all»
make: *** [all] Ошибка 10

My META file is probably wrong but I don't know where is a right template

➜  threads_test git:(master) ✗ OCAMLPATH=`pwd`/../../lib/_build/bundle cat `ocamlfind query lablqml`/META
version = "0.4"
description = "wrappers for QML objects"
exists_if = "lablqml.cmxa"
requires = "threads"

archive(byte) = "lablqml.cma"
archive(byte, plugin) = "lablqml.cma"
archive(native) = "lablqml.cmxa"

package "ppx" (
  ppx = "ppx_qt"
)

gencopy fails to build on OCaml 4.13.1

+ dune build -j48
File "tools/gencopy.ml", line 79, characters 43-74:
79 |     Pat.construct ?loc ?attrs (lid ?loc s) (may_tuple ?loc Pat.tuple args)
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: This expression has type Parsetree.pattern option
       but an expression was expected of type
         (str list * Parsetree.pattern) option
       Type Parsetree.pattern is not compatible with type
         str list * Parsetree.pattern 

Use ocaml-compiler-libs package

Currently when importing ocaml-migrate-parsetree all the packages under compilerlibs.common are added to the environment, this is problematic when there is copies of OCaml code, because now the error messages are always Types/1.signature not Types/2.signature, using ocaml-compiler-libs solves that.

If no one is against this I will implement it in the following days.

[feature request] support migration of `types.mli`

Dear OMP developers,

the ppx_import rewriter user the types.mli module from OCaml. Thus, in order to port it to OMP (ocaml-ppx/ppx_import#27 ) it would be great if OMP would include this module in the supported set.

IMHO this module is not too big and could prove useful for other rewriters. I could develop a compat machinery for ppx_import, but IMHO it seems like pointless duplication as OMP already has all the required meta-support.

Thanks!

Fix parse_argv usage

This was just merged in #82. However, the new code is not quite correct:

  1. parse_argv raises exceptions instead of internally executing exit.
  2. parse_argv should be called with ~current:(ref 0).

Perhaps the right way to do this is to restore the former signature of run_main, and leave it as the function that calls exit, and provide a new function run_main_with_argv that will take an argv argument and raise exceptions. I actually would prefer run_main_with_argv not call exit, because that allows linking a PPX directly into a test suite, which improves testing performance.

Another option is to leave run_main with ?argv, but it will be have differently, depending on whether ~argv is supplied: if not supplied, run_main will call exit, and if supplied, it will raise exceptions. This could be surprising to users of the API, however.

@diml, what do you think about the last two paragraphs?

I'll be happy to submit a PR, considering your preference.

4.06.0+rc1 support

Running make test with 4.06.0+rc1 fails with:

    ocamldep test/driver/ppx-user/foo.depends.ocamldep-output (exit 2)
(cd _build/default && /home/edwin/.opam/4.06.0+rc1/bin/ocamldep.opt -modules test/driver/ppx-user/foo.pp.ml) > _build/default/test/driver/ppx-user/foo.depends.ocamldep-output
>> Fatal error: OCaml and preprocessor have incompatible versions
Fatal error: exception Misc.Fatal_error
Makefile:27: recipe for target 'test' failed

This is likely due to the change in magic numbers mentioned in the 4.06.0+rc1 announcement: https://github.com/ocaml/ocaml/pull/1402/files

Circular dependency problem with OPAM on Travis

Hello !

I ran into a bit of a problem yesterday while CI'ing a project on Travis. See: ocaml/opam#3213. OPAM is failing on the last installable step complaining about a circular dependency between OMP and jbuilder.

Interestingly I could not reproduce the problem locally. Did you guys run into something similar ?

I've cross-posted than issue on dune ocaml/dune#492 for good measure.

x

Ability to read any version of AST

It would be useful for Bisect_ppx compiled on any OCaml version, to be able to read and write ASTs produced by any other OCaml version.

I think this is a sort of dual of current OMP functionality.

The context is that Bisect_ppx is now ported to BuckleScript, but during installation, BuckleScript is an NPM peer dependency of Bisect_ppx. This means that we can't guarantee that BuckleScript is installed first, so we can't detect its OCaml version number and use it for compiling the Bisect PPX with the same OCaml compiler. The current workaround for this is to constrain both the BuckleScript version and the OCaml version very specifically.

Ideally, we could generate one PPX, no matter which compiler compiled it, that can read any AST that is so far supported by OMP.

Unknown OCaml version 4.13.0+dev0-2020-10-19

I am trying to build ocaml-migrate-parsetree-2.1.0 with upstream OCaml (https://github.com/ocaml/ocaml/archive/trunk.tar.gz) for https://github.com/ocaml-bench/sandmark, and it fails with:

 ocaml src/ast-version (exit 1)
(cd _build/default/src && /home/guest/testing/sandmark/_opam/4.13.0+trunk/bin/ocaml config/gen.ml 4.13.0+dev0-2020-10-19)
Unknown OCaml version 4.13.0+dev0-2020-10-19

It builds fine for https://github.com/ocaml/ocaml/archive/4.12.0.tar.gz.
How can this be fixed?

Support for OCaml 4.06 features in previous versions.

It is unclear to me how to properly port some features missing from older Asts.

In <4.06, module type substitutions only took simple identifiers as path.
4.06 supports qualified identifiers, replacing a simple string by a Longident in the Ast.

In a first attempt to port, I chose to parse/print Longidents:

(copy_loc Longident.parse x0.From.Parsetree.ptype_name,

((copy_loc (fun x -> String.concat "." (Longident.flatten x)) x0),

Thinking twice the correct behavior is probably to match on the Longident.Lident case and throw unsupported feature exceptions for other cases.
I will implement this too, but I would be happy to have some feedback before releasing.

Compatibility with Pprintast

I would like to use Pprintast.core_type to stringify a core type. However, it looks like I cannot do this because of the incompatibility between ocaml-migrate-parsetree's Parsetree and the compiler-libs' Parsetree. From what I can tell, either ocaml-migrate-parsetree should implement Pprintast. Or is there another way to do this? Relevant code is here:

let string_of_core_type ( typ : Migrate_parsetree.OCaml_404.Ast.Parsetree.core_type ) =
  (* TODO: fix *)
  Format.asprintf "%a" Pprintast.core_type { typ with ptyp_attributes = [] }

Unrelated: where is OCaml_OCAML_VERSION defined?

Parsetree.effect_constructor missing build failure...

I have OMP installed via opam under 4.06.1
but I'm getting the "I can't decide ...." error when trying to use core so I went to compile the OMP source in order then to make the necessary adjustment (I cannot upgrade).
but I'm getting a an error as per the title.
I looked in ocaml 4.07 sources for that and it isn't even there!
this is confusing. anyone know what's going on?
thanks

ocaml-migrate-parsetree.1.7.1 breaks any program using Option

It appears that ocaml-migrate-parsetree 1.7.1 added a new, top-level (non-wrapped) Option module. This breaks anything using the stdlib's option module. Example program:

let iter = Option.iter

and dune file:

(executable
 (name main)
 (libraries ocaml-migrate-parsetree))

This fails with:

File "main.ml", line 1, characters 8-19:
1 | let x = Option.iter
            ^^^^^^^^^^^
Error (alert deprecated): module Option
Access modules via the Migrate_parsetree toplevel module. Use Migrate_parsetree.Option instead.
File "main.ml", line 1, characters 8-19:
1 | let x = Option.iter
            ^^^^^^^^^^^
Error: Unbound value Option.iter

If the ocaml-migrate-parsetree dependency is removed, it works.

(seen in ocaml/opam-repository#16216)

Where are we on 4.05+beta compatibility?

The README still mentions 4.05 as trunk. Now that 4.05 has been branched in preparation for a release, those are two distinct branches. Could you update the text and maybe clarify that 4.05 support is feature-complete with respect to the beta(s)?

Alain Frisch mentioned that this tool should be recommended for ppx authors for stability/compatibility. I am planning to mention it during the 4.05 release preparation -- so any improvement to the documentation is welcome.

ocaml-migrate-parsetree fails to build on 4.14.0+trunk

This is an error log from sandmark where I am trying to build ocaml-migrate-parsetree.2.1.0 with 4.14.0+trunk and dune.2.9.0

#=== ERROR while compiling ocaml-migrate-parsetree.2.1.0+stock ================#
# context              2.0.6 | linux/x86_64 | ocaml-base-compiler.4.14.0+trunk | file:///home/shubham/sandmark/dependencies
# path                 ~/sandmark/_opam/4.14.0+trunk/.opam-switch/build/ocaml-migrate-parsetree.2.1.0+stock
# command              ~/sandmark/_opam/4.14.0+trunk/bin/dune build -p ocaml-migrate-parsetree -j 27
# exit-code            1
# env-file             ~/sandmark/_opam/log/ocaml-migrate-parsetree-14664-9055a8.env
# output-file          ~/sandmark/_opam/log/ocaml-migrate-parsetree-14664-9055a8.out
### output ###
#        ocaml src/ast-version (exit 1)
# (cd _build/default/src && /home/shubham/sandmark/_opam/4.14.0+trunk/bin/ocaml config/gen.ml 4.14.0+dev0-2021-06-03)
# Unknown OCaml version 4.14.0+dev0-2021-06-03

module open in patterns failing on ocaml 4.04

When using OCaml 4.04.0 with this line

    function
    | Opam_bulk_build_diff_key.(Remote {o;n;ocaml_version;distro}) ->
        Fmt.strf "Diffing %d -> %d packages (%s-%a)"
         (List.length o) (List.length n) distro OV.pp ocaml_version

I am getting a migrate-parsetree exception:

Fatal error: exception File "src/opam_bulk_build_diff.ml", line 41, characters 6-66: module open in patterns are not supported before OCaml 4.04
Raised at file "src/migrate_parsetree_404_403_migrate.ml", line 24, characters 2-49
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 260, characters 8-46
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 223, characters 8-29
Called from file "list.ml", line 59, characters 20-23
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 63, characters 8-31
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 37, characters 8-49
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 69, characters 10-30
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 37, characters 8-49
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 244, characters 8-34
Called from file "list.ml", line 59, characters 20-23
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 502, characters 10-42
Called from file "src/migrate_parsetree_404_403_migrate.ml", line 485, characters 8-44

However, I am in fact on OCaml 4.04.0, so presumably shouldn't be getting this failure?

ocaml-migrate-parsetree 2.0.0

This is a meta issue to track the progress towards ocaml-migrate-parsetree 2.0.0, a new major release that simplify ocaml-migrate-parsetree to its core functionality: the parsetree type definitions + the migration functions.

Todo:

  • port existing projects to ppxlib: list here
  • simplify the ocaml-parsetree-repository
  • add version constraints to reverse dependencies of ocaml-migrate-parsetree
  • release ocaml-migrate-parsetree 2.0.0
  • release a version of ppxlib that is compatible with ocaml-migrate-parsetree 2.0.0

Docker build with `opam install ocaml-migrate-parsetree` fails

Hi!

I created a basic OCaml Docker image with an installed OCaml compiler 4.06.0 and opam 1.2.2.

I based off a Dockerfile which installs ocaml-migrate-parsetree like this:

FROM ryyppy/ocaml:4.06.0

RUN opam install ocaml-migrate-parsetree || true

docker build -t my-ocaml -f Dockerfile . does yield following error messages during the build:

Step 1/2 : FROM ryyppy/ocaml:4.06.0
 ---> 9fd61c178361
Step 2/2 : RUN opam install ocaml-migrate-parsetree || true
 ---> Running in 9126211b07a3
The following actions will be performed:
  - install ocaml-migrate-parsetree 1.0.11

=-=- Gathering sources =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[ocaml-migrate-parsetree: from default] Command started
[ocaml-migrate-parsetree: from default] Command started
[default] https://opam.ocaml.org/archives/ocaml-migrate-parsetree.1.0.11+opam.tar.gz downloaded

=-=- Processing actions -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[ocaml-migrate-parsetree: jbuilder build] Command started
[ERROR] The compilation of ocaml-migrate-parsetree failed at "jbuilder build -p
        ocaml-migrate-parsetree -j 4".

#=== ERROR while installing ocaml-migrate-parsetree.1.0.11 ====================#
# opam-version         1.2.2
# os                   linux
# command              jbuilder build -p ocaml-migrate-parsetree -j 4
# path                 /home/opam/.opam/system/build/ocaml-migrate-parsetree.1.0.11
# compiler             system (4.06.0)
# exit-code            127
# env-file             /home/opam/.opam/system/build/ocaml-migrate-parsetree.1.0.11/ocaml-migrate-parsetree-5-ad8886.env
# stdout-file          /home/opam/.opam/system/build/ocaml-migrate-parsetree.1.0.11/ocaml-migrate-parsetree-5-ad8886.out
# stderr-file          /home/opam/.opam/system/build/ocaml-migrate-parsetree.1.0.11/ocaml-migrate-parsetree-5-ad8886.err



=-=- Error report -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The following actions failed
  - install ocaml-migrate-parsetree 1.0.11
No changes have been performed
Removing intermediate container 9126211b07a3
 ---> 509f962534b6
Successfully built 509f962534b6
Successfully tagged my-ocaml:latest

I entered the container and looked into the resulting .out and .err files, but they are empty.

Another interesting thing: When I run the original docker image and do the opam install command in interactive mode, it works just fine.

Any ideas how to fix this?

Wish: Migrate raised exceptions

It would be better if the types of exceptions that might be raised by functions were also migrated along with their argument and return types. For example, Migrate_parsetree_parse.implementation may raise Warnings.Errors which has a different arity between 4.05 and 4.06.

ETA on support for 5.1

Hi !
Do you have any kind of timeline for supporting 5.1 ? Thanks !
As for today, opam show still mentions ocaml < 5. 1

normalize whitespace in output across OCaml versions

I ran into some differences in whitespace across OCaml versions when testing a ppx rewriter.
For example OCaml 4.02-4.05 places no space after a comma in tuples but adds some trailing space in other places where OCaml >= 4.06 does not.
See here: vogler/ppx_distr_guards@2c94051
I normalize the output with sed and only then compare.

It would be nicer if the output was the same across versions.
I assume the pretty-printing is done by OCaml itself, but maybe omp could normalize it afterwards?

Wish: support migration of Env

Would it be difficult to handle the migrations of env.ml ? I am mainly interested by the migration between 4.06 and 4.07 where the type Env.summary has been changed.
Thanks.

--dump-ast: write the same version of AST that was read

So, if reading, e.g., a version 4.02 binary AST, writing with --dump-ast should produce a version 4.02 binary AST.

Right now, it produces an AST of whatever compiler version the driver was compiled with.

I believe this is the ultimate place where the decision to write the same version is not made:

| Intf (_, sg) -> Ast_io.Intf ((module OCaml_current), sg)
| Impl (_, st) -> Ast_io.Impl ((module OCaml_current), st)

I guess we would need to note the source version on loading. On writing, we would need to migrate the AST to the target version (instead of to the current version, wherever this is done), and then write that. If the source version is not available (because we read a source file), we can write according to the version with which the driver was compiled, as now.

If this is approved, I can try to make the change.

Build failure with OCaml 4.14.0

Trying to build 2.3.0 I get this error:

$ dune build -j16
File "tools/gencopy.ml", line 147, characters 60-74:
147 |         List.map2 (fun s t -> (t.id, evar s.txt)) params_in td.type_params
                                                                  ^^^^^^^^^^^^^^
Error: This expression has type type_expr list
       but an expression was expected of type transient_expr list
       Type type_expr is not compatible with type transient_expr 

Build failure in ast405.ml with 4.05.0+trunk+flambda

Hi,

using 4.05.0+trunk+flamba it is not possible to build 1.0.1 from opam. Some of the result below, is that enough to find the reason?

An opam update && opam upgrade was done prior to compiling.

/Jörgen

teg@zotac:~$ opam install ocaml-migrate-parsetree
The following actions will be performed:
  ∗  install ocaml-migrate-parsetree 1.0.1

=-=- Gathering sources =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[ocaml-migrate-parsetree] Archive in cache

=-=- Processing actions -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[ERROR] The compilation of ocaml-migrate-parsetree failed at "jbuilder build -p
        ocaml-migrate-parsetree -j 1".

#=== ERROR while installing ocaml-migrate-parsetree.1.0.1 =====================#
# opam-version 1.2.2
# os           linux
# command      jbuilder build -p ocaml-migrate-parsetree -j 1
# path         /home/teg/.opam/4.05.0+trunk+flambda/build/ocaml-migrate-parsetree.1.0.1
# compiler     4.05.0+trunk+flambda
# exit-code    1
# env-file     /home/teg/.opam/4.05.0+trunk+flambda/build/ocaml-migrate-parsetree.1.0.1/ocaml-migrate-parsetree-3605-1872ec.env
# stdout-file  /home/teg/.opam/4.05.0+trunk+flambda/build/ocaml-migrate-parsetree.1.0.1/ocaml-migrate-parsetree-3605-1872ec.out
# stderr-file  /home/teg/.opam/4.05.0+trunk+flambda/build/ocaml-migrate-parsetree.1.0.1/ocaml-migrate-parsetree-3605-1872ec.err
### stderr ###
# Warning: copy-and-add-line-directive is deprecated, use copy# instead
# [...]
#       ocamlc src/ast_402.{cmi,cmo,cmt}
#       ocamlc src/ast_403.{cmi,cmo,cmt}
#       ocamlc src/ast_404.{cmi,cmo,cmt}
#       ocamlc src/ast_405.{cmi,cmo,cmt} (exit 2)
# (cd _build/default && /home/teg/.opam/4.05.0+trunk+flambda/bin/ocamlc.opt -w -40 -g -bin-annot -I /home/teg/.opam/4.05.0+trunk+flambda/lib/ocaml/compiler-libs -no-alias-deps -I src -o src/ast_405.cmo -c -impl src/ast_405.pp.ml)
# File "src/ast_405.ml", line 2856, characters 2-146:
# Error: This variant or record definition does not match that of type
#          Outcometree.out_variant
#        Fields number 2 have different names, Ovar_name and Ovar_typ.



=-=- Error report -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The following actions failed
  ∗  install ocaml-migrate-parsetree 1.0.1
No changes have been performed

Does not compile with multicore-ocaml

Currently investigating why it does not build with multicore-ocaml trunk.

This is the error message

File "src/ast_406.ml", line 237, characters 2-1773:
Error: This variant or record definition does not match that of type
         Parsetree.pattern_desc
       Fields number 17 have different names, Ppat_effect and Ppat_extension.

Any help would be appreciated. Thanks!

Add Reason flags --re-intf and --re-impl

I'm working on a ppx where the test cases are written in Reason. Right now I have to manually run these test cases through refmt and write .ml files, that I feed to the omp driver with --impl flag.

But I'm curious if it'd be possible to add some new flags to omp for this?

My current Dune rule:

(rule
 (targets pp.result)
 (deps test.ml)
 (action (run ./main.exe --impl %{deps} -o %{targets})))

What would be ideal:

(rule
 (targets pp.result)
 (deps test.re)
 (action (run ./main.exe --re-impl %{deps} -o %{targets})))

Wish: Ast_iterator

Would it be difficult to handle Ast_iterator similarly to how Ast_mapper is handled now? Only for the versions where it appears (>= 4.03 IIRC).

A workaround to print ## as it is, not as a infix operator.

Taken from here

Eg. obj##foo will be translated to (## obj foo) when I invoke ppx_deriving as a command line tool (compiled by myself). I understand ## is not standard object dispatch but is it possible that we keep it as it is, and not transform it?

Thanks!

Best,
Bob

The magic number checks of `Ast_4NN.register` appear to be broken

I am trying to understand the cause of a segfault in ppx_deriving (reported by @kit-ty-kate) since we migrated to ppxlib, see ocaml-ppx/ppx_deriving#210 (comment) . @thierry-martinez tracked down the issue to incompatible serialized ASTs (we seem to be calling input_value on an AST of some version, and getting a segfault when we try to use it as it was of another version), originating from a call to Ast_408.Ast_mapper.register. This suggests an issue in m-o-p, at least in terms of validation of magic numbers.

Indeed, the current source fo Ast_408 and all later versions have an Ast_mapper.apply_lazy module that performs magic number check using a Config module that appears to be the current compiler-libs config module (so it is checking against the current magic numbers, not 4.08's). There is a Config module defined later in the file, which provides the correct 4.08 magic numbers.

Magic number checking lines 3843-3847:
https://github.com/ocaml-ppx/ocaml-migrate-parsetree/blob/18c00c9/src/ast_408.ml#L3843-L3847

Re-definition of Config lines 4043-4046:
https://github.com/ocaml-ppx/ocaml-migrate-parsetree/blob/18c00c9/src/ast_408.ml#L4043-L4046

Questions:

  • Is this analysis correct, that the magic number checks of the Ast_4NN modules (_409 and _410 at least appear to have copy-pasted this code) are checking against the current-version magic number instead of their own version?
  • If this is the case, how come nobody noticed this before?
  • Why are those modules containing a reimplementation of this logic? This was not the case for Ast_407 and earlier versions. I tracked the issue to the first commit of @xclerc in #70. I suppose that the reimplementation is there to work around some kind of upstream change, but I am not sure which one.

(cc also @rgrinberg @jeremiedimino)

Building ocaml-migrate-parsetree-1.0.2 fails

Building ocaml-migrate-parsetree-1.0.2 on ocaml-4.06.0 fails with:

ocamlc src/ast_406.{cmi,cmo,cmt} (exit 2)
(cd _build/default && /usr/bin/ocamlc.opt -w -40 -open Result -g -bin-annot -I /usr/lib64/ocaml/compiler-libs -I /usr/lib64/ocaml/site-lib/result -no-alias-deps -I src -o src/ast_406.cmo -c -impl src/ast_406.pp.ml)

File "src/ast_406.ml", line 141, characters 2-2027:
Error: This variant or record definition does not match that of type
Parsetree.core_type_desc
The types for field Ptyp_object are not equal.
make: *** [Makefile:10: all] Error 1

Is there a dependency missing which is not reported by jbuilder, or what else am I doing wrong?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.