In D68054#1801066, @thopre wrote:

How about the following commit message:

(...)

In D68054#1755059, @thopre wrote:

Not committing to remove the ability to call match/sub on an invalid regex implies that the addition of the new API needs to be justified independently of the extra check that needs to be performed in match/sub to allow the current behaviour. And in fact, the only motivation for this patch I could think of was consistency with other languages and I was finding it a hard sell and was about to apologise for the extra work I made you do.

However I overlooked one benefit of removing the ability to match an invalid regex: robustness. All the cases where a call to match/sub is guards a code other than throwing an error is likely to result in wrong behaviour in case the regex is invalid. So I think it would be safer to use a separate API for combined regex creation + match/sub as per the previous revision of this patch and prevent the existing approach, so that users are mindful when not doing separate checks.

What do you think? If you agree that would mean reverting to the previous version of this patch and the simultaneous apologies from me for requesting the current version.

In D68155#1751826, @thopre wrote:

My sincere apologies, I forgot to change the author in the commit. I don't often commit on behalf of others so didn't think enough.

In D68054#1751415, @thopre wrote:

In D68054#1750788, @nlguillemot wrote:

Removed the assert inside match() that made it crash when match() is called with a regex pattern that isn't successfully compiled. Also removed the "death test" unit tests that tested that this assert was triggering.

Can you reword the description along the line of this new API being a convenience when one does not care about distinguishing validity of a regex from whether it matches?

Removed the assert inside match() that made it crash when match() is called with a regex pattern that isn't successfully compiled. Also removed the "death test" unit tests that tested that this assert was triggering.

Opened a review that just increases the const-correctness of Regex in clang: https://reviews.llvm.org/D68155

In D68054#1685676, @thopre wrote:

The following clang unit tests fail with your patch:

Format/./FormatTests/FormatTest.FunctionAnnotations
Format/./FormatTests/FormatTest.UnderstandsFunctionRefQualification

Can you have a look?

• Added more comments to static match and static sub to clarify the return value and the error's value.
• Remove updates of "static Regex" -> "static const Regex", to do them in a future separate patch instead.
• Switch order of test lines in "ConvenienceFunctions" test.

In D67241#1679847, @thopre wrote:

In D67241#1679348, @nlguillemot wrote:

friendly reminder ping

My bad, I misunderstood you and thought you'd do a patch to implement the "Create a Regex and immediately throw it away" idiom and rebase that one on top of it.

friendly reminder ping

Refactored loop over the list of vectors to avoid the tricky array/pointer loops.

Added note in the comments for match and sub to explicitly note that the Error string is cleared when there is no error.

I don't have commit privileges yet. Could somebody commit this for me?

Could somebody do the commit for me? I don’t have commit access yet.

ping

ping

ping

In D63320#1549309, @craig.topper wrote:

Can the enum be used without this? I'm trying to understand why the enum was there to begin with. Only one in tree target, AVR, defines GET_INSTRINFO_OPERAND_TYPES_ENUM. Its not built by default so I could't really check, but looking through the file that included it, I couldn't prove it was being used.

some syntax nits:
OpcodeOperandTypes [] -> OpcodeOperandTypes[] (removed unnecessary space)
OS << "-1"; -> OS << -1; (don't use string where not necessary

• Fix some syntax mistakes.
• Map only records that derive from Operand and are not anonymous. This exactly matches the condition used to generate GET_INSTRINFO_OPERAND_TYPES_ENUM.