Remove unnecessary Obj.magic.#81
Closed
Conversation
…werPC/BSD backtraces git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14854 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…g on extensible types git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14859 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This should make the type-checking of formats simpler and more robust:
instead of trying to find a pair as previously, we can now use the
path of the format6 type directly.
A nice side-effect of the change is that the internal definition of
formats (as a pair) is not printed in error messages anymore.
Because format6 is in fact defined in the CamlinternalFormatBasics
submodule of Pervasives, and has an alias at the toplevel of
Pervasives, error messages still expand the definition:
> Error: This expression has type
> ('a, 'b, 'c, 'd, 'd, 'a) format6 =
> ('a, 'b, 'c, 'd, 'd, 'a) CamlinternalFormatBasics.format6
> but an expression was expected of type ...
Passing the option `-short-paths` does avoid this expansion and
returns exactly the same error message as 4.01:
> Error: This expression has type ('a, 'b, 'c, 'd, 'd, 'a) format6
> but an expression was expected of type ...
(To get this error message without -short-paths, one would need to
define format6 directly in Pervasives; but this type is mutually
recursive with several GADT types that we don't want to add in the
Pervasives namespace unqualified. This is why I'll keep the alias
for now.)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14868 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…ccessing the x87 FP stack, which must not be eliminated. CSEgen: harden against the same x87-specific issue + against reuse of values in fixed hardware registers that were destroyed by a prior operation. git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14877 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14886 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
See the long comment in pervasives.ml for an explanation of the change. The short summary is that we need to prove more elaborate properties between the format types involved in the typing of %(...%), and that proving things by writing GADT functions in OCaml reveals that Coq's Ltac is a miracle of usability. Proofs on OCaml GADTs are runtime functions that do have a runtime semantics: it is legitimate to hope that those proof computations are as simple as possible, but the current implementation was optimized for feasability, not simplicity. François Bobot has some interesting suggestions to simplify the reasoning part (with more equality reasoning where I used transitivity and symmetry of the relation profusely), which may make the code simpler in the future (and possibly more efficient: the hope is that only %(...%) users will pay a proof-related cost). git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14897 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…nd record fields git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14902 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14904 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(thanks to Thomas Refis) git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14909 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
PR#6442: prevent re-sharing of "+0.0" and "-0.0". git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14917 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14919 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…ction git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14926 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
… Peter Zotov, github #54). git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14928 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…ove old HAVE_MKSTEMP conditional, rename HAVE_MKSTEMP -> HAS_MKSTEMP git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14930 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
… Mac OS X (PR 6196) git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14932 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…chitectures git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14940 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
PR#6082: on x86-32, enforce 16-byte stack alignment for compatibility with recent GCC and Clang. Win32/MSVC keeps 4-byte stack alignment. git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14944 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14945 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…from version/4.02.) git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14947 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
PR#6283: increase alignment to work around a linking error. git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14951 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
reducing world's sequentialization consistently improves parallel build times git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14971 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…scope (Backport from Jacques' commit 4.02@14921) git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14972 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
To be able to compile this patch, you should temporarily apply the following patch to bootstrap the format type change: > diff -Naur old/typing/typecore.ml new/typing/typecore.ml > --- old/typing/typecore.ml 2014-06-06 03:37:03.240926150 +0200 > +++ new/typing/typecore.ml 2014-06-06 03:37:24.696926699 +0200 > @@ -2956,7 +2956,7 @@ > | Theta rest -> > mk_constr "Theta" [ mk_fmt rest ] > | Formatting (fmting, rest) -> > - mk_constr "Formatting" [ mk_formatting fmting; mk_fmt rest ] > + mk_constr "Formatting_lit" [ mk_formatting fmting; mk_fmt rest ] > | Reader rest -> > mk_constr "Reader" [ mk_fmt rest ] > | Scan_char_set (width_opt, char_set, rest) -> Bootstrap process: make core apply the patch above make core make promote-cross make partialclean revert the patch above, apply the commit make partialclean make core make coreboot git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14973 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
PR#6211: in toplevel interactive use, bad interaction between uncaught exceptions and multiple bindings of the form "let x = a let y = b;;". git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14977 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
PR#6268: -DMODEL_$(MODEL) not passed when building asmrun/arm.p.o git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14979 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
…t Vaugon) The bootstrap procedure, as for commit trunk@14973 (see there for detailed build instructions), requires to first commit a temporary patch: > diff -Naur old/typing/typecore.ml new/typing/typecore.ml > --- old/typing/typecore.ml 2014-06-11 18:16:24.851647309 +0200 > +++ new/typing/typecore.ml 2014-06-11 18:15:50.075646418 +0200 > @@ -2758,16 +2758,9 @@ > let mk_int n = mk_cst (Const_int n) > and mk_string str = mk_cst (Const_string (str, None)) > and mk_char chr = mk_cst (Const_char chr) in > - let mk_block_type bty = match bty with > - | Pp_hbox -> mk_constr "Pp_hbox" [] > - | Pp_vbox -> mk_constr "Pp_vbox" [] > - | Pp_hvbox -> mk_constr "Pp_hvbox" [] > - | Pp_hovbox -> mk_constr "Pp_hovbox" [] > - | Pp_box -> mk_constr "Pp_box" [] > - | Pp_fits -> mk_constr "Pp_fits" [] in > let rec mk_formatting_lit fmting = match fmting with > - | Open_box (org, bty, idt) -> > - mk_constr "Open_box" [ mk_string org; mk_block_type bty; mk_int idt ] > + | Open_box _ -> > + assert false > | Close_box -> > mk_constr "Close_box" [] > | Close_tag -> > @@ -2950,6 +2943,19 @@ > mk_constr "Alpha" [ mk_fmt rest ] > | Theta rest -> > mk_constr "Theta" [ mk_fmt rest ] > + | Formatting_lit (Open_box (org, _bty, _idt), rest) -> > + mk_constr "Formatting_gen" [ > + mk_constr "Open_box" [ > + mk_constr "Format" [ > + mk_constr "String_literal" [ > + mk_string "<>"; > + mk_constr "End_of_format" []; > + ]; > + mk_string "@[<>"; > + ] > + ]; > + mk_fmt rest; > + ] > | Formatting_lit (fmting, rest) -> > mk_constr "Formatting_lit" [ mk_formatting_lit fmting; mk_fmt rest ] > | Formatting_gen (fmting, rest) -> git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14984 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
parsing/ast_mapper.ml
Outdated
Member
There was a problem hiding this comment.
Why is the comparison a <> here?
Author
There was a problem hiding this comment.
Just a typo. Thanks. I shouldn't have tested only with implementation file !
Member
|
I think that's a good thing indeed. |
ocamlbuild lazily traverses directory to build a vision of the filesystem tree in which the build happens. During that traversals, it parses any configuration file `_tags` it encouters. PR#6482 was caused by the fact that the configuration-parsing code used the relative path of the _tags file, which was correct at the time of traversal, but stale at the time the lazy thunk was in fact forced (a Sys.chdir had occured in between). The first fix is to detect when relative paths become stale, and use the correct absolute path in that situation. The reason why this lazy thunk was only forced after a Sys.chdir is that, at hygiene time, only the subtrees that are selected for hygiene checking are forced. It is an unexpected behavior that non-hygienic subtrees could remain unforced for so long (in particular, the semantics of parsing a configuration file only much later in the build process is more than unclear); this commit also removes this behavior by always forcing the whole traversed subtree just before hygiene. git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15000 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Typo in destroyed_at_alloc and destroyed_at_c_call, D17 was incorrectly claimed to be preserved. git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15007 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
PR#6460: runtime assertion failure with large [| e1;...eN |] float array expressions git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15011 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
PR#6484 and PR#6486: CSE across memory allocations can present the GC with memory roots that are illegal. Plus: lift the previous restriction that all arithmetic ops and loads have at most one result register, this isn't true for ARM with soft floats. Plus: code refactoring and more comments. git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15013 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Follow-up to commit 15012: keeping checkbound equations is useless when load equations have been forgotten, as all checkbounds involve a load of a block header. So, simplify things further by emptying the numbering after calls and allocs. git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15022 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Member
|
I would like to merge this patch in trunk, but it doesn't seem to apply cleanly anymore. Could you rebase? |
Two distinct calls to 'input_value' are probably less error prone that 6 use of 'Obj.magic'.
Author
|
I will reopen against trunk. |
chambart
pushed a commit
to chambart/ocaml-1
that referenced
this pull request
Aug 4, 2021
Import PRs 63, 96 (partially), 116, 284 and 324.
stedolan
pushed a commit
to stedolan/ocaml
that referenced
this pull request
Oct 5, 2021
Import PRs 63, 96 (partially), 116, 284 and 324.
EmileTrotignon
pushed a commit
to EmileTrotignon/ocaml
that referenced
this pull request
Jan 12, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two distinct calls to 'input_value' are probably less error prone than 6 call to 'Obj.magic'.