Skip to content

First class module dynlink#100

Closed
chambart wants to merge 7 commits intoocaml:trunkfrom
chambart:first_class_dynlink
Closed

First class module dynlink#100
chambart wants to merge 7 commits intoocaml:trunkfrom
chambart:first_class_dynlink

Conversation

@chambart
Copy link
Contributor

Adds an interface to get the first class module out of an cmo/cma/cmxs file.
This was started as a joke. I continued it a bit, and push it here to discuss the overall idea.

This adds a syntax to get a type witness of a module:
(sig Module:Module_type) of type (module Module_type) sig_t
and adds two functions to dynlink: load_modules : string -> module_info list and check_module : module_info -> 'a sig_t -> 'a option

The witness contains only the digest of the cmi file for Module and check_module compares it with the digest of the interface a module implements. That way there is no need to add any new dependency to dynlink.

@samoht
Copy link
Member

samoht commented Sep 16, 2014

Do you have an example of code using this new feature (just curious to see what fun stuff we can do with that)?

@chambart
Copy link
Contributor Author

I don't have anything really fun sorry, but here are the things I've written for my tests:

main.ml

module type T = module type of Chose
let crc : (module T) sig_t = (sig Chose:T)

let filename = Dynlink.adapt_filename Sys.argv.(1)

let modules = Dynlink.load_modules filename
let l =
  List.map (fun m -> Dynlink.check_module m crc) modules
  |> List.filter (function None -> false | _ -> true)

let m =
  match l with
  | Some m :: _ -> m
  | _ -> failwith "can't find module"

module M = (val m:T)
let () = print_endline (M.print M.v)

chose.mli

type t
val v : t
val print : t -> string

t1/chose.ml

type t = string
let v = "choucroute"
let print x = x

t2/chose.ml

type t = int
let v = 42
let print = string_of_int
# ./test_dynlink t1/chose.cmxs
choucroute
# ./test_dynlink t2/chose.cmxs
42

@whitequark
Copy link
Member

I really like this! It's like dlopen/dlsym, but typesafe. The great thing about this feature is that with regular Dynlink, the dependency graph must be, strictly, a tree. Or to say it another way, Dynlink-using code is not at all more conceptually powerful than code linked in the regular way, it's just that the linking phase is deferred to runtime.

With this PR, if I understand it correctly, a shared object has to do nothing more than to export a certain interface, and then anyone can independently request this interface. So this interface is much more flexible.

@c-cube
Copy link
Contributor

c-cube commented Oct 24, 2014

That would mean plugins could be "pure", just exposing one or more interfaces, as @whitequark said, rather than registering themselves with some global variable and side-effect. I really like the idea too - in fact I could use it in my current code, to make some choices at runtime easily.

I'd add a load_module : string -> 'a sig_t -> 'a option for the common case where at most one instance of the module is expected.

@chambart
Copy link
Contributor Author

In fact this pr was intended to launch the discution, but for a more complete interface I would also try to reasonnably handle .cm{,x}a files by not executing all initialisation code by default, but only when it is requested or a dependency is requested.

Notice also that this pr solve an existing problem with dynlinking: if a module is dynlinked multiple times, its initialisation code is run each time, which is quite unsafe/borken with native code. With this pr we avoid this problem since we can reasonnably execute the code only once.

@lpw25
Copy link
Contributor

lpw25 commented Oct 24, 2014

I think the additional (sig Chose:T) syntax is a bit unfortunate because it requires an explicit .cmi file. At the moment the language does not distinguish top-level modules from other modules, and it would be a shame to break that.

So perhaps something "extra-linguistic" like [%sig Chose T] would be better. It could still be interpreted by the OCaml compiler, it just wouldn't technically be part of the OCaml language.

Just my 2 cents.

@whitequark
Copy link
Member

Another use case that I have for this feature is dynamic loading of OCaml backends. They are essentially modules that only export a val initialize : unit -> unit, which inserts the backend into the corresponding tables in C++ code. Right now it's not really possible to ship backends separately; and if you link them statically, they bloat your code enormously.

The more I look at this feature, the more I like it.

@whitequark
Copy link
Member

@lpw25 I would use [%ocaml.dynlink (sig Chose : T)], shortenable to [%dynlink (sig Chose : T)], as this is the convention that seems to have emerged.

@dbuenzli
Copy link
Contributor

Is this completely orthogonal to the idea of runtime types ?

@chambart
Copy link
Contributor Author

@dbuenzli Yes. The module signature is manipulated only by its crc, no type information is known or checked at runtime. But if we had a runtime representation of modules signatures, we could lift the restriction of matching exactly a signature and only verify some kind of reasonable subtyping.

@bobot
Copy link
Contributor

bobot commented Nov 11, 2014

This PR have been discussed during the last developers' meeting, where I had the pleasure to be. To sum-up:

  • Need more evidence how it works in real examples and how it compares with typed input_value and type output_value.
  • Better if it could not depend on an .mli but on any module type.
  • Otherwise nice proposition.

@gasche
Copy link
Member

gasche commented Jun 6, 2016

@chambart are you planning to do something with this feature? I find it very nice, and regret its absence whenever I'm considering using dynlink to do something.

@chambart
Copy link
Contributor Author

chambart commented Jun 7, 2016

@gasche I'm ready to update it to recent compiler and spend some time improving the interface. Last time it was discussed in a developer meeting, it was agreed that some 'real' feedback is needed to consider this for inclusion. Since I didn't have a serious use case for dynlink for quite some time and nobody else really tried, this is stalled since then.

I'm ready to spend some more time to bring that to a mergeable state, but I need to know first if this would be effectively accepted.

Note that I also need some feedback on the Dynlink module additions, and in particular, its semantics: when to effectively run the initialisation code.

@chambart
Copy link
Contributor Author

chambart commented Jun 7, 2016

By the way, one thing that I really don't like in this proposition is the necessity to have an explicit path for the module type:

module type T = module type of Chose
let crc : (module T) sig_t = (sig Chose:T)

or

module type T = module type of Chose
let crc : (module T) sig_t = [%signature Chose T]

The module type T seems completely useless, yet it is needed since there is no module type for Chose.

The various ways to avoid needing module type of Chose are:

  • Restrict the construction to the structure level and declare a module type at the same time as the value. Since the module type is needed also to use the value, it means that the declared module type cannot be hidden.
  • Implicitly declare a module type for each compilation unit.

I don't like the first one, and I don't know yet how to do the second well.

@bobot
Copy link
Contributor

bobot commented Jun 7, 2016

Indeed, the major question during the meeting was to try to accept any module type, ie to not have to depend on a specific path, .mli.

Just a dumb question is it really costly to really test the inclusion of the module type at runtime instead of using the hash?

@lpw25
Copy link
Contributor

lpw25 commented Jun 7, 2016

Just a dumb question is it really costly to really test the inclusion of the module type at runtime instead of using the hash?

I wouldn't even be confident it is semantically well defined in the general case. It is getting pretty close to trying to do type-checking dynamically which has all sorts of issues in the presence of abstraction. It might be all right with some restrictions (e.g. the module type only refers to types/modules that are defined globally) to try and make sure that there are no issues of abstraction involved, but it is not clear to me that those restrictions are any better than just referring to a .cmi file.

@chambart
Copy link
Contributor Author

chambart commented Jun 7, 2016

This would indeed be quite tricky and require that a program using dynlink essentially link the whole typechecker.
If we restrict to equality, we can imagine still using a hash of a module type without needing an explicit .cmi file, but after some discussion with @garrigue, it seems to be a nightmare in the current codebase.

Also this might be too cumbersome to use across different projets/repository as the same hash is required, but not necessarily the same file: it could be copied in the different projects.

@bobot
Copy link
Contributor

bobot commented Jun 7, 2016

With the .cmi you can't accept a .cmx that would define more fields than the .cmi. Moreover current ocaml build system must be extended to support the compilation of these plug-ins since you need to specify to use the .cmi that have been installed by the main tool.

So I think it would be interesting to try to typecheck dynamically with your restrictions, before going for a solution that create other complications.

@gasche
Copy link
Member

gasche commented Jun 7, 2016

current ocaml build system must be extended to support the compilation of these plug-ins since you need to specify to use the .cmi that have been installed by the main tool.

Do you? I was hoping to be able to write, for example

include (module type of Choose)

as the .mli of any of the modules intended for dynlinking. Wouldn't this work?

@garrigue
Copy link
Contributor

garrigue commented Jun 8, 2016

@gasche This probably wouldn't work. The embedded hash in the cmo/cmx is that of the cmi used at compile time.
But you can easily write a wrapper.

include Chose

and compile it along with the intended .cmi.

But now I understand what @bobot means: in its current form, this feature only really supports loading an already known module. If you want to be able to load several units, you need to force them to share the same .cmi. Technically, this is doable by giving them the same name, and compiling with a directory containing the .cmi, and also an .mli with the same name (otherwise the .cmi will be ignored). This doesn't sound ideal. So it would be nice to be able to declare at compile time that a physical module is actually using a specific .cmi to be found in the path.

@gasche
Copy link
Member

gasche commented Jun 8, 2016

Regarding real-world application, I wonder how much of ocaml_plugin could be superseded by this feature -- in a nicer way.

@lpw25
Copy link
Contributor

lpw25 commented Jun 8, 2016

I wonder how much of ocaml_plugin could be superseded by this feature

Probably not that much. I think most of the work which ocaml_plugin does is in recreating the environment for compiling the plugin -- which it does by carrying around a tarball containing all the required cmi files (and also the compiler itself if required). I don't think ocaml_plugin actually supports loading .cmxs files directly: it insists on compiling all the .ml files it uses by hand to ensure that they are built in the desired environment.

@chambart
Copy link
Contributor Author

chambart commented Jun 8, 2016

Is there a reason why the name of the module is part of the hash ? Otherwise building plugins with a copied (or ln -s) and renamed .mli file would be ok for a compatible dynlink without too much build system complexity.

@v-gb
Copy link
Contributor

v-gb commented Jun 8, 2016

Without testing the feature, I suspect it can't be used in ocaml_plugin nicely. The usual pattern is probably to have in some lib:

plugin_intf.ml:

module type S = struct
  .. (* the module type of loaded plugins *)
end
let univ_constr = ..
module Plugin_loader = OCaml_plugin.Std.Ocaml_compiler.Make(struct type t = (module S) let path = "Lib.Plugin_intf.S" .. end)

It seems this feature requires both to have a toplevel cmi of the relevant interface, and to name that interface as a signature, but neither of these are nice here.
First, having to have a cmi is annoying. We don't even accept mlis without ml here, so I suppose we'd need to change the build system. Second, relying on [module type of] to "copy" that cmi as a signature doesn't work. Anyone who builds with libraries that are "packed" with module aliases can't do that, as the module type of an alias contains additional type equalities. And that would prevent us from fixing [module type of] to stop creating incompatible signatures.

Here is an idea I haven't thought through: what if this sig_t, instead of being a digest, was essentially a cmi for the given interface (or both perhaps), along with [val cmi : _ sig_t -> string] or something? Would that help?
(the way to force the compiler to build a .ml with a given cmi is -intf-suffix .ml by the way, assuming the names match)

@alainfrisch
Copy link
Contributor

Is anyone interested to shepherd this PR? It has been around for 3 years, and the discussion died more than one year ago. If nobody steps up, I suggest to close it.

@mshinwell
Copy link
Contributor

I still reckon this would be a nice addition.

@damiendoligez damiendoligez added this to the 4.07-or-later milestone Sep 25, 2017
@alainfrisch
Copy link
Contributor

I still reckon this would be a nice addition.

I don't feel a lot of momentum to push the proposal forward. Are you willing to shepherd it?

@mshinwell
Copy link
Contributor

@alainfrisch I don't have time to at the moment, but others may...

@xavierleroy
Copy link
Contributor

Two years after @alainfrisch's three-years-after ping, this PR is still dormant, so I'm taking the liberty to close it.

For the record: I, like many others, am interested in type-safe dynamic loading, and intrigued by the proposed approach. If there is enough interest and developers willing to spend time on the design and implementation, I suggest to turn it into a roadmap item proposal and discuss at a developer's meeting.

mshinwell added a commit to mshinwell/ocaml that referenced this pull request Apr 10, 2020
lthls pushed a commit to lthls/ocaml that referenced this pull request Sep 23, 2020
lthls pushed a commit to lthls/ocaml that referenced this pull request Sep 23, 2020
lthls pushed a commit to lthls/ocaml that referenced this pull request Sep 24, 2020
chambart pushed a commit to chambart/ocaml-1 that referenced this pull request Aug 4, 2021
stedolan pushed a commit to stedolan/ocaml that referenced this pull request Oct 5, 2021
stedolan pushed a commit to stedolan/ocaml that referenced this pull request Dec 13, 2021
chambart pushed a commit to chambart/ocaml-1 that referenced this pull request Feb 1, 2022
23a7f73 flambda-backend: Fix some Debuginfo.t scopes in the frontend (ocaml#248)
33a04a6 flambda-backend: Attempt to shrink the heap before calling the assembler (ocaml#429)
8a36a16 flambda-backend: Fix to allow stage 2 builds in Flambda 2 -Oclassic mode (ocaml#442)
d828db6 flambda-backend: Rename -no-extensions flag to -disable-all-extensions (ocaml#425)
68c39d5 flambda-backend: Fix mistake with extension records (ocaml#423)
423f312 flambda-backend: Refactor -extension and -standard flags (ocaml#398)
585e023 flambda-backend: Improved simplification of array operations (ocaml#384)
faec6b1 flambda-backend: Typos (ocaml#407)
8914940 flambda-backend: Ensure allocations are initialised, even dead ones (ocaml#405)
6b58001 flambda-backend: Move compiler flag -dcfg out of ocaml/ subdirectory (ocaml#400)
4fd57cf flambda-backend: Use ghost loc for extension to avoid expressions with overlapping locations (ocaml#399)
8d993c5 flambda-backend: Let's fix instead of reverting flambda_backend_args (ocaml#396)
d29b133 flambda-backend: Revert "Move flambda-backend specific flags out of ocaml/ subdirectory (ocaml#382)" (ocaml#395)
d0cda93 flambda-backend: Revert ocaml#373 (ocaml#393)
1c6eee1 flambda-backend: Fix "make check_all_arches" in ocaml/ subdirectory (ocaml#388)
a7960dd flambda-backend: Move flambda-backend specific flags out of ocaml/ subdirectory (ocaml#382)
bf7b1a8 flambda-backend: List and Array Comprehensions (ocaml#147)
f2547de flambda-backend: Compile more stdlib files with -O3 (ocaml#380)
3620c58 flambda-backend: Four small inliner fixes (ocaml#379)
2d165d2 flambda-backend: Regenerate ocaml/configure
3838b56 flambda-backend: Bump Menhir to version 20210419 (ocaml#362)
43c14d6 flambda-backend: Re-enable -flambda2-join-points (ocaml#374)
5cd2520 flambda-backend: Disable inlining of recursive functions by default (ocaml#372)
e98b277 flambda-backend: Import ocaml#10736 (stack limit increases) (ocaml#373)
82c8086 flambda-backend: Use hooks for type tree and parse tree (ocaml#363)
33bbc93 flambda-backend: Fix parsecmm.mly in ocaml subdirectory (ocaml#357)
9650034 flambda-backend: Right-to-left evaluation of arguments of String.get and friends (ocaml#354)
f7d3775 flambda-backend: Revert "Magic numbers" (ocaml#360)
0bd2fa6 flambda-backend: Add [@inline ready] attribute and remove [@inline hint] (not [@inlined hint]) (ocaml#351)
cee74af flambda-backend: Ensure that functions are evaluated after their arguments (ocaml#353)
954be59 flambda-backend: Bootstrap
dd5c299 flambda-backend: Change prefix of all magic numbers to avoid clashes with upstream.
c2b1355 flambda-backend: Fix wrong shift generation in Cmm_helpers (ocaml#347)
739243b flambda-backend: Add flambda_oclassic attribute (ocaml#348)
dc9b7fd flambda-backend: Only speculate during inlining if argument types have useful information (ocaml#343)
aa190ec flambda-backend: Backport fix from PR#10719 (ocaml#342)
c53a574 flambda-backend: Reduce max inlining depths at -O2 and -O3 (ocaml#334)
a2493dc flambda-backend: Tweak error messages in Compenv.
1c7b580 flambda-backend: Change Name_abstraction to use a parameterized type (ocaml#326)
07e0918 flambda-backend: Save cfg to file (ocaml#257)
9427a8d flambda-backend: Make inlining parameters more aggressive (ocaml#332)
fe0610f flambda-backend: Do not cache young_limit in a processor register (upstream PR 9876) (ocaml#315)
56f28b8 flambda-backend: Fix an overflow bug in major GC work computation (ocaml#310)
8e43a49 flambda-backend: Cmm invariants (port upstream PR 1400) (ocaml#258)
e901f16 flambda-backend: Add attributes effects and coeffects (#18)
aaa1cdb flambda-backend: Expose Flambda 2 flags via OCAMLPARAM (ocaml#304)
62db54f flambda-backend: Fix freshening substitutions
57231d2 flambda-backend: Evaluate signature substitutions lazily (upstream PR 10599) (ocaml#280)
a1a07de flambda-backend: Keep Sys.opaque_identity in Cmm and Mach (port upstream PR 9412) (ocaml#238)
faaf149 flambda-backend: Rename Un_cps -> To_cmm (ocaml#261)
ecb0201 flambda-backend: Add "-dcfg" flag to ocamlopt (ocaml#254)
32ec58a flambda-backend: Bypass Simplify (ocaml#162)
bd4ce4a flambda-backend: Revert "Semaphore without probes: dummy notes (ocaml#142)" (ocaml#242)
c98530f flambda-backend: Semaphore without probes: dummy notes (ocaml#142)
c9b6a04 flambda-backend: Remove hack for .depend from runtime/dune  (ocaml#170)
6e5d4cf flambda-backend: Build and install Semaphore (ocaml#183)
924eb60 flambda-backend: Special constructor for %sys_argv primitive (ocaml#166)
2ac6334 flambda-backend: Build ocamldoc (ocaml#157)
c6f7267 flambda-backend: Add -mbranches-within-32B to major_gc.c compilation (where supported)
a99fdee flambda-backend: Merge pull request ocaml#10195 from stedolan/mark-prefetching
bd72dcb flambda-backend: Prefetching optimisations for sweeping (ocaml#9934)
27fed7e flambda-backend: Add missing index param for Obj.field (ocaml#145)
cd48b2f flambda-backend: Fix camlinternalOO at -O3 with Flambda 2 (ocaml#132)
9d85430 flambda-backend: Fix testsuite execution (ocaml#125)
ac964ca flambda-backend: Comment out `[@inlined]` annotation. (ocaml#136)
ad4afce flambda-backend: Fix magic numbers (test suite) (ocaml#135)
9b033c7 flambda-backend: Disable the comparison of bytecode programs (`ocamltest`) (ocaml#128)
e650abd flambda-backend: Import flambda2 changes (`Asmpackager`) (ocaml#127)
14dcc38 flambda-backend: Fix error with Record_unboxed (bug in block kind patch) (ocaml#119)
2d35761 flambda-backend: Resurrect [@inline never] annotations in camlinternalMod (ocaml#121)
f5985ad flambda-backend: Magic numbers for cmx and cmxa files (ocaml#118)
0e8b9f0 flambda-backend: Extend conditions to include flambda2 (ocaml#115)
99870c8 flambda-backend: Fix Translobj assertions for Flambda 2 (ocaml#112)
5106317 flambda-backend: Minor fix for "lazy" compilation in Matching with Flambda 2 (ocaml#110)
dba922b flambda-backend: Oclassic/O2/O3 etc (ocaml#104)
f88af3e flambda-backend: Wire in the remaining Flambda 2 flags (ocaml#103)
678d647 flambda-backend: Wire in the Flambda 2 inlining flags (ocaml#100)
1a8febb flambda-backend: Formatting of help text for some Flambda 2 options (ocaml#101)
9ae1c7a flambda-backend: First set of command-line flags for Flambda 2 (ocaml#98)
bc0bc5e flambda-backend: Add config variables flambda_backend, flambda2 and probes (ocaml#99)
efb8304 flambda-backend: Build our own ocamlobjinfo from tools/objinfo/ at the root (ocaml#95)
d2cfaca flambda-backend: Add mutability annotations to Pfield etc. (ocaml#88)
5532555 flambda-backend: Lambda block kinds (ocaml#86)
0c597ba flambda-backend: Revert VERSION, etc. back to 4.12.0 (mostly reverts 822d0a0 from upstream 4.12) (ocaml#93)
037c3d0 flambda-backend: Float blocks
7a9d190 flambda-backend: Allow --enable-middle-end=flambda2 etc (ocaml#89)
9057474 flambda-backend: Root scanning fixes for Flambda 2 (ocaml#87)
08e02a3 flambda-backend: Ensure that Lifthenelse has a boolean-valued condition (ocaml#63)
77214b7 flambda-backend: Obj changes for Flambda 2 (ocaml#71)
ecfdd72 flambda-backend: Cherry-pick 9432cfdadb043a191b414a2caece3e4f9bbc68b7 (ocaml#84)
d1a4396 flambda-backend: Add a `returns` field to `Cmm.Cextcall` (ocaml#74)
575dff5 flambda-backend: CMM traps (ocaml#72)
8a87272 flambda-backend: Remove Obj.set_tag and Obj.truncate (ocaml#73)
d9017ae flambda-backend: Merge pull request ocaml#80 from mshinwell/fb-backport-pr10205
3a4824e flambda-backend: Backport PR#10205 from upstream: Avoid overwriting closures while initialising recursive modules
f31890e flambda-backend: Install missing headers of ocaml/runtime/caml (ocaml#77)
83516f8 flambda-backend: Apply node created for probe should not be annotated as tailcall (ocaml#76)
bc430cb flambda-backend: Add Clflags.is_flambda2 (ocaml#62)
ed87247 flambda-backend: Preallocation of blocks in Translmod for value let rec w/ flambda2 (ocaml#59)
a4b04d5 flambda-backend: inline never on Gc.create_alarm (ocaml#56)
cef0bb6 flambda-backend: Config.flambda2 (ocaml#58)
ff0e4f7 flambda-backend: Pun labelled arguments with type constraint in function applications (ocaml#53)
d72c5fb flambda-backend: Remove Cmm.memory_chunk.Double_u (ocaml#42)
9d34d99 flambda-backend: Install missing artifacts
10146f2 flambda-backend: Add ocamlcfg (ocaml#34)
819d38a flambda-backend: Use OC_CFLAGS, OC_CPPFLAGS, and SHAREDLIB_CFLAGS for foreign libs (#30)
f98b564 flambda-backend: Pass -function-sections iff supported. (#29)
e0eef5e flambda-backend: Bootstrap (#11 part 2)
17374b4 flambda-backend: Add [@@Builtin] attribute to Primitives (#11 part 1)
85127ad flambda-backend: Add builtin, effects and coeffects fields to Cextcall (#12)
b670bcf flambda-backend: Replace tuple with record in Cextcall (#10)
db451b5 flambda-backend: Speedups in Asmlink (#8)
2fe489d flambda-backend: Cherry-pick upstream PR#10184 from upstream, dynlink invariant removal (rev 3dc3cd7 upstream)
d364bfa flambda-backend: Local patch against upstream: enable function sections in the Dune build
886b800 flambda-backend: Local patch against upstream: remove Raw_spacetime_lib (does not build with -m32)
1a7db7c flambda-backend: Local patch against upstream: make dune ignore ocamldoc/ directory
e411dd3 flambda-backend: Local patch against upstream: remove ocaml/testsuite/tests/tool-caml-tex/
1016d03 flambda-backend: Local patch against upstream: remove ocaml/dune-project and ocaml/ocaml-variants.opam
93785e3 flambda-backend: To upstream: export-dynamic for otherlibs/dynlink/ via the natdynlinkops files (still needs .gitignore + way of generating these files)
63db8c1 flambda-backend: To upstream: stop using -O3 in otherlibs/Makefile.otherlibs.common
eb2f1ed flambda-backend: To upstream: stop using -O3 for dynlink/
6682f8d flambda-backend: To upstream: use flambda_o3 attribute instead of -O3 in the Makefile for systhreads/
de197df flambda-backend: To upstream: renamed ocamltest_unix.xxx files for dune
bf3773d flambda-backend: To upstream: dune build fixes (depends on previous to-upstream patches)
6fbc80e flambda-backend: To upstream: refactor otherlibs/dynlink/, removing byte/ and native/
71a03ef flambda-backend: To upstream: fix to Ocaml_modifiers in ocamltest
686d6e3 flambda-backend: To upstream: fix dependency problem with Instruct
c311155 flambda-backend: To upstream: remove threadUnix
52e6e78 flambda-backend: To upstream: stabilise filenames used in backtraces: stdlib/, otherlibs/systhreads/, toplevel/toploop.ml
7d08e0e flambda-backend: To upstream: use flambda_o3 attribute in stdlib
403b82e flambda-backend: To upstream: flambda_o3 attribute support (includes bootstrap)
65032b1 flambda-backend: To upstream: use nolabels attribute instead of -nolabels for otherlibs/unix/
f533fad flambda-backend: To upstream: remove Compflags, add attributes, etc.
49fc1b5 flambda-backend: To upstream: Add attributes and bootstrap compiler
a4b9e0d flambda-backend: Already upstreamed: stdlib capitalisation patch
4c1c259 flambda-backend: ocaml#9748 from xclerc/share-ev_defname (cherry-pick 3e937fc)
00027c4 flambda-backend: permanent/default-to-best-fit (cherry-pick 64240fd)
2561dd9 flambda-backend: permanent/reraise-by-default (cherry-pick 50e9490)
c0aa4f4 flambda-backend: permanent/gc-tuning (cherry-pick e9d6d2f)

git-subtree-dir: ocaml
git-subtree-split: 23a7f73
sadiqj pushed a commit to sadiqj/ocaml that referenced this pull request Feb 21, 2023
stedolan pushed a commit to stedolan/ocaml that referenced this pull request Mar 21, 2023
c703f5f Incorporate upstream comments into type-variable refactor (ocaml#121)
362ba23 Constrain curry modes to increase along applications (ocaml#108)
b1f0cf9 Simplify the extension handling (ocaml#114)
4fd53a1 Remove pat_mode from typedtree (ocaml#105)
cf6fcbc Handle attributes on lambdas with locally abstract types (ocaml#120)
5fa80fe Don't track attributes inside attributes for warning 53 (ocaml#115)
8a69777 Handle unclosed `[: ... :]` patterns (via `Generic_array` machinery) (ocaml#117)
b0737f4 Add promote-one Makefile target (ocaml#118)
c6ad684 Refactoring and fixes around module lookup (ocaml#107)
b0a6495 Add documentation for global constructor arguments (ocaml#69)
dd79aec Print `nlocal` in the `-d(raw)lambda` output (ocaml#112)
8035026 Fix `nlocal` in the generated Lambda for list comprehensions (ocaml#113)
afbcdf0 Immutable arrays (ocaml#47)
bfe1490 fix several issues when removing exp_mode (ocaml#110)
8f46060 Better error message for under-applied functions (ocaml#74)
27331d8 Consistently use Lmutvar or Lvar in comprehensions (ocaml#111)
01e965b Skip failing test for now
0131357 Fix test case to use comprehensions_experimental
22a7368 Temporarily disable list comprehensions tests due to locals bug
e08377d Make `comprehensions` into `comprehensions_experimental` for now (ocaml#109)
947cf89 List and array comprehensions (ocaml#46)
bd9e051 remove exp_mode from typedtree (ocaml#100)
a9268d2 Fix misplaced attribute warning when using external parser (and some cleanup) (ocaml#101)
2b33f24 Refactor toplevel local escape check (ocaml#104)
ed2aec6 Comment functions exported from TyVarEnv.
87838ba Move new variable creation into TyVarEnv.
a3f60ab Encapsulate functions that work with tyvars
43d83a6 Prevent possibility of forgetting to re-widen
2f3dd34 Encapsulate context when narrowing type env't
d78ff6d Make immediate64 things mode cross (ocaml#97)
aa25ab9 Fix version number (ocaml#94)
d01ffa0 Fix .depend file (ocaml#93)
942f2ab Bootstrap (ocaml#92)
05f7e38 Check Menhir version (ocaml#91)
1569b58 Move the CI jobs from 4.12 to 4.14. (ocaml#90)

git-subtree-dir: ocaml
git-subtree-split: c703f5f
EmileTrotignon pushed a commit to EmileTrotignon/ocaml that referenced this pull request Jan 12, 2024
EmileTrotignon pushed a commit to EmileTrotignon/ocaml that referenced this pull request Jan 12, 2024
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.