Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007637OCamllexing and parsingpublic2017-09-25 10:172017-10-20 11:08
Reporternojebar 
Assigned Togasche 
PriorityhighSeverityminorReproducibilityalways
StatusresolvedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target Version4.06.0 +dev/beta1/beta2/rc1Fixed in Version4.06.0 +dev/beta1/beta2/rc1 
Summary0007637: Breaking change in parser (probably related to GPR#1064 - Extended indexing operators)
Description4.05 accepted

  type t = < f: 'a.?foo:'a -> unit >

but 4.06 requires a space between '.' and '?':

  type t = < f: 'a. ?foo:'a -> unit >

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0018324)
frisch (developer)
2017-09-25 10:38
edited on: 2017-09-25 10:39

This is indeed an unfortunate side effect of GPR#1064. This PR adds support for things like "a.?(i)", but it does so by considering that ".?" is a token, thus breaking cases where the "DOTOP"" is not followed by (, { or [.

I can see two directions:

 1. Change the lexer to consider ".XXX(" (where XXX stands for a non-empty sequence of symbol characters) as a token, and similarly for { and [. This excludes whitespaces/comments before the parentheses (one could allow whitespaces by tweaking the lexer, but for comments it would be more ticky).

 2. Keep the current behavior, but document GPR#1064 as a breaking change in Changes.


2 is simpler and opens the door to other uses of the current DOTOP token in the grammar. My preference goes to it.

(0018325)
gasche (developer)
2017-09-25 10:52

I would also think of 2. as the best way forward, but I think we should evaluate the extent of the compatibility breakage on OPAM.
(0018328)
shinwell (developer)
2017-09-25 15:24

In general, I don't like enforcing whitespace conventions in the language, but given the situation we find ourselves in I wouldn't be opposed to one here. Morally speaking, there should be a space after that dot, IMO.
(0018336)
doligez (administrator)
2017-09-25 17:22

I'm running a test against OPAM now I'll report when it's done (probably tomorrow).
(0018338)
octachron (developer)
2017-09-25 17:29

In term of tests, I was thinking that testing "4.04.2+lexer changes" might be simpler: https://github.com/Octachron/ocaml/tree/indexop-test [^] .
(0018367)
octachron (developer)
2017-09-27 16:43

After a little bit of testing on my side with the above compiler patch over a subset of 1453(/1704) opam packages; I could only detect one syntax error failure, in the earley package.

Note that the missing 221 opam package were either not installable on version 4.04.2 (for 78 packages), missing hard to automate external dependencies (for 74 packages) or failed to build due to another kind of errors (for 69 packages), see https://gist.github.com/Octachron/e9691b3ea1c43463730349f806894050 [^] for the full list.
(0018369)
gasche (developer)
2017-09-27 16:46

I'm interested in the testing methodology, did you reuse Damien's opam-testing script or something else?
(0018371)
doligez (administrator)
2017-09-27 17:10

Same here, earley is the only package that breaks between before and after the merge of GPR#1064.

I got a strange error with gasoline.0.4.0, but I don't think it's related (and there is a newer version of gasoline anyway).
(0018372)
octachron (developer)
2017-09-27 17:26

Since I initially wanted to test few packages, I opted for a small hand written script: https://gist.github.com/Octachron/4c196486df168e2a0b68e7621e45c018 [^] .
(0018376)
ChriChri (reporter)
2017-09-28 06:51

The next version of earley will have no problem with that...
(0018595)
gasche (developer)
2017-10-19 17:08

Let's suppose that this breakage is not going to change (I updated the issue status accordingly). Do we need to document it better?
(0018605)
octachron (developer)
2017-10-20 11:08

I think that we need to mark the change as breaking at the very least:
https://github.com/ocaml/ocaml/pull/1438 [^] .

- Issue History
Date Modified Username Field Change
2017-09-25 10:17 nojebar New Issue
2017-09-25 10:29 frisch Target Version => 4.06.0 +dev/beta1/beta2/rc1
2017-09-25 10:38 frisch Note Added: 0018324
2017-09-25 10:39 frisch Note Edited: 0018324 View Revisions
2017-09-25 10:39 frisch Priority normal => high
2017-09-25 10:52 gasche Note Added: 0018325
2017-09-25 15:24 shinwell Note Added: 0018328
2017-09-25 17:22 doligez Note Added: 0018336
2017-09-25 17:29 octachron Note Added: 0018338
2017-09-27 16:43 octachron Note Added: 0018367
2017-09-27 16:46 gasche Note Added: 0018369
2017-09-27 17:10 doligez Note Added: 0018371
2017-09-27 17:10 doligez Status new => confirmed
2017-09-27 17:26 octachron Note Added: 0018372
2017-09-28 06:51 ChriChri Note Added: 0018376
2017-10-19 17:08 gasche Note Added: 0018595
2017-10-19 17:08 gasche Status confirmed => resolved
2017-10-19 17:08 gasche Fixed in Version => 4.06.0 +dev/beta1/beta2/rc1
2017-10-19 17:08 gasche Resolution open => won't fix
2017-10-19 17:08 gasche Assigned To => gasche
2017-10-20 11:08 octachron Note Added: 0018605


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker