Improved regexp/strict rule

[RunDevelopment]

This adds the logic I was talking about here. Many reports are fixable. Only reports that are likely a but are not fixable.

However, there is still one problem with this: the tests don't pass because RegExpValidator says that /(?<foo>)\k<foo>/ isn't valid. I have no idea why it rejects that regex. Do you know why @ota-meshi?

[ota-meshi]

/(?<foo>)\k<foo>/ isn't valid

I think it's probably an invalid regular expression because of backward compatibility.

However, the named backreference syntax, /\k<foo>/, is currently permitted in non-Unicode RegExps and matches the literal string "k<foo>". In Unicode RegExps, such escapes are banned.

https://github.com/tc39/proposal-regexp-named-groups#backwards-compatibility-of-new-syntax

I'm not sure if it's valid as a strict non-Unicode regular expression.

[RunDevelopment]

v8 will happily execute that regex. Example:

Node.js v14.15.4.
> /^(?<foo>A)\k<foo>$/.test("AA")
true

It should be valid because:

In this proposal, \k<foo> in non-Unicode RegExps will continue to match the literal string "k<foo>" unless the RegExp contains a named group, in which case it will match that group or be a syntax error [...]

And I think, I figured out why regexpp throws an error. It's a bug in regexpp's validator: mysticatea/regexpp#23.

Now we have two option:

1. Wait until the bug is fixed.
2. Publish regexp/strict without RegExpValidator and re-add it later when the bug is fixed.

Which one do we want to choose?

[ota-meshi]

I heard a rumor that mysticatea seems to be busy these days and doesn't have time to maintain OSS.
I don't know if he will reply, but I will try to send him a message via chat.

[RunDevelopment]

I see. Thank you @ota-meshi!

In that case, I'll disable the RegExpValidator-based check for patterns with named backreferences. We can re-add it as soon as the bug is fixed.

[ota-meshi]

Thank you very much!