Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: rust-lang/regex
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 1.8.0
Choose a base ref
...
head repository: rust-lang/regex
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 1.8.1
Choose a head ref
  • 6 commits
  • 8 files changed
  • 2 contributors

Commits on Apr 21, 2023

  1. doc: update MSRV in README 

    PR #980
    @atouchet
    atouchet authored Apr 21, 2023
    Configuration menu
    Copy the full SHA
    93316a3 View commit details
    Browse the repository at this point in the history

  2. impl: fix prefix literal matching bug 

    This commit fixes a bug where it was possible to report a match where
none existed. Basically, in the current regex crate, it just cannot deal
with a mixture of look-around assertions in the prefix of a pattern and
prefix literal optimizations. Before 1.8, this was handled by simply
refusing to extract literals in that case. But in 1.8, with a rewrite of
the literal extractor, literals are now extracted for patterns like
this:

    (?i:(?:\b|_)win(?:32|64|dows)?(?:\b|_))

So in 1.8, since it was still using the old engines that can't deal with
this, I added some extra logic to throw away any extracted prefix
literals if a look-around assertion occurred in the prefix of the
pattern. The problem is that the logic I used was "always occurs in the
prefix of the pattern" instead of "may occur in the prefix of the
pattern." In the pattern above, it's the latter case. So it slipped by
and the regex engine tried to use the prefix literals to accelerat the
search. This in turn caused mishandling of the `\b` and led to a false
positive match.

The specific reason why the current regex engines can't deal with this
is because they weren't designed to handle searches that took the
surrounding context into account when resolving look-around assertions.
It was a pretty big oversight on my part many years ago.

The new engines we'll be migrating to Real Soon Now don't have this
problem and can deal with the prefix literal optimizations while
correctly handling look-around assertions in the prefix.

Fixes #981
    @BurntSushi
    BurntSushi committed Apr 21, 2023
    Configuration menu
    Copy the full SHA
    f003d72 View commit details
    Browse the repository at this point in the history

  3. changelog: 1.8.1

    @BurntSushi
    BurntSushi committed Apr 21, 2023
    Configuration menu
    Copy the full SHA
    960aade View commit details
    Browse the repository at this point in the history

  4. regex-syntax-0.7.1

    @BurntSushi
    BurntSushi committed Apr 21, 2023
    Configuration menu
    Copy the full SHA
    31c8452 View commit details
    Browse the repository at this point in the history

  5. deps: bump regex-syntax to 0.7.1

    @BurntSushi
    BurntSushi committed Apr 21, 2023
    Configuration menu
    Copy the full SHA
    8a7cb64 View commit details
    Browse the repository at this point in the history

  6. 1.8.1

    @BurntSushi
    BurntSushi committed Apr 21, 2023
    Configuration menu
    Copy the full SHA
    4e29fce View commit details
    Browse the repository at this point in the history
Loading