These options allow to control whether identifiers are made unique by
appending a stamp to them when dumping intermediate representations or not.
The default is to print the stamp, as is done currently.
The "-dno-unique-ids" option is useful e.g. to simplify the comparison
between a produced intermediate reprsentation (-dlambda, say) and the
expected one, in the context of the testsuite, for instance.
Except for the Camlinternal* modules and the new Stdlib module, all
modules in the stdlib now compile to Stdlib__<module>.
Pervasives is renamed to Stdlib and now contains a list of aliases
from the long names to the short ones, so that from inside and outside
the stdlib we can refer to the standard modules as just List or
Stdlib.List rather than Stdlib__list.
In order to avoid printing the long names in error messages and in the
toplevel, the following heuristic is added to Printtyp: given a path
Foo__bar, if Foo.Bar exists and is a direct or indirect alias to
Foo__bar, then prefer Foo.Bar.
A bootstrap step was required to replace Pervasives by Stdlib as the
module opened by default.
Before, cyclic dependencies were reported as a warning, and ocamldep -sort would exit with code 0.
Now, the message says "error" and the exit code is nonzero.
-(un)safe-string becomes -(no-)force-safe-string
-(un)safe-string-default becomes -default-unsafe-string
Config.safe_string (and Clflags.unsafe_string) keep their name for
backward-compatibility, as well as the C define CAML_SAFE_STRING
(which corresponds to -force-safe-string).
The install-flexdll target now puts the object files for FlexDLL in a
subdirectory flexdll of the Standard Library instead of in the Standard
Library itself.
A configuration tweak means that -I +flexdll is effectively added to all
compiler invocations and also a pseudo-option -L+flexdll to ocamlmklib
calls to Config.mkdll which fixes PR#7373.
Since 4.03, OCaml supports coloring its messages to standard output and standard
error, depending on the "-color" argument ({always,never,auto}). This commit
adds support for the environment variable "OCAML_COLOR" (which value can as well
be {always,never,auto}).
The command line argument "-color" takes precedence, "OCAML_COLOR" is only
taken into consideration if no "-color" is provided.
The motivation for this is that the user should have control over coloring
OCaml's output messages. OCamlbuild, a widely used build tool executes OCaml
not under a tty (and OCaml does not colorize errors and warnings), which lead
various packages use `color(always)` in their `_tags` files, which breaks with
other (non-interactive) programs (i.e. editor helpers).
Further discussion was done at https://github.com/ocaml/ocamlbuild/issues/87 and
https://github.com/ocaml/ocaml/pull/1098.
The code in this commit was written by Marcell Fischbach & Benedikt Meurer.
See [Mantis#5324](http://caml.inria.fr/mantis/view.php?id=5324) for some
context.
The code (which was originally written against 3.12) was ported to trunk by
doing
```bash
git clone https://github.com/bmeurer/ocaml-experimental/
cd ocaml-experimental
git diff master...linear-scan-register-allocator > t.diff
```
and then applying the diff by hand.
This commit modifies these two behaviours:
1. ``make install'' installs libraries with profiling support only when
this makes sense.
2. On platforms that do not support profiling with gprof, the -p option of
ocamlopt produces an error message.
On such platforms, ``make install'' was installing dummy profiling
libraries and ocamlopt's -p option was silently ignored.
In addition, this commit modifies the values of the PROFILING make
variable. Before the commit it was either prof or noprof. After the
commit it is either true or false.
In the asmrun directory, the call to ranlib for libasmrunp.a has also been
removed from the install target because this command is already invoked
in the rule that builds libasmrunp.a.
ocamlc/ocamlopt -config now prints the state of profiling support
This reverts commit 8adfe15f18.
This is a temporary revert caused by Continuous Integration
failure. We'll investigate the issue and merge again when it is fixed.
This commit modifies these two behaviours:
1. ``make install'' installs libraries with profiling support only when
this makes sense.
2. On platforms that do not support profiling with gprof, the -p option of
ocamlopt produces an error message.
On such platforms, ``make install'' was installing dummy profiling
libraries and ocamlopt's -p option was silently ignored.
In addition, this commit modifies the values of the PROFILING make
variable. Before the commit it was either prof or noprof. After the
commit it is either true or false.
In the asmrun directory, the call to ranlib for libasmrunp.a has also been
removed from the install target because this command is already invoked
in the rule that builds libasmrunp.a.
ocamlc/ocamlopt -config now prints the state of profiling support
* Added expand to toplevel.
The toplevel now also accepts -args and -args0. In order to avoid
problems with the overide_args hack now script file is allowed in
expand options.
* Fixed differences between .ml and .mli
* Added missing expand in opttopmain.
* Added some test for broken -args for toplevel.
The test checks whether the toplevel fails if the script file is passed
via args option.
* Corrected test case.
* Updated error case.
Instead of printing the error string, Arg.Bad is raised and a wrapper is
added around the parse_and_expand_dynamic_argv.
* Added begin ... end around try ... with.
* Added working example an strip error path.
* Use sed to remove path and fixed typo.
* Added documentation.
* Also fix typo in reference file.
* Added PR to the corresponding change entry.
* Reworked Changes entry.
* Added new tests and updated documentation.
A script file in a responsefile now only prints an error message instead
of the help.
* Removed duplicated entry.
* Simplified expand logic.
We only remember where the current last expanded option is.
* Use first non_expand position instead.
* Updated error message.
When reading a serialized-ast file, Pparse.file sets
Location.input_name to the filename embedded in the AST, and this is
correct. But before this patch it would also set Location.input_name
to the filename if this is a regular file, and this is wrong: this
filename may be a temporary file used for preprocessing (-pp option),
with a randomly-generated name, while Location.input_name is in fact
already correctly set to the user-provided source path.
I needed to fix two lines in ocamldoc/odoc_analyze.ml that
used !Location.input_file but actually required access to the
post-processing file (ocamldoc re-opens source files and rereads them
to detect documentation comments). This is not an invasive change as
the path to the post-processing file is available at this point in the
code (as the [input_file] variable).
This ocamldoc issue was caught thanks to Debian downstream work in bug
triaging ( mlpost breaks if it is not fixed, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802347 ) and package
maintenance (this bug would not have been found if Debian maintainers
had not kept the mlpost documentation generator working even after
non-trivial ocamldoc changes).
The parse_expand function does the same as parse and parse_dynamic
but allows Expand. However it does not update current to avoid
the problem that the array is modified.
This function is used for the ocamlopt, ocamlc, ocamlcp,
ocamloptp and ocamldep.
The read_aux function trims the cr character for the new-line
based method and the write functions are simplified without an
additional sep function.
The argument names are changed to match the default naming format
and the documentation is updated to match the implementation
behavior.
Also two new tests for reading and writing empty command lines as
well as a command lines containing empty arguments are added.
When configured with -safe-string, the OCaml tools will default to the
safe-string mode and ignore -unsafe-string command-line arguments. This
is intended to serve two purposes:
- Facilitate the detection of packages that are not ready
for -safe-string ready. (Perhaps with some OPAM switch?)
- Enable some optimizations that assume that all linked units are
compiled with -safe-string.
Note: currently, there is no check that units compiled with an OCaml
configured without -safe-string are not linked in.
The definition was suggested by Daniel Bunzli. It considers
that ".", "..", ".foo" all have an empty extension.
This commit also fixes chop_extension to align with this definition
and adds remove_extension which behaves as chop_extension but
does not fail when the extension is empty.
There used to be a Misc.chop_extension_if_any in the compiler code base.
The commit also replaces it with the new Filename.remove_extension.
Adds the required_globals information to bytecode compilation units.
This patch also bootstrap ocamlc. The cmo format is changed by this
commit, there is no way around bootstraping here. Note that ocamldep and
ocamllex does not rely on the cmo format, so they are not present in
this commit.
Changes in tests:
* Update test/transprim/comparison_table.ml.reference:
The (opaque (global List!)) expression is not present anymore
* Update tests/no-alias-deps/aliases.cmo.reference
The output of objinfo changed
In order to remove some redundancy, the Pparse modules used a dirty
Obj.magic trick to manipulate either structure or signature values
(ASTs parsed from source files). This unsafe approach means that
programming mistakes may result in broken type soudness, and indeed
I myself had to track a very puzzling Segfault during the development
of my Menhir backend (due to a copy-paste error I was passing
Parse.implementation instead of Parse.interface somewhere). Wondering
why your parser generator seems to generate segfaulting parsers is
Not Fun.
This change means that the external interface of Pparse has changed
a bit. There is no way to fulfill the type of Pparse.file in
a type-safe way
val file : formatter -> tool_name:string -> string ->
(Lexing.lexbuf -> 'a) -> string -> 'a
as it promises to be able to process any ast type 'a depending on the
magic number (the last string argument). The knew type-safe interface is
val file : formatter -> tool_name:string -> string ->
(Lexing.lexbuf -> 'a) -> 'a ast_kind -> 'a
where ['a ast_kind] is a GADT type:
type 'a ast_kind =
| Structure : Parsetree.structure ast_kind
| Signature : Parsetree.signature ast_kind
This addresses PR#6475.
In 4.02 the behavior of ocamlc/ocamlopt with regards to these options
was as follows:
* options and arguments are parsed left-to-right in the exact order
in which they are passed, with compilation taking into account
only the options leftwards from it;
* "foo.c" is compiled to "foo.o" in current directory;
* when "-c" is not specified:
* "foo.ml" is compiled to "foo.cmo"/"foo.cmxo"
in current directory;
* after all files have been compiled, if any .ml files are passed,
all provided files are linked as:
* when "-o" is not specified: "a.out" in current directory;
* when "-o out" is specified: "out".
* when "-c" is specified:
* "foo.ml" is compiled to:
* when "-o" is not specified: "foo.cmo"/"foo.cmxo"
in current directory;
* when "-o out" is specified: "out.cmo"/"out.cmxo";
and then compilation proceeds as if the last "-o" option
has disappeared.
* no final link is performed.
The behavior where the build product of the C sources always ended up
in the current directory was problematic: it required buildsystem
hacks to move the file in its proper place and ultimately was racy,
as multiple files with the same basename in different directories
may well end up overwriting each other with e.g. ocamlbuild.
On top of that, the behavior was quite confusing, since it is not
only stateful and dependent on argument order, but also the mere act
of compilation changed state.
The commit 1d8e590c has attempted to rectify that by looking at
the "-o" option when compiling C files, too. After that commit,
the behavior of ocamlc/ocamlopt was as follows (only the handling
of C files was changed, but the entire chart is provided for
posterity):
* options and arguments are parsed left-to-right in the exact order
in which they are passed, with compilation taking into account
only the options leftwards from it;
* "foo.c" is compiled to:
* when "-o" is not specified: "foo.o" in current directory;
* when "-o out" is specified: "out".
* when "-c" is not specified:
* "foo.ml" is compiled to "foo.cmo"/"foo.cmxo"
in current directory;
* after all files have been compiled, if any .ml files are passed,
all provided files are linked as:
* when "-o" is not specified: "a.out" in current directory;
* when "-o out" is specified: "out".
* when "-c" is specified:
* "foo.ml" is compiled to:
* when "-o" is not specified: "foo.cmo"/"foo.cmxo"
in current directory;
* when "-o out" is specified: "out.cmo"/"out.cmxo";
and then compilation proceeds as if the last "-o" option
has disappeared.
* no final link is performed.
There is a non-obvious bug here. Specifically, what happens if more
than one C source file is passed together with a "-o" option? Also,
what happens if a C source file is passed together with a "-o" option
and then a final link is performed? The answer is that
the intermediate build product gets silently overwritten, with quite
opaque errors as a result.
There is some code (and even buildsystems) in the wild that is relying
on the fact that the -o option does not affect compilation of C source
files, e.g. by running commands such as (from ocamlnet):
ocamlc -custom -o t tend.c t.ml
It might seem that the solution would be to make the behavior of
the compiler drivers for C files match that for the OCaml files;
specifically, pretend that the "-o" option has disappeared once
the C compiler has written a build product to the specified place.
However, this would still break the existing code, and moreover
does not address the underlying problem: that the option parsing
of the OCaml compiler driver is confusing and prone to creating
latent bugs.
Instead, this commit finishes (after 1d8e590c and 55d2d420) overhauls
the way option parsing in ocamlc/ocamlopt works to behave as follows:
* options are parsed left-to-right in the order they are specified;
* after all options are parsed, arguments are parsed left-to-right
in the order they were specified;
* when "-o out" and "-c" are specified:
* when more than one file is passed, an error message
is displayed.
* when one file is passed:
* "foo.c" is compiled to "out";
* "foo.ml" is compiled to "out.cmo"/"out.cmxo".
* when "-o out" is not specified or "-c" is not specified:
* "foo.c" is compiled to "foo.o" in current directory;
* "foo.ml" is compiled to "foo.cmo"/"foo.cmxo"
in current directory;
* when "-c" is not specified:
* after all files have been compiled, if any .ml files are passed,
all provided files are linked as:
* when "-o" is not specified: "a.out" in current directory;
* when "-o out" is specified: "out".
In short, the combination of "-o", "-c" and a single source file
compiles that one file to the corresponding intermediate
build product. Otherwise, passing "-o" will either set the name of
the final build product only or error out.
This preserves compatibility with old code, makes the handling of
C and OCaml sources consistent, and overall makes the behavior
of the option parser more straightforward. However, this may break
code that relies on the fact that options are parsed in-order, e.g.
ocamlc -o t a.ml -g b.ml
where debug info would be built only for "b.ml".
Some alternative implementation paths I have considered:
* Collect the C sources and process them after OCaml sources,
while paying attention to any "-o" or "-c" that may have
been set. This doesn't work because compilation of C sources
is also affected by many flags, e.g. "-I", and so this would
have the same drawbacks but none of the benefits;
* Compile C and OCaml sources in-order as usual, but error out
when an improper combination of flags is encountered in
the middle of a compilation. This is technically feasible,
and is the option that maximally preserves compatibility, but
it is very complex: it doubles the amount of implicitly mutated
global state, and there's no guarantee I will get all edge
cases right. Moreover, the option parsing remains confusing,
and I strongly believe that the current behavior should not
remain in place.
On top of that it is hard to imagine cases where setting new options
in the middle of compilation would actually be desirable, because
this mechanism is very inexpressive: it can only add new options and
option values, since there is no way to negate or clear most of
the driver's state. Most likely is that any code that does so,
does it in error and remains operational by pure chance.
The behavior of ocamlc and ocamlopt drivers before this commit is
that the command-line options and arguments are processed exactly
sequentially; encountered options (e.g. "-o") modify the state of
the driver, and encountered arguments (e.g. "t.ml") compile
the corresponding file with whatever state the driver had at the time.
This can be quite confusing, because compiler drivers (e.g. gcc/g++,
clang/clang++, rustc, javac, go, ...) either parse the entire command
line before going on to compile files or reject options after
the first argument (only in the case of go). Thus the behavior
of ocamlc and ocamlopt is unexpected.
The following commit provides another reason for this change.
This module checks all the AST invariants. This is to ensure that all
invariants are written down in one place and are consistently checked
between the various clients of the AST (typer, pprintast, ...).
The invariants are checked in Pparsee, after applying the ppx
rewriters.
(Simon Cruanes and Gabriel Scherer)
Use one of
-color auto
-color always
-color never
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16348 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This should cover all places involving filenames in the compiler.
There are a few more paths still using Latin-1 in other ways,
e.g. in ocamldoc.
From: Peter Zotov <whitequark@whitequark.org>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15727 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Patch by Pierre Chambart and Gabriel Scherer)
(Ack'ed by Damien Doligez)
This enables a form of incremental compilation for ocamlopt: if
A depends on B, and B is compiled with `ocamlopt -opaque`, then minor
implementation changes in B that do not affect the module interface
will not require recompilation of A.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15105 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Reuses results of previous computations instead of recomputing them.)
(Cherry-picked from branch backend-optim.)
Tested on amd64/linux and i386/linux.
Other back-ends compile (after assorted updates) but are untested.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14688 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Constant propagation for floats can be turned off with option
-no-float-const-prop, for codes that change FP rounding modes at
run-time.
- Clambda / C-- / Mach: represent float constants as FP numbers of type
float rather than literals of type string.
- Tested for AMD64; other archs need testing.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14673 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
14278
14277
14276
14176
14175
14173
14172
14171
14169
14168
14167
These changes need to mature on their own branch.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14329 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This script was built from ocamlcomp.sh.in through sed and is called
instead of "ocamlc" (for instance).
It makes it possible to switch from "ocamlc" to "ocamlc.opt" without
changing anything in the Makefiles, only calling sed.
I couldn't cleanly make it handle both a compiler for the target and for
the build. Instead I'm replacing it and doing as much as possible
directly in the Makefiles.
I hoped it would reduce the number of shell invocations, which would
speed things up quite a lot on Windows but I still had to have at least
one since it's not possible to update a make variable from inside a make
rule: i.e. it's not possible to do X=a, build a.opt and update X to be
a.opt.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14168 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02