[PATCH] D35824: [Sema] Implicitly apply the may_alias attribute to std::byte

majnemer created this revision. std::byte, when defined as an enum, needs to be given special treatment with regards to its aliasing properties. An array of std::byte is allowed to be used as storage for other types. This fixes PR33916. https://reviews.llvm.org/D35824 Files: lib/Sema/SemaDec

[PATCH] D35782: [C++2a][Preprocessor] Implement p0306 __VA_OPT__ (Comma omission and comma deletion)

rsmith added a comment. I think we need more consideration of what the end result of `__VA_OPT__` should be, and particularly how it should affect the `SourceLocation` data. It seems there are two models: 1. Model `__VA_OPT__` following the specification in the standard: form an imaginary macr

Re: [PATCH v3] [PPC64]: Add support for Swift calling convention

On Mon, 2017-07-24 at 09:32 +0200, Ulrich Weigand wrote: > > Andrew Jeffery wrote on 24.07.2017 03:54:05: > > > > > > +  bool shouldPassIndirectlyForSwift(CharUnits totalSize, > > > > > +ArrayRef scalars, > > > > > +bool asRe

r308948 - [NFC] Use RAII to un-poison and then re-poison __VA_ARGS__

Author: faisalv Date: Mon Jul 24 20:15:36 2017 New Revision: 308948 URL: http://llvm.org/viewvc/llvm-project?rev=308948&view=rev Log: [NFC] Use RAII to un-poison and then re-poison __VA_ARGS__ - This will also be used for the forthcoming __VA_OPT__ feature approved for C++2a. - recommended by

[PATCH] D35824: [Sema] Implicitly apply the may_alias attribute to std::byte

rsmith added a comment. I would prefer to handle `std::byte` explicitly in the places where it matters, rather than adding an attribute to it and otherwise treating it like any other enumeration. We're going to want to be able to identify `std::byte` for warning emission and probably other code

[PATCH] D35783: Ignore shadowing for declarations coming from within macros.

kimgr added a comment. Any chance you could try my example too? It seems like this approach might catch it. But does the new approach really do anything different for your original example? https://reviews.llvm.org/D35783 ___ cfe-commits mailing

[PATCH] D35783: Ignore shadowing for declarations coming from within macros.

djasper added a comment. Yes, your example would work, too. The specific use case I have is where we are shadowing global variables. https://reviews.llvm.org/D35783 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-b

[clang-tools-extra] r308954 - [clang-tidy] Handle incomplete types in bugprone-undefined-memory-manipulation

Author: xazax Date: Mon Jul 24 23:52:08 2017 New Revision: 308954 URL: http://llvm.org/viewvc/llvm-project?rev=308954&view=rev Log: [clang-tidy] Handle incomplete types in bugprone-undefined-memory-manipulation check Patch by: Reka Nikolett Kovacs Differential Revision: https://reviews.llvm.org/

[PATCH] D35790: [clang-tidy] Handle incomplete types in bugprone-undefined-memory-manipulation check.

This revision was automatically updated to reflect the committed changes. Closed by commit rL308954: [clang-tidy] Handle incomplete types in bugprone-undefined-memory-manipulation (authored by xazax). Changed prior to commit: https://reviews.llvm.org/D35790?vs=107863&id=108012#toc Repository:

[PATCH] D33672: [analyzer] INT50-CPP. Do not cast to an out-of-range enumeration checker

xazax.hun added a reviewer: aaron.ballman. xazax.hun added a comment. Aaron, could you comment on the applicability of this check to C? Thanks in advance. https://reviews.llvm.org/D33672 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http:

[PATCH] D34030: Fix the postorder visting of the ClassTemplateSpecializationDecl nodes in the RecursiveASTVisitor.

MontyKutyi updated this revision to Diff 108013. MontyKutyi added a comment. Updated the comment. https://reviews.llvm.org/D34030 Files: include/clang/AST/RecursiveASTVisitor.h Index: include/clang/AST/RecursiveASTVisitor.h ===

<    1   2