What flavor of Regex does Visual Studio Code use?

Question

Trying to search-replace in Visual Studio Code, I find that its Regex flavor is different from full Visual Studio. Specifically, I try to declare a named group with string (?<p>[\w]+) which works in Visual Studio, but not in Visual Studio Code. It'll complain with the error Invalid group.

Apart from solving this specific issue, I'm looking for information about the flavor of Regexes in Visual Studio Code and where to find documentation about it, so I can help myself with any other questions I might stumble upon.

Full Visual Studio uses .NET Regular Expressions as documented here. This link is mentioned as the documentation for Visual Studio Code elsewhere on Stack Overflow, but it's not.

Wrest

VSCode is using JavaScript-based regex engine, but it is not the same. You cannot use named capturing groups there. – Dastard

There is no specific documentation on the regex used in VSCode. However, if you have a look at the source code, you will see lots of JS code around. If you try using lookbehinds, you get invalid pattern error, while lookaheads work. And the JS regex flavor is the only regex engine that treats [^] pattern as matching any symbol. So, it is clear it is JS regex engine. – Dastard

What is your real problem? Note you do not need the named capturing groups usually, that is just a "perk". – Dastard

The standard is ECMAScript 5. – Dastard

OK. Well if you're sure and you have some links to docs you can answer. I'll upvote. Don't think the ECMAScript spec is a great link if it's the only one though. – Wrest

So, what kind of answer do you expect? All what I posted above + link to the JS regex syntax description? Like MDN reference? – Dastard

Answer 1

Rust Regex in the Find/Replace in Files Sidebar

Rob Lourens of MSFT wrote that the file search uses Rust regex. The Rust language documentation describes the syntax.

JavaScript Regex in the Find/Replace in File Widget

Alexandru Dima of MSFT wrote that the find widget uses JavaScript regex. As Wicktor commented, ECMAScript 5's documentation describes the syntax. So does the MDN JavaScript Regular Expression Guide.

Test the Difference

The find in files sidebar does not support (?=foobar) whereas the find in file widget does support that lookahead syntax.

Regarding Find/Replace with Groups

To find/replace with groups, use parentheses () to group and $1, $2, $3, $n to replace.

Here is an example.

Before:

After:

Clearcut

It's possible to debug regex here: rustexp.lpil.uk – Pellerin

Not true anymore github.com/microsoft/vscode/issues/72459 – Lobito

@rofrol: What isn't true anymore? Can you elaborate? – Indescribable

@PeterMortensen You can now use lookaround (also negative) in the search sidebar. – Aloin

This is now a backlog candidate: Regex Find/Replace with named capture groups – Doggett

Answer 2

Shaun's answer is still correct, however to add an update, recently VS Code added the option to opt into using the Perl based PCRE2 engine. You can enable this through your settings config.

This allows you to perform more advanced regex operations like lookaheads and backreferences. But as noted below, the regex still has to be valid JavaScript regex.

VS Code does support regular expression searches, however, backreferences and lookaround aren't supported by default. But you can enable these with the setting search.usePCRE2. This configures ripgrep to use the PCRE2 regex engine. While PCRE2 supports many other features, we only support regex expressions that are still valid in JavaScript, because open editors are still searched using the editor's JavaScript-based search.

And for a bonus if you ended up here trying to do multi line searches, VS Code recently added that feature as well!

Levitus

PCRE2 can be activated in the settings menu. Go to Preferences~Settings and search for 'regex' – Engineering

Looks like that setting is deprecated, and PCRE2 is automatically used as fallback when the default engine doesn't support a feature. – Blythebm

i don't see how to enable this.. I search for regex and see only two matches and pcr and cannot find anything . – Opsis

Answer 3

I've found newer information (July 22, 2020) about it.

IllusionMH left the following comment on GitHub:

ripgrep (compatible with PCRE2) is already used for Find in files functionality (for not open editors) and JS engine used only for open editors.

Maxfield

Answer 4

Which regex engine does Visual Studio Code use? It is now a little more nuanced than previously. The best source is this Visual Studio Code wiki: GitHub wiki: Notes on Regular Expression Support:

[At the top of the document]

This document applies to search (CMD+SHIFT+F/CTRL+SHIFT+F) and quickopen (CMD+P/CTRL+P). By default, VS Code uses the ripgrep tool to drive search.

...

[At the end of the document]

Text search uses two different sets of regular expression engines. The workspace is searched using ripgrep, which will use the Rust regex engine, and will fallback to PCRE2 if the regex fails to parse in the Rust regex engine. The Rust regex engine doesn't support some features like backreferences and look-around, so if you use those features, PCRE2 will be used. Open files are searched using a JS regex in the editor itself. Most of the time, you don't need to worry about this, but you may see an inconsistency in how some complex regexes are interpreted, and this can be an explanation. Especially when you see a regex interpreted one way when a file is open, and another way when it is not. During a Replace operation, each file will be opened in turn, and the search query will be run as a JS regex.

Another potential issue is how newlines are handled between ripgrep and the editor. The editor normalizes newlines, so that you can match both CRLF and LF line endings just with \n. It's actually not possible to match \r explicitly in the editor because it is normalized away. When searching in the workspace, VS Code tries to rewrite a regex so that \n will match CRLF. But \r\n or \s\n will also match CRLF in closed files, but not in open files.

Two key points: (1) newlines are handled specially and (2) backrefereences and look-arounds are supported despite using the Rust regex engine - if your regex has a look-around or backreference in it PCRE2 will be used instead of the Rust engine.

---

More on lookarounds

The Find Widget (Ctrl + F) used for finding within the active editor only supports all lookarounds (lookahead and lookbehind) and those lookarounds can be non-fixed-length. So this will work in the Find Widget: (?<!blah.*).

In a search across files (Ctrl + Shift + F) non-fixed-length lookbehinds do not work. Lookaheads can be fixed or non-fixed-length. But non-fixed-length positive or negative lookbehinds do not work and you will get an error message below the search input box: Regex parse error: lookbehind assertion is not fixed length which may not appear until you actually try to run the search.

Effectual