ping :)

Make Zmmul extension independent instead of implied by M extension for backward ELF attribute compatibility.

The Zmmul extension has just ratified. Update patch to rebase to current main.

Ok then I would only do that.

Thanks for the review and it sounds a good rationale. I am also wondering whether only changing errs to dbgs on the original code without changing other parts or using helper function a good change for consistency with other code?

Apply suggestions from clangfmt

Thanks!

Fix patch apply failed

Rebase and adapt to new ISAInfo module.

In D118869#3359439, @krasimir wrote:

It appears that this caused a regression by adding an additional space of indentation to line comments in some cases:

% cat test.cc  # (before)
// Comment
int i;
% clang-format -style=google test.cc
//  Comment
int i;

@ksyx could you please take a look?

In D103313#3359310, @JiahaoChenConor wrote:

Hi, do you still continue working on this patch?

Use for loop to go through tokens in a line.

• Remove else after return

• Add or remove empty lines surrounding unions.
• Move new test location.
• Remove else immediately above return.

Related discussion: https://reviews.llvm.org/D92257#3252060

In D117520#3263403, @MyDeveloperDay wrote:

maybe slightly related https://github.com/llvm/llvm-project/issues/53183 in that this is also impacted by the 5 character TT_FunctionLikeOrFreestandingMacro

Apply review suggestions of renaming.

Add token type FunctionLikeOrFreestandingMacro and use it to replace duplicated check with UnwrappedLineParser

In D117520#3260443, @curdeius wrote:

In D117520#3258454, @MyDeveloperDay wrote:

I think its been fixed, in the last but one diff.

Generally speaking we simply cannot have --output-replacements-xml , -n or --dry-run show replacements that amount to nothing because this is the mechanism by which 100s of repos fail commits thinking their is a clang-format issue.

Last revision I tried these issues seem to have disappeared

I understood that it was fixed but I'd really like to have a test case that reproduces it.
We might have the same problem somewhere else, no?
Can we have a part of verifyFormat that runs with DryRun=true and checks the replacements?

Add unit test for formatting conflict

Apply suggestion from clangfmt

• Apply suggestions from clangfmt
• Split assertion conditions

Recognize long (len>=5) uppercased name taking a single line as return type
and fix the problem of adding newline below it:

void
afunc(int x) {
  return;
}
TYPENAME
func(int x, int y) {
  // ...
}

• Resolves formatting conflict with options EmptyLineAfterAccessModifier and EmptyLineBeforeAccessModifier (prompts with --dry-run (-n) or --output-replacement-xml but no observable change)
• Remove redundant and repeated initialization
• Do no change to newlines before EOF

In D117520#3251425, @MyDeveloperDay wrote:

For

class Test
{
public:
    static void foo()
    {
    }
};

$ clang-format -n test.cxx
test.cxx:3:8: warning: code should be clang-formatted [-Wclang-format-violations
]
public:
       ^

$ clang-format --output-replacements-xml test.cxx
<?xml version='1.0'?>
<replacements xml:space='preserve' incomplete_format='false'>
<replacement offset='20' length='5'>&#10;    </replacement>
</replacements>

but when I run it nothing changes

$ clang-format test.cxx
class Test
{
public:
    static void foo()
    {
    }
};

And no character change

In D117520#3251376, @MyDeveloperDay wrote:

I'm getting some sort of seemingly empty replacements going on, after public: I can't quite put my finger on what's happening.

• Use function keyword for JavaScript instead of comparing strings
• Apply review suggestions

Apply clangfmt's suggestion.

In D92257#3004563, @HazardyKnusperkeks wrote:

In D92257#3003281, @byronhe wrote:

Hi guys，i found SpacesInLineCommentPrefix does not support other encoding such as utf8 ，
I am curious why there is a isAlphanumeric limit in BreakableLineCommentSection::BreakableLineCommentSection() ?
I want to make some contribution to make it support utf8, what should i do ?

The isAlphanumeric is there to not break doxygen like comments for example.

I'm very interested in how you want to tackle that problem. :)

• add comments for direction = 0
• use true/false instead of 0/1
• rebase

Hi, just to confirm, are there anything needed to be improved for this patch or it is ready to be committed? Thanks

I see your point, but I think the problem is more likely to be coming from the token annotator that detected it as a macro and just start a new line?

In D116663#3227813, @MyDeveloperDay wrote:

I think that perhaps

if (Style.SeparateDefinitionBlocks != FormatStyle::SDS_Leave)
  Passes.emplace_back([&](const Environment &Env) {
    return DefinitionBlockSeparator(Env, Expanded).process();
  });

Should be moved to After the Formatter pass, thoughts?

Seems like this is intent for dealing with macro but somehow went into return type

In D116663#3227691, @MyDeveloperDay wrote:

Seem related to the number of characters used in the type?

void foo()
{}

LRES
Foo::func() {}

LRESU

Foo::func() {}

----
AnnotatedTokens(L=0):
 M=0 C=0 T=Unknown S=1 F=0 B=0 BK=0 P=0 Name=identifier L=4 PPK=2 FakeLParens= FakeRParens=0 II=0x1592cb8 Text='LRES'
 M=1 C=1 T=FunctionDeclarationName S=1 F=0 B=0 BK=0 P=80 Name=identifier L=84 PPK=2 FakeLParens= FakeRParens=0 II=0x1592cf0 Text='barbabararr'
 M=0 C=0 T=Unknown S=0 F=0 B=0 BK=0 P=23 Name=l_paren L=85 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text='('
 M=0 C=0 T=Unknown S=0 F=0 B=0 BK=0 P=140 Name=r_paren L=86 PPK=2 FakeLParens= FakeRParens=0 II=0x0 Text=')'
----

rebase

In D116663#3227029, @MyDeveloperDay wrote:

HRESULT
Foo::func()
{
}

becomes

HRESULT

Foo::func() {}

• Use prefix inc/dec
• Not run test in lambda

In D116663#3227022, @MyDeveloperDay wrote:

This shows some other failure scenarios

https://github.com/llvm/llvm-project/issues/45895

apply suggestion from clangfmt.

apply suggestion from clangfmt.

Apply suggested behaviour and fix misrecognition of token namespace

In D116663#3222714, @MyDeveloperDay wrote:

namespace {
<--- extraneous newline will be removed (just checking if thats what we want?)  shouldn't it honour MaxEmptyLines?  
   /*  foo */
   void foo()
   {
   }
<--- extraneous newline will be removed (just checking if thats what we want?)  shouldn't it honour MaxEmptyLines?
}

Apply most suggestions

apply clangfmt suggestions.

Fix failing when the first line of body is comment.

failed on dealing with classes.

In D116314#3221488, @MyDeveloperDay wrote:

@ksyx

Did you see this issue https://github.com/llvm/llvm-project/issues/52976

In its current form, this patch causes huge amounts of flux in projects
that document code like (anyone using doxygen likely, + most normal people
;-) )

...
}

// My function
<<<<-------- extra newline added
void
foo()
{
}

as it will place and undesirable additional newline between the function
and the return type.

We really need this to be resolved before we branch out v14 (which may be
imminent)

MyDeveloperDay

Thanks for the fix!

Thanks for the fix :)

Add release note entry.

Change the SDS_Leave style check to be assert not having this style.

Use reformat method instead of calling the single method only.

Change lambda variable names' leading letter to uppercase.

Change lambda variable names' leading letter to uppercase.

• Apply review suggestions.
• Assert the style is not SDS_Leave in private method, while return no change in public method if so.
• Rename loop variable Line to CurrentLine

minor fixes.

Apply suggestion from clangfmt

Apply clangfmt's suggestions

• Improve compatibility to other languages
• Improve unit test by test format stability, inverse result, and generate some input from expected output
• Reformat sample code
• Use more concise word for SDS_Leave

Fix typo.

• Apply suggestions from clangfmt
• Add missing period of comments
• Fix namespace ending comment
• Add comment for notes on return value of WhitespaceManager's method

• Change version from 15 to 14
• Add option SDS_Never, rename SDS_Between => SDS_Always
• Add unit tests
• Separate class into new file

• Change bool type of the option to enum type
• Generate empty line for enum block

Fix missing semicolon in sample/test code