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.