aaron.ballman (Aaron Ballman)
User

Projects

User does not belong to any projects.

User Details

User Since
Mar 14 2013, 3:16 PM (239 w, 3 d)

Recent Activity

Today

aaron.ballman accepted D38969: Sort Attributes by "HeaderName" .

LGTM, thank you!

Mon, Oct 16, 1:29 PM
aaron.ballman accepted D38970: Clarify the 'interrupt' names in Attribute Docs.

LGTM, thank you!

Mon, Oct 16, 1:02 PM

Yesterday

aaron.ballman added a comment to D36836: [clang-tidy] Implement readability-function-cognitive-complexity check.

(I've not had the chance to complete a full review, but these are some thoughts thus far.)

Sun, Oct 15, 9:01 AM · Restricted Project
aaron.ballman closed D37436: Initial implementation of C attributes (WG14 N2137).

I've commit in r315856, thank you for the reviews!

Sun, Oct 15, 8:01 AM
aaron.ballman added inline comments to D38396: [clang-tidy] introduce legacy resource functions to 'cppcoreguidelines-owning-memory'.
Sun, Oct 15, 7:49 AM
aaron.ballman added inline comments to D33722: [clang-tidy] Add checker for undelegated copy of base classes.
Sun, Oct 15, 7:11 AM · Restricted Project

Fri, Oct 13

aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

Ping.

Fri, Oct 13, 11:51 AM

Sun, Oct 8

aaron.ballman added a comment to D38596: Implement attribute target multiversioning.

The attribute and sema bits look good to me, but I agree that you might want Richard's opinions before committing.

Sun, Oct 8, 7:28 AM
aaron.ballman added inline comments to D38396: [clang-tidy] introduce legacy resource functions to 'cppcoreguidelines-owning-memory'.
Sun, Oct 8, 7:22 AM

Sat, Oct 7

aaron.ballman added inline comments to D37436: Initial implementation of C attributes (WG14 N2137).
Sat, Oct 7, 10:08 AM
aaron.ballman updated the diff for D37436: Initial implementation of C attributes (WG14 N2137).

Corrected review feedback from Richard.

Sat, Oct 7, 10:07 AM

Fri, Oct 6

aaron.ballman added a reviewer for D38596: Implement attribute target multiversioning: aaron.ballman.
Fri, Oct 6, 6:53 AM
aaron.ballman closed D38284: [clang-tidy] Fix google-readability-namespace-comments handling of C++17 nested namespaces.

I've commit in r315057. Thank you!

Fri, Oct 6, 5:59 AM · Restricted Project

Thu, Oct 5

aaron.ballman added a reviewer for D36836: [clang-tidy] Implement readability-function-cognitive-complexity check: dberlin.

Adding @dberlin for licensing discussion questions.

Thu, Oct 5, 8:44 AM · Restricted Project
aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

Updated based on review feedback.

  • Rename CAttributes to DoubleSquareBracketAttributes
  • Added Objective-C test cases to demonstrate no regressed behavior (based on a use-case pointed out during review)
  • Fixed regression with GNU-style attributes in enumerations

    I still need to rename the cc1 flag, pending agreement on the name.

Ping -- the last outstanding issue that I'm aware of is the cc1 flag name, do you have a preference there, Richard? If not, I'll be going with the verbose -fdouble-square-bracket-attributes.

Thu, Oct 5, 6:05 AM

Wed, Oct 4

aaron.ballman accepted D38411: [clang-tidy] Emit note for variable declaration that are later deleted.

LGTM!

Wed, Oct 4, 6:05 AM · Restricted Project
aaron.ballman accepted D38284: [clang-tidy] Fix google-readability-namespace-comments handling of C++17 nested namespaces.

Aside from a small nit, this LGTM, thanks!

Wed, Oct 4, 6:03 AM · Restricted Project
aaron.ballman added inline comments to D38396: [clang-tidy] introduce legacy resource functions to 'cppcoreguidelines-owning-memory'.
Wed, Oct 4, 5:58 AM

Mon, Oct 2

aaron.ballman accepted D38458: Fix assertion failure in thread safety analysis (PR34800)..

LGTM!

Mon, Oct 2, 9:33 AM
aaron.ballman added inline comments to D38284: [clang-tidy] Fix google-readability-namespace-comments handling of C++17 nested namespaces.
Mon, Oct 2, 9:29 AM · Restricted Project
aaron.ballman added inline comments to D38411: [clang-tidy] Emit note for variable declaration that are later deleted.
Mon, Oct 2, 9:17 AM · Restricted Project
aaron.ballman added inline comments to D38396: [clang-tidy] introduce legacy resource functions to 'cppcoreguidelines-owning-memory'.
Mon, Oct 2, 8:13 AM
aaron.ballman accepted D38399: [clang-tidy] Fix bug 34747, streaming operators and hicpp-signed-bitwise.

LGTM, with a comment about the unrelated test change.

Mon, Oct 2, 8:06 AM

Fri, Sep 29

aaron.ballman added inline comments to D38396: [clang-tidy] introduce legacy resource functions to 'cppcoreguidelines-owning-memory'.
Fri, Sep 29, 6:46 AM
aaron.ballman added inline comments to D38399: [clang-tidy] Fix bug 34747, streaming operators and hicpp-signed-bitwise.
Fri, Sep 29, 6:38 AM

Thu, Sep 28

aaron.ballman accepted D38270: [clang] Add getUnsignedPointerDiffType method.

LGTM!

Thu, Sep 28, 3:25 PM
aaron.ballman closed D38342: [C++] Parse (sub) postfix expression after boolean literal.

Committed in r314463.

Thu, Sep 28, 2:31 PM · Restricted Project
aaron.ballman accepted D38342: [C++] Parse (sub) postfix expression after boolean literal.

LGTM! Do you need me to commit on your behalf?

Thu, Sep 28, 2:20 PM · Restricted Project
aaron.ballman added a comment to D38342: [C++] Parse (sub) postfix expression after boolean literal.
  • Moved test to test/CXX/

    Do I actually need to -verify the test if no diagnostics are expected?

    Thanks @aaron.ballman
Thu, Sep 28, 1:59 PM · Restricted Project
aaron.ballman added inline comments to D38284: [clang-tidy] Fix google-readability-namespace-comments handling of C++17 nested namespaces.
Thu, Sep 28, 1:21 PM · Restricted Project
aaron.ballman added a comment to D36836: [clang-tidy] Implement readability-function-cognitive-complexity check.

@alexfh please specify, is that enough or not?

Thu, Sep 28, 1:05 PM · Restricted Project
aaron.ballman added a reviewer for D38342: [C++] Parse (sub) postfix expression after boolean literal: aaron.ballman.
Thu, Sep 28, 1:03 PM · Restricted Project
aaron.ballman added inline comments to D38342: [C++] Parse (sub) postfix expression after boolean literal.
Thu, Sep 28, 1:03 PM · Restricted Project
aaron.ballman added inline comments to D38270: [clang] Add getUnsignedPointerDiffType method.
Thu, Sep 28, 12:51 PM
aaron.ballman accepted D38205: [Sema] Warn on attribute nothrow conflicting with language specifiers.

changes that were suggested by @aaron.ballman

It DOES warn on the template correctly, however I'm not thrilled that it misses the 'warning' info. Any idea how I can get that information to give that 'note'? I'd like an "in instantiation of template ..." type note.

Thu, Sep 28, 10:55 AM
aaron.ballman accepted D38209: [Sema] Correct nothrow inherited by noexcept.

This is somewhat complicated in that noexcept, throw(), and attribute(())/__declspec no throw are all synonyms for one another except for the type system effect differences between attribute and __declspec, but I think our behavior here is reasonable.

Thu, Sep 28, 10:50 AM
aaron.ballman accepted D38202: Add Documentation to attribute-nothrow. Additionally, limit to functions..

LGTM!

Thu, Sep 28, 10:42 AM

Wed, Sep 27

aaron.ballman added a comment to D38270: [clang] Add getUnsignedPointerDiffType method.

The code for printf diagnostics + new tests are supposed to be added by a separate diff.

Wed, Sep 27, 12:50 PM

Tue, Sep 26

aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

Updated based on review feedback.

  • Rename CAttributes to DoubleSquareBracketAttributes
  • Added Objective-C test cases to demonstrate no regressed behavior (based on a use-case pointed out during review)
  • Fixed regression with GNU-style attributes in enumerations

    I still need to rename the cc1 flag, pending agreement on the name.
Tue, Sep 26, 3:30 PM

Mon, Sep 25

aaron.ballman added a reviewer for D38209: [Sema] Correct nothrow inherited by noexcept: rsmith.

do you think __declspec(nothrow) calling the terminate handler in Clang is a bug?

It's certainly a behavior difference with potential performance impact, although I don't think it can be viewed as a bug, strictly speaking. MSVC treats __declspec(nothrow) as an optimization request, with undefined behavior if it's violated. Termination is definitely one of the possible results of undefined behavior.

We've recently had to slightly rethink our EH strategy in light of C++17's addition of noexcept into the type system, and the removal of dynamic exception specifications (and the change in semantics to throw()). MSVC's /EHsc makes this extra fun. If you're interested, I can put you in contact with the compiler dev who recently made those changes.

Mon, Sep 25, 1:42 PM
aaron.ballman added a comment to D38209: [Sema] Correct nothrow inherited by noexcept.

I'm not certain we have the semantics of __declspec(nothrow) exactly correct -- a simple test shows that __attribute__((nothrow)), __declspec(nothrow), and noexcept(true) are subtly different.

Mon, Sep 25, 5:52 AM
aaron.ballman added inline comments to D38205: [Sema] Warn on attribute nothrow conflicting with language specifiers.
Mon, Sep 25, 5:32 AM
aaron.ballman accepted D38203: [Sema] Corrected the warn-on-throw-from-noexcept behavior to include nothrow.

Aside from a minor testing nit, LGTM! Thanks!

Mon, Sep 25, 5:13 AM
aaron.ballman added inline comments to D38202: Add Documentation to attribute-nothrow. Additionally, limit to functions..
Mon, Sep 25, 5:11 AM
aaron.ballman added inline comments to D38179: [clang-tidy] Handle unions in modernize-use-equals-default check.
Mon, Sep 25, 5:03 AM

Fri, Sep 22

aaron.ballman accepted D38159: [clang] Fix printf fixit for objc specific types.

Aside from a few minor nits, LGTM!

Fri, Sep 22, 6:07 AM
aaron.ballman added a comment to D38171: Implement clang-tidy check aliases..

Thank you for working on this -- it's very nice functionality!

Fri, Sep 22, 5:58 AM

Wed, Sep 20

aaron.ballman added inline comments to D33722: [clang-tidy] Add checker for undelegated copy of base classes.
Wed, Sep 20, 8:37 AM · Restricted Project

Tue, Sep 19

aaron.ballman accepted D37629: [Sema] Move some stuff into -Wtautological-unsigned-enum-zero-compare.

LGTM!

Tue, Sep 19, 1:55 PM · Restricted Project
aaron.ballman added inline comments to D37629: [Sema] Move some stuff into -Wtautological-unsigned-enum-zero-compare.
Tue, Sep 19, 1:12 PM · Restricted Project
aaron.ballman added inline comments to D37629: [Sema] Move some stuff into -Wtautological-unsigned-enum-zero-compare.
Tue, Sep 19, 11:21 AM · Restricted Project

Sep 15 2017

aaron.ballman added reviewers for D36836: [clang-tidy] Implement readability-function-cognitive-complexity check: sbenza, JonasToth.

Adding a few reviewers to hopefully help Roman get some feedback.

Sep 15 2017, 6:30 AM · Restricted Project

Sep 14 2017

aaron.ballman updated the diff for D37436: Initial implementation of C attributes (WG14 N2137).

Updated based on review feedback.

Sep 14 2017, 2:03 PM
aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

Also, your wording paper appears to allow things like

struct [[foo]] S *p; // ok in c n2137, ill-formed in c++
struct T {};
int n = sizeof(struct [[foo]] T); // ok in c n2137, ill-formed in c++

You don't seem to implement those changes; are they bugs in the wording paper?

Sep 14 2017, 6:03 AM

Sep 13 2017

aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

I think that I misunderstood your concern. Let me see if I can summarize your position: You believe that, when GCC implements this syntax in C, they will audit their attributes and not support all of their existing gnu:: attributes in C. You only want us to support these when we know what that list will be (which we don't yet). Is that correct?

Yes, that is correct.

Okay. A large fraction of the number of attributes we'll want to use are going to fall into this category (because Clang doesn't have its own attributes, but copied GCC's, for many things). I don't think we'll get good implementation feedback until we have this figured out. If we can't sync with GCC soon, I suggest just making a reasonable guess. My first choice would be to just allowing everything, and then we can see what people found to be useful and why. Our experience here can also provide feedback to GCC (and we can always update late if needed - it is still an experimental feature).

Sep 13 2017, 11:10 AM
aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

I think that I misunderstood your concern. Let me see if I can summarize your position: You believe that, when GCC implements this syntax in C, they will audit their attributes and not support all of their existing gnu:: attributes in C. You only want us to support these when we know what that list will be (which we don't yet). Is that correct?

Sep 13 2017, 5:26 AM
aaron.ballman updated the diff for D37436: Initial implementation of C attributes (WG14 N2137).

Added full context, no other changes from previous patch.

Sep 13 2017, 5:11 AM
aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

I do not think that's the correct approach. These are not C++ attributes (for instance, no using insanity is allowed, :: is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does abi_tag *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific gnu:: attributes that GCC does not implement in C yet.

On this last point, I disagree. Implementation experience is about all of the messy things that occur in production. In production, if we have this syntax, then we'll end up enabling it for a bunch of vendor-specific attributes. Do you think that we wouldn't?

I'm sure we would. Also, FWIW, I was planning to traverse the attributes we implement to find which clang-specific C++ attributes would make sense to also enable as a follow-up patch once the syntax is in.

N2137 specifically talks about this as a use case. If so, this will include gnu:: attributes that we have in Clang (even if GCC does not implement them).

Eventually, yes, but it seems like a problem to implement something under that vendor namespace when the vendor themselves do not. I think it would be really unfortunate were GCC to add a C++ attribute named [[clang::frobble]] that Clang does not implement, and I don't see this case as being all that different. My belief is that GCC will eventually elect to make most of these attributes available in C mode and that's an appropriate time for us to do the same for their vendor namespace.

From my perspective, lack of consistency here between Clang's C and C++ modes is much more problematic than a lack of consistency between what Clang and GCC implement.

From my perspective, they're both problems in their own right. To me (and maybe I'm weird with this line of reasoning), the only reasonable time to implement an attribute under another vendor's attribute namespace is when you are promising your users that you will attempt to match the owning vendor's semantics for that attribute. A case could be made here that the owning vendor *has* implemented that attribute (since they have in C++), but I'm not too comfortable *assuming* that the GCC folks are okay with this since they don't implement the feature syntax in C yet.

That said, I'm happy to ask Jason at the meetings in Albuquerque to explore the idea -- but I don't think it should hold up this patch, especially since we have our own vendor attributes we can use for gaining experience.

I certainly understand your perspective, but this is an orthogonal concern. If this is something that Clang does, then it should do it consistently. If you'd like us not to support gnu:: attributes that GCC itself does not support, and that's something that we currently do in C++, then please submit a patch to fix that for all language modes. It should not differ between language modes.

Is the problem here that we're treating gnu::, not as a vendor prefix, but as generic escape hatch to get to anything generally provided via GCC-attribute syntax (which many compilers, including ours, have extended with attributes that GCC does not itself support)?

Sep 13 2017, 4:52 AM

Sep 12 2017

aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

I do not think that's the correct approach. These are not C++ attributes (for instance, no using insanity is allowed, :: is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does abi_tag *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific gnu:: attributes that GCC does not implement in C yet.

On this last point, I disagree. Implementation experience is about all of the messy things that occur in production. In production, if we have this syntax, then we'll end up enabling it for a bunch of vendor-specific attributes. Do you think that we wouldn't?

Sep 12 2017, 11:30 AM
aaron.ballman added a comment to D33826: [clang-tidy] avoid pointer cast to more strict alignment check.

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

Quote for the reference:

EXP36-C-EX2: If a pointer is known to be correctly aligned to the target type, then a cast to that type is permitted. There are several cases where a pointer is known to be correctly aligned to the target type. The pointer could point to an object declared with a suitable alignment specifier. It could point to an object returned by aligned_alloc(), calloc(), malloc(), or realloc(), as per the C standard, section 7.22.3, paragraph 1 [ISO/IEC 9899:2011].

For plain calloc(), malloc(), or realloc(), i would guess it's related to max_align_t / std::max_align_t / __STDCPP_DEFAULT_NEW_ALIGNMENT__, which is generally just 16 bytes.

It's a requirement from the C standard that malloc, calloc, and realloc return a suitably-aligned pointer for *any* type.

We are probably arguing about the details, or i'm just misguided, but you mean any *standard* type, right?

MALLOC(3)
 ...
 The  malloc()  and calloc() functions return a pointer to the allocated memory, which is suitably aligned for any built-in type.

E.g. __m256 needs to be 32-byte aligned, and user type, with the help of alignas(), can have different alignment requirements

Sep 12 2017, 9:37 AM · Restricted Project
aaron.ballman accepted D36354: [clang-tidy] Implement type-based check for `gsl::owner`.

Good catch on the deleted constructor -- LGTM still!

Sep 12 2017, 9:15 AM
aaron.ballman accepted D36354: [clang-tidy] Implement type-based check for `gsl::owner`.

LGTM, with a few last typos.

Sep 12 2017, 8:53 AM
aaron.ballman added inline comments to D37308: Fix the __interface inheritence rules to work better with IUnknown and IDispatch.
Sep 12 2017, 8:46 AM
aaron.ballman added a comment to D33826: [clang-tidy] avoid pointer cast to more strict alignment check.

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

In practice, are there any malloc declarations still in use that return char* instead of void*? I assume this does not complain when the source is void*.

Sep 12 2017, 8:30 AM · Restricted Project
aaron.ballman added a comment to D33826: [clang-tidy] avoid pointer cast to more strict alignment check.

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

Quote for the reference:

EXP36-C-EX2: If a pointer is known to be correctly aligned to the target type, then a cast to that type is permitted. There are several cases where a pointer is known to be correctly aligned to the target type. The pointer could point to an object declared with a suitable alignment specifier. It could point to an object returned by aligned_alloc(), calloc(), malloc(), or realloc(), as per the C standard, section 7.22.3, paragraph 1 [ISO/IEC 9899:2011].

For plain calloc(), malloc(), or realloc(), i would guess it's related to max_align_t / std::max_align_t / __STDCPP_DEFAULT_NEW_ALIGNMENT__, which is generally just 16 bytes.

Sep 12 2017, 8:30 AM · Restricted Project
aaron.ballman added inline comments to D37629: [Sema] Move some stuff into -Wtautological-unsigned-enum-zero-compare.
Sep 12 2017, 8:26 AM · Restricted Project
aaron.ballman added inline comments to D36354: [clang-tidy] Implement type-based check for `gsl::owner`.
Sep 12 2017, 8:18 AM
aaron.ballman added a comment to D37436: Initial implementation of C attributes (WG14 N2137).

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

Sep 12 2017, 7:17 AM
aaron.ballman updated the diff for D37436: Initial implementation of C attributes (WG14 N2137).

Updates based on review feedback.

Sep 12 2017, 7:05 AM

Sep 8 2017

aaron.ballman updated the diff for D37436: Initial implementation of C attributes (WG14 N2137).

Updated based on Richard's comments and some further discussion on IRC.

Sep 8 2017, 3:52 PM
aaron.ballman accepted D37643: Add objcImplementationDecl matcher.

LGTM, thanks!

Sep 8 2017, 3:46 PM
aaron.ballman accepted D37636: [TableGen] Ensure that __lsan_is_turned_off isn't removed by DCE in llvm-tblgen.

LGTM!

Sep 8 2017, 1:32 PM
aaron.ballman added inline comments to D36354: [clang-tidy] Implement type-based check for `gsl::owner`.
Sep 8 2017, 1:30 PM
aaron.ballman added inline comments to D37572: [clang-tidy] SuspiciousEnumUsageCheck bugfix.
Sep 8 2017, 1:24 PM
aaron.ballman added inline comments to D33852: Enable __declspec(selectany) on linux.
Sep 8 2017, 11:43 AM
aaron.ballman added inline comments to D33852: Enable __declspec(selectany) on linux.
Sep 8 2017, 9:14 AM
aaron.ballman added inline comments to D37572: [clang-tidy] SuspiciousEnumUsageCheck bugfix.
Sep 8 2017, 8:45 AM
aaron.ballman added inline comments to D37624: add support for -fno-instrument-functions and -finstrument-functions-exclude-{file,function}-list=<arg1,arg2,...> to match gcc options..
Sep 8 2017, 8:43 AM
aaron.ballman added inline comments to D37572: [clang-tidy] SuspiciousEnumUsageCheck bugfix.
Sep 8 2017, 7:47 AM
aaron.ballman added inline comments to D36672: [clang-tidy] readability-non-const-parameter: fixit on all function declarations.
Sep 8 2017, 7:31 AM · Restricted Project
aaron.ballman added inline comments to D37308: Fix the __interface inheritence rules to work better with IUnknown and IDispatch.
Sep 8 2017, 7:16 AM
aaron.ballman added inline comments to D36354: [clang-tidy] Implement type-based check for `gsl::owner`.
Sep 8 2017, 6:58 AM
aaron.ballman accepted D37620: [Sema] Put tautological comparison of unsigned and zero into it's own flag.

Please run the test through clang-format, but otherwise LGTM!

Sep 8 2017, 6:47 AM · Restricted Project
aaron.ballman added inline comments to D33852: Enable __declspec(selectany) on linux.
Sep 8 2017, 6:40 AM
aaron.ballman requested changes to D37620: [Sema] Put tautological comparison of unsigned and zero into it's own flag.

The bulk of the patch LGTM as well, but it should still have a test case.

Sep 8 2017, 6:22 AM · Restricted Project
aaron.ballman added a comment to D37620: [Sema] Put tautological comparison of unsigned and zero into it's own flag.

Thanks!
Unless I'm missing something, the current patch just adds the category, but doesn't actually recategorize the warning, right?

Sep 8 2017, 6:14 AM · Restricted Project
aaron.ballman added a comment to D37620: [Sema] Put tautological comparison of unsigned and zero into it's own flag.

Does this need test?

Sep 8 2017, 5:32 AM · Restricted Project

Sep 5 2017

aaron.ballman added a comment to D33826: [clang-tidy] avoid pointer cast to more strict alignment check.

Have you run this check over any large code bases to see what the quality of the diagnostics are?

Sep 5 2017, 10:20 AM · Restricted Project
aaron.ballman added a comment to D33825: [clang-tidy] signal handler must be plain old function check.

Aside from a few small nits, this looks reasonable. Have you run it over any large code bases that use signals to test the quality of the check?

Sep 5 2017, 9:19 AM · Restricted Project

Sep 4 2017

aaron.ballman created D37436: Initial implementation of C attributes (WG14 N2137).
Sep 4 2017, 6:49 AM
aaron.ballman abandoned D23453: Add a c2x language mode.
Sep 4 2017, 6:22 AM

Sep 1 2017

aaron.ballman accepted D33852: Enable __declspec(selectany) on linux.

Assuming no sphinx issues with the docs, this LGTM, thank you!

Sep 1 2017, 10:53 AM

Aug 31 2017

aaron.ballman accepted D37312: Add documentation for force_align_arg_pointer function attribute.

LGTM! Thank you for working on this!

Aug 31 2017, 1:24 PM
aaron.ballman added a comment to D37308: Fix the __interface inheritence rules to work better with IUnknown and IDispatch.

The test case you gave doesn't compile. It returns the diagnostic. CL has the same behavior. I don't think it is because of the dllimport.

Aug 31 2017, 12:22 PM
aaron.ballman added inline comments to D33852: Enable __declspec(selectany) on linux.
Aug 31 2017, 12:14 PM
aaron.ballman added a comment to D37308: Fix the __interface inheritence rules to work better with IUnknown and IDispatch.

Removed the helper function.

If RD (base class) has uuid attribute, we want to ensure that the interface doesn't have attributes. Otherwise cases like:

class declspec(uuid("00000000-0000-0000-C000-000000000046")) IUnknown1 {};
interface __declspec(dllimport) ISfFileIOPropertyPage1 : public IUnknown1 {};

will compile.

Aug 31 2017, 11:38 AM
aaron.ballman added inline comments to D37312: Add documentation for force_align_arg_pointer function attribute.
Aug 31 2017, 11:33 AM
aaron.ballman accepted D37346: Register linkageSpecDecl matcher.

LGTM!

Aug 31 2017, 11:28 AM

Aug 30 2017

aaron.ballman added a comment to D36272: [CodeGen][x86_64] Enable 'force_align_arg_pointer' attribute at x86_64.

Hi Aaron. Thank you very much for reviewing this patch.

I'll be glad to add documentation for 'force_align_arg_pointer' attribute and upload another patch. But before doing it I would like to finish work on the current patch and make its forward progress toward repository.

Aug 30 2017, 1:35 PM · Restricted Project
aaron.ballman added inline comments to D37308: Fix the __interface inheritence rules to work better with IUnknown and IDispatch.
Aug 30 2017, 1:23 PM