Skip to content

String.split(x: Array[Char]) produces bad regexes #105

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gzm0 opened this issue Jan 11, 2014 · 8 comments · Fixed by #4455
Closed

String.split(x: Array[Char]) produces bad regexes #105

gzm0 opened this issue Jan 11, 2014 · 8 comments · Fixed by #4455
Assignees
Labels
bug Confirmed bug. Needs to be fixed.
Milestone

Comments

@gzm0
Copy link
Contributor

gzm0 commented Jan 11, 2014

Just like split(x: Char) (see #65), StringLike relies on the \Q, \E escapes for Regex creation. We now have to deal with the following pattern:

[\Q<char>\E\Q<char>\E<etc>]

This produces regexes such as:

[\Q-\E]

Which then cause an exception in the JavaScript regex matcher.

@sjrd Should we handle this as a hack just like #65, knowing that this is substantially more complex?

@ghost ghost assigned gzm0 Jan 11, 2014
@sjrd
Copy link
Member

sjrd commented Jan 11, 2014

Why is this more complex?

@gzm0
Copy link
Contributor Author

gzm0 commented Jan 11, 2014

Sorry, I wasn't expressing myself very clearly: I meant the regex creation at runtime will become more complex and hence slower.

@sjrd
Copy link
Member

sjrd commented Jan 11, 2014

Hum ... I don't know. I wouldn't care if that particular method was slow, but IIUC, in order to support it, we would have to slow down all regex creations, which is not a good idea.

@gzm0
Copy link
Contributor Author

gzm0 commented Jan 11, 2014

Exactly. We already do this to support split(x: Char), but what we have to match against is less complex. We might have no choice but to re-implement StringLike. :(

@jonas
Copy link
Contributor

jonas commented Jan 12, 2014

FYI, to avoid duplicate work, I am creating a test suite for the Java regexp emulation. My plan is to post a pull request today.

@gzm0
Copy link
Contributor Author

gzm0 commented Jan 13, 2014

Originating partest: run/t0325.scala

@gzm0
Copy link
Contributor Author

gzm0 commented Jan 13, 2014

As discussed with @sjrd, we will currently not support this. Leaving open until properly documented.

@sjrd
Copy link
Member

sjrd commented Mar 28, 2021

This would be fixed by #4455 as well.

(This means the Semantics page on the website should be updated if/when we merge it.)

sjrd added a commit to sjrd/scala-js that referenced this issue Apr 16, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical fullOpt output is approximately 12 KB.

The source of `PatternCompiler` contains an extensive explanation
of the design of the compiler, and of how it compiles each kind of
Java pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 17, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical fullOpt output is approximately 12 KB.

The source of `PatternCompiler` contains an extensive explanation
of the design of the compiler, and of how it compiles each kind of
Java pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 17, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical fullOpt output is approximately 12 KB.

The source of `PatternCompiler` contains an extensive explanation
of the design of the compiler, and of how it compiles each kind of
Java pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 17, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical fullOpt output is approximately 12 KB.

The source of `PatternCompiler` contains an extensive explanation
of the design of the compiler, and of how it compiles each kind of
Java pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 18, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical fullOpt output is approximately 12 KB.

The source of `PatternCompiler` contains an extensive explanation
of the design of the compiler, and of how it compiles each kind of
Java pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 18, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical fullOpt output is approximately 12 KB.

The source of `PatternCompiler` contains an extensive explanation
of the design of the compiler, and of how it compiles each kind of
Java pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 18, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical fullOpt output is approximately 12 KB.

The source of `PatternCompiler` contains an extensive explanation
of the design of the compiler, and of how it compiles each kind of
Java pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 19, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 19, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 20, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 21, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 21, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 22, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 22, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 23, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 25, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 25, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 26, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 26, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Apr 26, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue May 2, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue May 6, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue May 19, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue May 22, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Jun 9, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Jun 10, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Jun 10, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Jun 14, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Jun 24, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Jun 28, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Jul 6, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
sjrd added a commit to sjrd/scala-js that referenced this issue Jul 7, 2021
Previously, `java.util.regex.Pattern` was implemented without much
concern for correctness wrt. the Java semantics of regular
expressions. Patterns were passed through to the native `RegExp`
with minimal preprocessing.

This could cause several kinds of incompatibilities:

- Throwing `ParseError`s for features not supported by JS regexes,
- Or worse, silently compile with different semantics.

In this commit, we correctly implement virtually all the features
of Java regular expressions by compiling Java patterns down to JS
patterns with the same semantics.

This change introduces a significant code size regression for code
bases that were already using `Pattern` and/or Scala's `Regex`.
Therefore, we went to great lengths to optimize the compiler for
code size, in particular in the default ES 2015 configuration. This
means that some code is not as idiomatic as it could be. The impact
of this commit on a typical output is approximately 65 KB for
fastOpt and 12 KB for fullOpt.

The `README.md` file contains an extensive explanation of the
design of the compiler, and of how it compiles each kind of Java
pattern.

In addition to fixing the mega-issue scala-js#1201, this commit fixes the
smaller issues scala-js#105, scala-js#1677, scala-js#1847, scala-js#2082 and scala-js#3959, which had been
closed as duplicates of scala-js#1201.
@sjrd sjrd removed the wontfix We decided not to fix this issue/not implement that feature request. label Jul 8, 2021
@sjrd sjrd added this to the v1.7.0 milestone Jul 8, 2021
@sjrd sjrd assigned sjrd and unassigned gzm0 Jul 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bug. Needs to be fixed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants