Reader supports poorly defined regexes that break code

Description

I ran into a strange case where CLJS emitted invalid code based on a poorly formatted regex that escaped / incorrectly.

Looking at such a regex, along with two similar but well formed regexes, passing through tools.reader:

But what does

mean here?

Looking at Clojure execution of these regexes:

ie.

behaves exactly like

Things get more unfortunate once CLJS get's involved, it does not expect the "heisen" regex - and the "dangling escape" ends up capturing the forward slash's escape, ie. an prematurely terminating regex is emitted.

Despite Clojure's existing "fortuitous" behaviour, perhaps the correct behaviour is to throw a reader exception for such regexes, as it does for

Alternatively, if

remains supported (for familiarity with users used to /.../ syntax), then the reader should emit

not

as the string value of the literal, ie. this "tolerance" should be part of the reader semantics rather than a concern for emitters.

See http://dev.clojure.org/jira/browse/CLJS-1399

Environment

None

Assignee

Nicola Mometto

Reporter

Jeff Palentine

Labels

None

Approval

None

Patch

None

Priority

Minor
Configure