* Move driver code from Cmt2annot to Read_cmt
* Move cmt2annot.ml into typing/
* make depend
* Use standard error handling
* Move specific logic to read_cmt
* Do not pass full cmt record as argument
* Better locations
* Emit .annot files produced from cmt data
* Remove direct calls to Stypes
* Deprecate -annot
* Changes
* make depend
* Adapt doc
* make -C tools depend
Warning 30 warns when the same constructor/label is used in two
mutually-recursive type declarations. This warning (added in OCaml
3.12, 2010) was meaningful at the time where constructor/label
conflicts had a shadowing semantics: the "last" definition would mean,
while ideally mutually-recursive definitions should not be strictly
ordered but defined "all at once".
Since OCaml 4.01 (2013) we support type-based disambiguation of
constructor/label names and it is now common to write code such as,
say
type pattern = Var of var | ...
type expr = Var of var | ...
(no warning, of course). But warning 30 fires if you instead write
type pattern = Var of var | ...
and expr = Var of var | ...
This doesn't make much sense, and in particular it certainly makes no
sense to enable this warning by default. The present PR disables it by
default.
After consultation on the core developers' list I am proposing this patch to remove support for compiler plugins.
The main motivations for removing compiler plugins are:
- They are a potential security risk.
- They increase the complexity of the build system and make maintenance of the Dynlink libraries more difficult (although actually, this complexity could probably be reduced after #2268 is merged).
- Many applications of plugins should be able to be expressed by building custom compiler drivers that link against compilerlibs.
* Remove compiler plugins and hooks
* Add new function Dynlink.unsafe_get_global_symbol but keep it outside the documented API.
* Remove otherlibs/dynlink/nodynlink.ml
* Update Changes
* Delete the deprecated vmthreads library
It was deprecated in 4.08.
* Remove the byte/native argument of init_path
It is no longer necessary.
* Error out when passing --{enable,disable}-vmthreads to ./configure
Signed-off-by: Jeremie Dimino <jeremie@dimino.org>
These are most likely a mistake for "type t = unit", but still valid, and lead
to quite confusing error messages afterwards because now `()` denotes two
different incompatible constructors.
Instead of the current print to stderr. This way it's treated the same
as other warnings: it has a position, colors, can be made an error,
disabled, goes in the expected formatter, is documented.
Nearly identical changes to:
ocaml.m, ocamlc.m, ocamlopt.m, unified-options.etex
"-safe-string" has been the default since 4.06, so the assertion that
it would be the default someday, and that "-unsafe-string" is still
the default, was incorrect.
The proposed behavior of `-config-var s` is as follows:
- if `s` is an existing configuration variable, print its value as
a string and exit with a success return value (0)
- if `s` is not an existing configuration variable, print nothing
and exit with a failure return value (non-0)
Note that we do not print a newline after the value of the
configuration variable. In particular, if the value is an empty
string, the output is undistinguishable from the output for
non-existing variables, the return value has to be considered instead.
The following alternative behaviors were considered:
- We could print a newline after the configuration value, which
would let users distinguish empty values from non-existing variables
by counting the lines of output, and would also be more pleasant for
users invoking the option from the command-line. However, the way
bash works on Windows means that $(ocamlc -config-var foo) would keep
a trailing \r in its output, and portable scripts would have to use
$(ocamlc -config-var foo | tr -d '\r') instead, which is a pain.
(This issue was pointed out by David Allsopp)
- We could print a message on the error output if the configuration
variable does not exist. This is clearer to a human user, but it is
annoying for scripts if they forget to silence the error output and
get their output mixed with our error messages. The main use of this
new feature is for scripting purposes.
* fall back to __secure_getenv when secure_getenv is not available
* use secure_getenv for instrumented runtimes
* documentation: warn against setting the setuid or setgid bits on custom bytecode executables
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.
hhugo
Krzysztof Leśniak
muskangarg21
Nicolás Ojeda Bär
Andre
Gabriel Scherer
Lucas Pluvinage
Mark Shinwell
Jérémie Dimino
Alain Frisch
Armaël Guéneau
Valentin Gatien-Baron
Dwight Guth
Perry E. Metzger
Leo White
Thomas Refis
Damien Doligez
Fabrice Le Fessant
Hannes Mehnert
Konstantin Romanov
Xavier Leroy
Damien Doligez
whitequark
Simon Cruanes
Mark Shinwell
Damien Doligez
Jacques Garrigue