r373844 - [clang-format][docs] Fix the Google C++ and Chromium style guide URLs

2019-10-06 Thread Paul Hoad via cfe-commits 
Author: paulhoad
Date: Sun Oct  6 02:37:58 2019
New Revision: 373844

URL: http://llvm.org/viewvc/llvm-project?rev=373844&view=rev
Log:
[clang-format][docs] Fix the Google C++ and Chromium style guide URLs

Summary: The Google C++ and Chromium style guides are broken in the 
clang-format docs. This patch updates them.

Reviewers: djasper, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: cfe-commits

Tags: #clang

Patch by: m4tx

Differential Revision: https://reviews.llvm.org/D61256

Modified:
cfe/trunk/docs/ClangFormatStyleOptions.rst

Modified: cfe/trunk/docs/ClangFormatStyleOptions.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangFormatStyleOptions.rst?rev=373844&r1=373843&r2=373844&view=diff
==
--- cfe/trunk/docs/ClangFormatStyleOptions.rst (original)
+++ cfe/trunk/docs/ClangFormatStyleOptions.rst Sun Oct  6 02:37:58 2019
@@ -141,7 +141,7 @@ the configuration (without a prefix: ``A
 `_
   * ``Chromium``
 A style complying with `Chromium's style guide
-`_
+
`_
   * ``Mozilla``
 A style complying with `Mozilla's style guide
 `_


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61256: [clang-format][docs] Fix the Google C++ and Chromium style guide URLs

2019-10-06 Thread Phabricator via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL373844: [clang-format][docs] Fix the Google C++ and Chromium 
style guide URLs (authored by paulhoad, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61256?vs=197078&id=223407#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61256/new/

https://reviews.llvm.org/D61256

Files:
  cfe/trunk/docs/ClangFormatStyleOptions.rst


Index: cfe/trunk/docs/ClangFormatStyleOptions.rst
===
--- cfe/trunk/docs/ClangFormatStyleOptions.rst
+++ cfe/trunk/docs/ClangFormatStyleOptions.rst
@@ -141,7 +141,7 @@
 `_
   * ``Chromium``
 A style complying with `Chromium's style guide
-`_
+
`_
   * ``Mozilla``
 A style complying with `Mozilla's style guide
 `_


Index: cfe/trunk/docs/ClangFormatStyleOptions.rst
===
--- cfe/trunk/docs/ClangFormatStyleOptions.rst
+++ cfe/trunk/docs/ClangFormatStyleOptions.rst
@@ -141,7 +141,7 @@
 `_
   * ``Chromium``
 A style complying with `Chromium's style guide
-`_
+`_
   * ``Mozilla``
 A style complying with `Mozilla's style guide
 `_
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63640: [clang] Improve Serialization/Imporing/Dumping of APValues

2019-10-06 Thread Tyker via Phabricator via cfe-commits 
Tyker marked 10 inline comments as done.
Tyker added a comment.

update done tasks.




Comment at: clang/lib/AST/APValue.cpp:599
 Out << '[' << Path[I].getAsArrayIndex() << ']';
-ElemTy = Ctx.getAsArrayType(ElemTy)->getElementType();
+ElemTy = cast(ElemTy)->getElementType();
   }

aaron.ballman wrote:
> Tyker wrote:
> > aaron.ballman wrote:
> > > Are you sure this doesn't change behavior? See the implementation of 
> > > `ASTContext::getAsArrayType()`. Same question applies below.
> > i ran the test suite after the change it there wasn't any test failures. 
> > but the test on dumping APValue are probably not as thorough as we would 
> > like them to be.
> > from analysis of `ASTContext::getAsArrayType()` the only effect i see on 
> > the element type is de-sugaring and canonicalization which shouldn't affect 
> > correctness of the output.  de-sugaring requires the ASTContext but 
> > canonicalization doesn't.
> > 
> > i think the best way the have higher confidence is to ask rsmith what he 
> > thinks.
> Yeah, I doubt we have good test coverage for all the various behaviors here. 
> I was wondering if the qualifiers bit was handled properly with a simple 
> cast. @rsmith is a good person to weigh in.
the original question we had is whether it is correct to replace 
`Ctx.ASTContext::getAsArrayType(ElemTy)` by 
`cast(ElemTy.getCanonicalType())` in this context and the other 
comment below.



Comment at: clang/lib/AST/Expr.cpp:319
   case RSK_None:
 return;
   case RSK_Int64:

rsmith wrote:
> Can you use `llvm_unreachable` here? (Are there cases where we use `RSK_None` 
> and then later find we actually have a value to store into the 
> `ConstantExpr`?)
we can put `llvm_unreachable` in the switch because of `if (!Value.hasValue())` 
above the switch but we can't remove `if (!Value.hasValue())`.
all cases i have seen where `if (!Value.hasValue())` is taken occur after a 
semantic error occured. 



Comment at: clang/lib/Serialization/ASTReader.cpp:9635
+if (IsExpr) {
+  Base = APValue::LValueBase(ReadExpr(F), CallIndex, Version);
+  ElemTy = Base.get()->getType();

rsmith wrote:
> This is problematic.
> 
> `ReadExpr` will read a new copy of the expression, creating a distinct 
> object. But in the case where we reach this when deserializing (for a 
> `MaterializeTemporaryExpr`), we need to refer to the existing 
> `MaterializeTemporaryExpr` in the initializer of its lifetime-extending 
> declaration. We will also need to serialize the `ASTContext`'s 
> `MaterializedTemporaryValues` collection so that the temporaries 
> lifetime-extended in a constant initializer get properly handled.
> 
> That all sounds very messy, so I think we should reconsider the model that we 
> use for lifetime-extended materialized temporaries. As a half-baked idea:
> 
>  * When we lifetime-extend a temporary, create a `MaterializedTemporaryDecl` 
> to hold its value, and modify `MaterializeTemporaryExpr` to refer to the 
> `MaterializedTemporaryDecl` rather than to just hold the subexpression for 
> the temporary.
>  * Change the `LValueBase` representation to denote the declaration rather 
> than the expression.
>  * Store the constant evaluated value for a materialized temporary on the 
> `MaterializedTemporaryDecl` rather than on a side-table in the `ASTContext`.
> 
> With that done, we should verify that all remaining `Expr*`s used as 
> `LValueBase`s are either only transiently used during evaluation or don't 
> have these kinds of identity problems.
Would it be possible to adapt serialization/deserialization so that they make 
sure that `MaterializeTemporaryExpr` are unique.
by:

  - When serializing `MaterializeTemporaryExpr` serialize a key obtained from 
the pointer to the expression as it is unique.
  - When deserializing `MaterializeTemporaryExpr` deserializing the key, and 
than have a cache for previously deserialized expression that need to be unique.

This would make easier adding new `Expr` that require uniqueness and seem less 
complicated.
What do you think ?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63640/new/

https://reviews.llvm.org/D63640



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68551: [clang-format] [NFC] Ensure clang-format is itself clang-formatted.

2019-10-06 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay created this revision.
MyDeveloperDay added a reviewer: mitchell-stellar.
MyDeveloperDay added a project: clang-format.
Herald added a project: clang.

Before making a proposed change, ensure ClangFormat.cpp is fully 
clang-formatted,

no functional change just clang-formatting using the in tree .clang-format.


Repository:
  rC Clang

https://reviews.llvm.org/D68551

Files:
  clang/tools/clang-format/ClangFormat.cpp

Index: clang/tools/clang-format/ClangFormat.cpp
===
--- clang/tools/clang-format/ClangFormat.cpp
+++ clang/tools/clang-format/ClangFormat.cpp
@@ -51,13 +51,14 @@
  "Can only be used with one input file."),
 cl::cat(ClangFormatCategory));
 static cl::list
-LineRanges("lines", cl::desc(": - format a range of\n"
- "lines (both 1-based).\n"
- "Multiple ranges can be formatted by specifying\n"
- "several -lines arguments.\n"
- "Can't be used with -offset and -length.\n"
- "Can only be used with one input file."),
-   cl::cat(ClangFormatCategory));
+LineRanges("lines",
+   cl::desc(": - format a range of\n"
+"lines (both 1-based).\n"
+"Multiple ranges can be formatted by specifying\n"
+"several -lines arguments.\n"
+"Can't be used with -offset and -length.\n"
+"Can only be used with one input file."),
+   cl::cat(ClangFormatCategory));
 static cl::opt
 Style("style", cl::desc(clang::format::StyleOptionHelpDescription),
   cl::init(clang::format::DefaultFormatStyle),
@@ -72,12 +73,12 @@
   cl::init(clang::format::DefaultFallbackStyle),
   cl::cat(ClangFormatCategory));
 
-static cl::opt
-AssumeFileName("assume-filename",
-   cl::desc("When reading from stdin, clang-format assumes this\n"
-"filename to look for a style config file (with\n"
-"-style=file) and to determine the language."),
-   cl::init(""), cl::cat(ClangFormatCategory));
+static cl::opt AssumeFileName(
+"assume-filename",
+cl::desc("When reading from stdin, clang-format assumes this\n"
+ "filename to look for a style config file (with\n"
+ "-style=file) and to determine the language."),
+cl::init(""), cl::cat(ClangFormatCategory));
 
 static cl::opt Inplace("i",
  cl::desc("Inplace edit s, if specified."),
@@ -249,8 +250,8 @@
   // On Windows, overwriting a file with an open file mapping doesn't work,
   // so read the whole file into memory when formatting in-place.
   ErrorOr> CodeOrErr =
-  !OutputXML && Inplace ? MemoryBuffer::getFileAsStream(FileName) :
-  MemoryBuffer::getFileOrSTDIN(FileName);
+  !OutputXML && Inplace ? MemoryBuffer::getFileAsStream(FileName)
+: MemoryBuffer::getFileOrSTDIN(FileName);
   if (std::error_code EC = CodeOrErr.getError()) {
 errs() << EC.message() << "\n";
 return true;
@@ -264,20 +265,21 @@
   // https://en.wikipedia.org/wiki/Byte_order_mark#Byte_order_marks_by_encoding
   // for more information.
   StringRef BufStr = Code->getBuffer();
-  const char *InvalidBOM = llvm::StringSwitch(BufStr)
-.StartsWith(llvm::StringLiteral::withInnerNUL("\x00\x00\xFE\xFF"),
-  "UTF-32 (BE)")
-.StartsWith(llvm::StringLiteral::withInnerNUL("\xFF\xFE\x00\x00"),
-  "UTF-32 (LE)")
-.StartsWith("\xFE\xFF", "UTF-16 (BE)")
-.StartsWith("\xFF\xFE", "UTF-16 (LE)")
-.StartsWith("\x2B\x2F\x76", "UTF-7")
-.StartsWith("\xF7\x64\x4C", "UTF-1")
-.StartsWith("\xDD\x73\x66\x73", "UTF-EBCDIC")
-.StartsWith("\x0E\xFE\xFF", "SCSU")
-.StartsWith("\xFB\xEE\x28", "BOCU-1")
-.StartsWith("\x84\x31\x95\x33", "GB-18030")
-.Default(nullptr);
+  const char *InvalidBOM =
+  llvm::StringSwitch(BufStr)
+  .StartsWith(llvm::StringLiteral::withInnerNUL("\x00\x00\xFE\xFF"),
+  "UTF-32 (BE)")
+  .StartsWith(llvm::StringLiteral::withInnerNUL("\xFF\xFE\x00\x00"),
+  "UTF-32 (LE)")
+  .StartsWith("\xFE\xFF", "UTF-16 (BE)")
+  .StartsWith("\xFF\xFE", "UTF-16 (LE)")
+  .StartsWith("\x2B\x2F\x76", "UTF-7")
+  .StartsWith("\xF7\x64\x4C", "UTF-1")
+  .StartsWith("\xDD\x73\x66\x73", "UTF-EBCDIC")
+  .StartsWith("\x0E\xFE\xFF", "SCSU")
+  .StartsWith("\xFB\xEE\x28", "BOCU-1")
+  .StartsWith("\x84\x31\x95\x33", "GB-18030")
+  .Default(nullptr);
 
   if (InvalidBOM) {
 errs() << "error: encoding with unsupported byte order mark \""
@@ -313,8 +315

[PATCH] D29039: Proposal for clang-format -r option

2019-10-06 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added a comment.

When I first saw this issue some time ago I tended to agree with the comment 
regarding the "its not clang-formats" job to do that...

However, over the last couple of months I've seen more and more twitter and 
stack-overflow comments regarding "how do I check my whole tree to see what 
needs clang formatting"

The solutions seem to be a mixture of using various shell tools like find and 
grep depending if your using cmd,bash,make etc.. and to determine if a change 
is indeed needed a quite convoluted series of commands looking for greping for 
""

Finally a quote on twitter by @invalidop may be want to change the way I use 
clang-format.

> If it's not formatted with clang-format it's a build error.

When I'm making a change to clang-format itself, one thing I like to do to test 
the change is to ensure I didn't cause a huge wave of changes, what I want to 
do is simply run this on a known formatted directory and see if any new 
differences arrive.

This started me thinking that we should allow build systems to run clang-format 
on a whole tree and emit compiler style warnings about files that fail 
clang-format in a form that would make them as warning in most build systems 
and because those build systems range in their construction I don't think its 
unreasonable to NOT expect them to have to do the directory searching or 
parsing the output replacements themselves, but simply transform that into an 
error code when there are changes required.

To this end I would like to resurect these ideas of searching a tree, along 
with another idea I have regarding adding a -n or -dry-run command line 
argument which would emit a warning/error of the form

  fileXXX.XXX:29:3: warning: file requires a clang-format 
[-Wfile-needs-clang-format]

I envisage being able to use -Wno-file-needs-clang-format and  -Werror to 
escalate them to errors. I know for my own team we'd use this to scan a 
directory during a build, bring clang-format failures to the front, and this 
would prevent clang-formatting errors creeping in to the build which seems to 
happen from the few people who don't use it integrated into an editor or those 
who forget to run git-clang-format.

my question to you @stryku is are you still interested in pursuing this patch, 
or are you ok with us consuming it (at least partially) into another piece of 
work?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D29039/new/

https://reviews.llvm.org/D29039



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68539: [clang-tidy] fix for readability-identifier-naming incorrectly fixes variables which become keywords

2019-10-06 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added a comment.

This should really be a full context diff -U9


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68539/new/

https://reviews.llvm.org/D68539



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62394: [ARM][CMSE] Add CMSE header & builtins

2019-10-06 Thread Momchil Velikov via Phabricator via cfe-commits 
chill added a comment.

I hope I will be able to pick this up in the following weeks and land patches a 
couple of weeks later. Sorry for the delay, but priorities shift all the time ;)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62394/new/

https://reviews.llvm.org/D62394



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68526: [Diagnostics] Silence -Wsizeof-array-div for character buffers

2019-10-06 Thread James Clarke via Phabricator via cfe-commits 
jrtc27 added a comment.

Having said that, the one warning this raised in FreeBSD (at least for our 
configuration) was a completely unnecessary use of a character buffer and could 
be cleaned up, so maybe this case is a useful one to catch. Does anyone else 
have an opinion on this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68526/new/

https://reviews.llvm.org/D68526



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r373847 - [InstCombine] don't assume 'inbounds' for bitcast pointer to GEP transform (PR43501)

2019-10-06 Thread Sanjay Patel via cfe-commits 
Author: spatel
Date: Sun Oct  6 06:08:08 2019
New Revision: 373847

URL: http://llvm.org/viewvc/llvm-project?rev=373847&view=rev
Log:
[InstCombine] don't assume 'inbounds' for bitcast pointer to GEP transform 
(PR43501)

https://bugs.llvm.org/show_bug.cgi?id=43501
We can't declare a GEP 'inbounds' in general. But we may salvage that 
information if
we have known dereferenceable bytes on the source pointer.

Differential Revision: https://reviews.llvm.org/D68244

Modified:
cfe/trunk/test/CodeGen/aapcs-bitfield.c
cfe/trunk/test/CodeGenCXX/microsoft-abi-dynamic-cast.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-typeid.cpp

Modified: cfe/trunk/test/CodeGen/aapcs-bitfield.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aapcs-bitfield.c?rev=373847&r1=373846&r2=373847&view=diff
==
--- cfe/trunk/test/CodeGen/aapcs-bitfield.c (original)
+++ cfe/trunk/test/CodeGen/aapcs-bitfield.c Sun Oct  6 06:08:08 2019
@@ -8,7 +8,7 @@ struct st0 {
 
 // LE-LABEL: @st0_check_load(
 // LE-NEXT:  entry:
-// LE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST0:%.*]], 
%struct.st0* [[M:%.*]], i32 0, i32 0
+// LE-NEXT:[[TMP0:%.*]] = getelementptr [[STRUCT_ST0:%.*]], %struct.st0* 
[[M:%.*]], i32 0, i32 0
 // LE-NEXT:[[BF_LOAD:%.*]] = load i8, i8* [[TMP0]], align 2
 // LE-NEXT:[[BF_SHL:%.*]] = shl i8 [[BF_LOAD]], 1
 // LE-NEXT:[[BF_ASHR:%.*]] = ashr exact i8 [[BF_SHL]], 1
@@ -17,7 +17,7 @@ struct st0 {
 //
 // BE-LABEL: @st0_check_load(
 // BE-NEXT:  entry:
-// BE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST0:%.*]], 
%struct.st0* [[M:%.*]], i32 0, i32 0
+// BE-NEXT:[[TMP0:%.*]] = getelementptr [[STRUCT_ST0:%.*]], %struct.st0* 
[[M:%.*]], i32 0, i32 0
 // BE-NEXT:[[BF_LOAD:%.*]] = load i8, i8* [[TMP0]], align 2
 // BE-NEXT:[[BF_ASHR:%.*]] = ashr i8 [[BF_LOAD]], 1
 // BE-NEXT:[[CONV:%.*]] = sext i8 [[BF_ASHR]] to i32
@@ -29,7 +29,7 @@ int st0_check_load(struct st0 *m) {
 
 // LE-LABEL: @st0_check_store(
 // LE-NEXT:  entry:
-// LE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST0:%.*]], 
%struct.st0* [[M:%.*]], i32 0, i32 0
+// LE-NEXT:[[TMP0:%.*]] = getelementptr [[STRUCT_ST0:%.*]], %struct.st0* 
[[M:%.*]], i32 0, i32 0
 // LE-NEXT:[[BF_LOAD:%.*]] = load i8, i8* [[TMP0]], align 2
 // LE-NEXT:[[BF_CLEAR:%.*]] = and i8 [[BF_LOAD]], -128
 // LE-NEXT:[[BF_SET:%.*]] = or i8 [[BF_CLEAR]], 1
@@ -38,7 +38,7 @@ int st0_check_load(struct st0 *m) {
 //
 // BE-LABEL: @st0_check_store(
 // BE-NEXT:  entry:
-// BE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST0:%.*]], 
%struct.st0* [[M:%.*]], i32 0, i32 0
+// BE-NEXT:[[TMP0:%.*]] = getelementptr [[STRUCT_ST0:%.*]], %struct.st0* 
[[M:%.*]], i32 0, i32 0
 // BE-NEXT:[[BF_LOAD:%.*]] = load i8, i8* [[TMP0]], align 2
 // BE-NEXT:[[BF_CLEAR:%.*]] = and i8 [[BF_LOAD]], 1
 // BE-NEXT:[[BF_SET:%.*]] = or i8 [[BF_CLEAR]], 2
@@ -56,7 +56,7 @@ struct st1 {
 
 // LE-LABEL: @st1_check_load(
 // LE-NEXT:  entry:
-// LE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST1:%.*]], 
%struct.st1* [[M:%.*]], i32 0, i32 0
+// LE-NEXT:[[TMP0:%.*]] = getelementptr [[STRUCT_ST1:%.*]], %struct.st1* 
[[M:%.*]], i32 0, i32 0
 // LE-NEXT:[[BF_LOAD:%.*]] = load i16, i16* [[TMP0]], align 4
 // LE-NEXT:[[BF_ASHR:%.*]] = ashr i16 [[BF_LOAD]], 10
 // LE-NEXT:[[CONV:%.*]] = sext i16 [[BF_ASHR]] to i32
@@ -64,7 +64,7 @@ struct st1 {
 //
 // BE-LABEL: @st1_check_load(
 // BE-NEXT:  entry:
-// BE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST1:%.*]], 
%struct.st1* [[M:%.*]], i32 0, i32 0
+// BE-NEXT:[[TMP0:%.*]] = getelementptr [[STRUCT_ST1:%.*]], %struct.st1* 
[[M:%.*]], i32 0, i32 0
 // BE-NEXT:[[BF_LOAD:%.*]] = load i16, i16* [[TMP0]], align 4
 // BE-NEXT:[[BF_SHL:%.*]] = shl i16 [[BF_LOAD]], 10
 // BE-NEXT:[[BF_ASHR:%.*]] = ashr exact i16 [[BF_SHL]], 10
@@ -77,7 +77,7 @@ int st1_check_load(struct st1 *m) {
 
 // LE-LABEL: @st1_check_store(
 // LE-NEXT:  entry:
-// LE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST1:%.*]], 
%struct.st1* [[M:%.*]], i32 0, i32 0
+// LE-NEXT:[[TMP0:%.*]] = getelementptr [[STRUCT_ST1:%.*]], %struct.st1* 
[[M:%.*]], i32 0, i32 0
 // LE-NEXT:[[BF_LOAD:%.*]] = load i16, i16* [[TMP0]], align 4
 // LE-NEXT:[[BF_CLEAR:%.*]] = and i16 [[BF_LOAD]], 1023
 // LE-NEXT:[[BF_SET:%.*]] = or i16 [[BF_CLEAR]], 1024
@@ -86,7 +86,7 @@ int st1_check_load(struct st1 *m) {
 //
 // BE-LABEL: @st1_check_store(
 // BE-NEXT:  entry:
-// BE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST1:%.*]], 
%struct.st1* [[M:%.*]], i32 0, i32 0
+// BE-NEXT:[[TMP0:%.*]] = getelementptr [[STRUCT_ST1:%.*]], %struct.st1* 
[[M:%.*]], i32 0, i32 0
 // BE-NEXT:[[BF_LOAD:%.*]] = load i16, i16* [[TMP0]], align 4
 // BE-NEXT:[[BF_CLEAR:%.*]] = and i16 [[BF_LOAD]], -64
 // BE-NEXT:[[BF_SET:%.*]] = or i16 [[BF_CLEAR]], 1
@@ -151,7 +151,7 @@ s

[PATCH] D68526: [Diagnostics] Silence -Wsizeof-array-div for character buffers

2019-10-06 Thread Roman Lebedev via Phabricator via cfe-commits 
lebedev.ri added a comment.

There's not a single word in the patch's description.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68526/new/

https://reviews.llvm.org/D68526



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68551: [clang-format] [NFC] Ensure clang-format is itself clang-formatted.

2019-10-06 Thread Eugene Zelenko via Phabricator via cfe-commits 
Eugene.Zelenko added a comment.

If clang-format if clang-formatted now completely, I think will be good idea to 
add rule to check this during build, like Polly does.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68551/new/

https://reviews.llvm.org/D68551



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68526: [Diagnostics] Silence -Wsizeof-array-div for character buffers

2019-10-06 Thread James Clarke via Phabricator via cfe-commits 
jrtc27 added a comment.

In D68526#1696587 , @lebedev.ri wrote:

> There's not a single word in the patch's description.


If I were to add a description, it would be something like:

  Character buffers are sometimes used to represent a pool of memory that
  contains non-character objects, due to them being synonymous with a stream of
  bytes on almost all modern architectures. Often, when interacting with 
hardware
  devices, byte buffers are therefore used as an intermediary and so we can end
  Character buffers are sometimes used to represent a pool of memory that
  contains non-character objects, due to them being synonymous with a stream of
  bytes on almost all modern architectures. Often, when interacting with 
hardware
  devices, byte buffers are therefore used as an intermediary and so we can end
  up generating lots of false-positives.
  
  Moreover, due to the ability of character pointers to alias non-character
  pointers, the strict aliasing violations that would generally be implied by 
the
  calculations caught by the warning (if the calculation itself is in fact
  correct) do not apply here, and so although the length calculation may be
  wrong, that is the only possible issue.

But it seems that this first premise is actually wrong; at least in FreeBSD, 
and using a quick grep through Linux for obvious names (`sizeof.*buf) /`, 
`sizeof.*buffer) /` and `sizeof.*data) /`) I couldn't find one instance of an 
array where the types didn't match, but that was for `u64` vs `u32` so isn't 
even covered by this. Maybe it was true in the past, but these days people seem 
to be diligent about using the right types, with proper unions when needed.

The aliasing point still applies (in that this case is slightly less 
dangerous), but given it draws attention to code that may be able to be written 
more nicely with better types, I'd be inclined to abandon this. Unless people 
come screaming that we're spewing too many warnings for their code, that is, of 
course.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68526/new/

https://reviews.llvm.org/D68526



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68526: [Diagnostics] Silence -Wsizeof-array-div for character buffers

2019-10-06 Thread Dávid Bolvanský via Phabricator via cfe-commits 
xbolva00 added a comment.

I think I saw some false positives with char buffers, so I am not against this 
patch personally.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68526/new/

https://reviews.llvm.org/D68526



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68554: [clang-format] Proposal for clang-format to give compiler style warnings

2019-10-06 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: mitchell-stellar, klimek, owenpan.
MyDeveloperDay added projects: clang-format, clang-tools-extra.
Herald added a subscriber: mgorny.
Herald added a project: clang.

Related somewhat to D29039: [clang-format] Proposal for clang-format -r option 


On seeing a quote on twitter by @invalidop

> If it's not formatted with clang-format it's a build error.

This made me want to change the way I use clang-format into a tool that could 
optionally show me where my source code violates clang-format syle.

When I'm making a change to clang-format itself, one thing I like to do to test 
the change is to ensure I didn't cause a huge wave of changes, what I want to 
do is simply run this on a known formatted directory and see if any new 
differences arrive in a manner I'm used to.

This started me thinking that we should allow build systems to run clang-format 
on a whole tree and emit compiler style warnings about files that fail 
clang-format in a form that would make them as a warning in most build systems 
and because those build systems range in their construction I don't think its 
unreasonable to NOT expect them to have to do the directory searching or 
parsing the output replacements themselves, but simply transform that into an 
error code when there are changes required.

I am starting this by suggesing adding a -n or -dry-run command line argument 
which would emit a warning/error of the form

Support for various common compiler command line argumuments like '-Werror' and 
'-ferror-limit' could make this very flexible to be integrated into build 
systems and CI systems.

  > $ /usr/bin/clang-format --dry-run ClangFormat.cpp -ferror-limit=3 
-fcolor-diagnostics
  > ClangFormat.cpp:54:29: warning: code should be clang-formatted 
[-Wclang-format-violations]
  > static cl::list
  > ^
  > ClangFormat.cpp:55:20: warning: code should be clang-formatted 
[-Wclang-format-violations]
  > LineRanges("lines", cl::desc(": - format a range of\n"
  >^
  > ClangFormat.cpp:55:77: warning: code should be clang-formatted 
[-Wclang-format-violations]
  > LineRanges("lines", cl::desc(": - format a range of\n"
  > 
^


Repository:
  rC Clang

https://reviews.llvm.org/D68554

Files:
  clang/tools/clang-format/CMakeLists.txt
  clang/tools/clang-format/ClangFormat.cpp

Index: clang/tools/clang-format/ClangFormat.cpp
===
--- clang/tools/clang-format/ClangFormat.cpp
+++ clang/tools/clang-format/ClangFormat.cpp
@@ -18,6 +18,7 @@
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
 #include "clang/Format/Format.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
@@ -107,6 +108,54 @@
 Verbose("verbose", cl::desc("If set, shows the list of processed files"),
 cl::cat(ClangFormatCategory));
 
+// Use --dry-run to match other LLVM tools when you mean do it but don't
+// actually do it
+static cl::opt
+DryRun("dry-run",
+   cl::desc("If set, do not actually make the formatting changes"),
+   cl::cat(ClangFormatCategory));
+
+// Use -n as a common command as an alias for --dry-run. (git and make use -n)
+static cl::alias DryRunShort("n", cl::desc("Alias for --dry-run"),
+ cl::cat(ClangFormatCategory), cl::aliasopt(DryRun),
+ cl::NotHidden);
+
+// Emulate being able to turn on/off the warning.
+static cl::opt
+WarnFormat("Wclang-format-violations",
+   cl::desc("Warnings about individual formatting changes needed. "
+"Used only with --dry-run or -n"),
+   cl::init(true), cl::cat(ClangFormatCategory), cl::Hidden);
+
+static cl::opt
+NoWarnFormat("Wno-clang-format-violations",
+ cl::desc("Do not warn about individual formatting changes "
+  "needed. Used only with --dry-run or -n"),
+ cl::init(false), cl::cat(ClangFormatCategory), cl::Hidden);
+
+static cl::opt ErrorLimit(
+"ferror-limit",
+cl::desc("Set the maximum number of clang-format errors to emit before "
+ "stopping (0 = no limit). Used only with --dry-run or -n"),
+cl::init(0), cl::cat(ClangFormatCategory));
+
+static cl::opt
+WarningsAsErrors("Werror",
+ cl::desc("If set, changes formatting warnings to errors"),
+ cl::cat(ClangFormatCategory));
+
+static cl::opt
+ShowColors("fcolor-diagnostics",
+   cl::desc("If set, and on a color-capable terminal controls "
+"whether or not to print diagnostics in color"),
+   cl::init(true), cl::cat(Clang

[PATCH] D68554: [clang-format] Proposal for clang-format to give compiler style warnings

2019-10-06 Thread Manuel Klimek via Phabricator via cfe-commits 
klimek added a comment.

Why not build a tool that takes the diff output of clang-format and changes it 
to what you want? Wouldn't that be a couple of lines of python?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68554/new/

https://reviews.llvm.org/D68554



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68554: [clang-format] Proposal for clang-format to give compiler style warnings

2019-10-06 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added a comment.

In D68554#1696675 , @klimek wrote:

> Why not build a tool that takes the diff output of clang-format and changes 
> it to what you want? Wouldn't that be a couple of lines of python?


Thanks for taking the time to look at this idea. At least initially I can see 
that that would seem like a low impact way of doing it, and this also relates 
to D29039: [clang-format] Proposal for clang-format -r option 
, initially I felt this is not clang-formats 
job.. but the more I look online the more I see people using tricks to parse 
the output-replacements-xml

https://stackoverflow.com/questions/22866609/can-clang-format-tell-me-if-formatting-changes-are-necessary

But really what it means is each developer/group has to come up with their own 
solution or we have to develop some external python script.

But take a look at the hoops people are jumping thought just to determine if 
something needs to be formatted. All the additional tools like find/xargs/grep 
and these tools aren't always truly cross-platform, throw in additional 
complications of those people not using WSL,MingW or Cygwin and you now need a 
powershell or cmd.exe solution too. To make matters work every build system is 
different or needs some $shell() magic to run a series of commands, and all of 
that's before we even mention the whole python issue of getting it to work 
reliably in both Cygwin and/or Windows.  (did I even mention the whole color 
diagnostics etc.. that you get for free by reusing the LLVM classes)

When you consider that really apart of the setting up of the DiagnosticsEngine 
(which is a large portion of this code change), its actually quite a small fix. 
(which still needs lit tests in clang/test/Format I know, I'm trying to get 
those working and failing miserably)

This idea really amounts to making the xml  human-readable, in a 
way in which both developers but also build systems which are used to parsing 
and/or displaying the output of compilers know and understand.

Like the quote says, its about making clang-format violations seem much more 
like build errors:

> If it's not formatted with clang-format it's a build error.




Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68554/new/

https://reviews.llvm.org/D68554



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68539: [clang-tidy] fix for readability-identifier-naming incorrectly fixes variables which become keywords

2019-10-06 Thread Daniel via Phabricator via cfe-commits 
Daniel599 updated this revision to Diff 223429.
Daniel599 added a comment.

added -U99 to diff cmd


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68539/new/

https://reviews.llvm.org/D68539

Files:
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
  
clang-tools-extra/test/clang-tidy/readability-identifier-naming-bugfix-name-conflicts.cpp
  clang/include/clang/Basic/IdentifierTable.h

Index: clang/include/clang/Basic/IdentifierTable.h
===
--- clang/include/clang/Basic/IdentifierTable.h
+++ clang/include/clang/Basic/IdentifierTable.h
@@ -581,6 +581,8 @@
   iterator end() const   { return HashTable.end(); }
   unsigned size() const  { return HashTable.size(); }
 
+  iterator find(StringRef Name) const { return HashTable.find(Name); }
+
   /// Print some statistics to stderr that indicate how well the
   /// hashing is doing.
   void PrintStats() const;
Index: clang-tools-extra/test/clang-tidy/readability-identifier-naming-bugfix-name-conflicts.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/readability-identifier-naming-bugfix-name-conflicts.cpp
@@ -0,0 +1,15 @@
+// RUN: %check_clang_tidy %s readability-identifier-naming %t -- \
+// RUN:   -config='{CheckOptions: [ \
+// RUN: {key: readability-identifier-naming.ParameterCase, value: lower_case} \
+// RUN:   ]}'
+
+int func(int Break) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: invalid case style for parameter 'Break'. Cannot be fixed because 'break' would conflict with a language keyword
+  // CHECK-FIXES: {{^}}int func(int Break) {{{$}}
+  if (Break == 1) {
+// CHECK-FIXES: {{^}}  if (Break == 1) {{{$}}
+return 2;
+  }
+
+  return 0;
+}
\ No newline at end of file
Index: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
===
--- clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
+++ clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
@@ -64,6 +64,14 @@
 std::string Suffix;
   };
 
+  enum class ShouldFixStatus {
+ShouldFix,
+InsideMacro, /// if the identifier was used or declared within a macro we
+ /// won't offer a fixup for safety reasons.
+ConflictsWithKeyword /// The fixup will conflict with a language keyword, so
+ /// we can't fix it automatically
+  };
+
   /// Holds an identifier name check failure, tracking the kind of the
   /// identifer, its possible fixup and the starting locations of all the
   /// identifier usages.
@@ -75,13 +83,20 @@
 ///
 /// ie: if the identifier was used or declared within a macro we won't offer
 /// a fixup for safety reasons.
-bool ShouldFix;
+bool ShouldFix() const { return (FixStatus == ShouldFixStatus::ShouldFix); }
+
+bool ShouldNotify() const {
+  return (FixStatus == ShouldFixStatus::ShouldFix ||
+  FixStatus == ShouldFixStatus::ConflictsWithKeyword);
+}
+
+ShouldFixStatus FixStatus = ShouldFixStatus::ShouldFix;
 
 /// A set of all the identifier usages starting SourceLocation, in
 /// their encoded form.
 llvm::DenseSet RawUsageLocs;
 
-NamingCheckFailure() : ShouldFix(true) {}
+NamingCheckFailure() = default;
   };
 
   typedef std::pair NamingCheckId;
Index: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
===
--- clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
+++ clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
@@ -679,10 +679,11 @@
   if (!Failure.RawUsageLocs.insert(FixLocation.getRawEncoding()).second)
 return;
 
-  if (!Failure.ShouldFix)
+  if (!Failure.ShouldFix())
 return;
 
-  Failure.ShouldFix = utils::rangeCanBeFixed(Range, SourceMgr);
+  if (!utils::rangeCanBeFixed(Range, SourceMgr))
+Failure.FixStatus = IdentifierNamingCheck::ShouldFixStatus::InsideMacro;
 }
 
 /// Convenience method when the usage to be added is a NamedDecl
@@ -861,6 +862,13 @@
   DeclarationNameInfo(Decl->getDeclName(), Decl->getLocation())
   .getSourceRange();
 
+  IdentifierTable &Idents = Decl->getASTContext().Idents;
+  auto CheckNewIdentifier = Idents.find(Fixup);
+  if (CheckNewIdentifier != Idents.end() &&
+  CheckNewIdentifier->second->isKeyword(getLangOpts())) {
+Failure.FixStatus = ShouldFixStatus::ConflictsWithKeyword;
+  }
+
   Failure.Fixup = std::move(Fixup);
   Failure.KindName = std::move(KindName);
   addUsage(NamingCheckFailures, Decl, Range);
@@ -923,24 +931,35 @@
 if (Failure.KindName.empty())
   continue;
 
-if (Failure.ShouldFix) {
-  auto Diag = diag(Decl.first, "invalid case style

r373862 - [Sema] Avoids an assertion failure when an invalid conversion declaration is used

2019-10-06 Thread Richard Smith via cfe-commits 
Author: rsmith
Date: Sun Oct  6 11:40:59 2019
New Revision: 373862

URL: http://llvm.org/viewvc/llvm-project?rev=373862&view=rev
Log:
[Sema] Avoids an assertion failure when an invalid conversion declaration is 
used

Summary:
When using a user-defined conversion function template with a deduced return 
type the compiler gives a set of warnings:
```
bug.cc:252:44: error: cannot specify any part of a return type in the 
declaration of a conversion function; use an alias template to declare a 
conversion to 'auto (Ts &&...) const'
  template  operator auto()(Ts &&... xs) const;
   ^~~
bug.cc:252:29: error: conversion function cannot convert to a function type
  template  operator auto()(Ts &&... xs) const;
^
error: pointer to function type cannot have 'const' qualifier
```
after which it triggers an assertion failure. It seems the last error is 
incorrect and doesn't have any location information. This patch stops the 
compilation after the second warning.

Fixes bug 31422.

Patch by Mark de Wever!

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: bbannier, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64820

Added:
cfe/trunk/test/SemaCXX/PR31422.cpp
Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=373862&r1=373861&r2=373862&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Sun Oct  6 11:40:59 2019
@@ -8206,6 +8206,9 @@ static FunctionDecl *CreateNewFunctionDe
 }
 
 SemaRef.CheckConversionDeclarator(D, R, SC);
+if (D.isInvalidType())
+  return nullptr;
+
 IsVirtualOkay = true;
 return CXXConversionDecl::Create(
 SemaRef.Context, cast(DC), D.getBeginLoc(), NameInfo, R,

Added: cfe/trunk/test/SemaCXX/PR31422.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/PR31422.cpp?rev=373862&view=auto
==
--- cfe/trunk/test/SemaCXX/PR31422.cpp (added)
+++ cfe/trunk/test/SemaCXX/PR31422.cpp Sun Oct  6 11:40:59 2019
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
+
+// expected-error@+3 {{cannot specify any part of a return type in the 
declaration of a conversion function; use an alias template to declare a 
conversion to 'auto (Ts &&...) const'}}
+// expected-error@+2 {{conversion function cannot convert to a function type}}
+struct S {
+  template  operator auto()(Ts &&... xs) const;
+};


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64820: [Sema] Avoids an assertion failure when an invalid conversion declaration is used

2019-10-06 Thread Richard Smith - zygoloid via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL373862: [Sema] Avoids an assertion failure when an invalid 
conversion declaration is… (authored by rsmith, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64820?vs=218213&id=223434#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64820/new/

https://reviews.llvm.org/D64820

Files:
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/test/SemaCXX/PR31422.cpp


Index: cfe/trunk/test/SemaCXX/PR31422.cpp
===
--- cfe/trunk/test/SemaCXX/PR31422.cpp
+++ cfe/trunk/test/SemaCXX/PR31422.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
+
+// expected-error@+3 {{cannot specify any part of a return type in the 
declaration of a conversion function; use an alias template to declare a 
conversion to 'auto (Ts &&...) const'}}
+// expected-error@+2 {{conversion function cannot convert to a function type}}
+struct S {
+  template  operator auto()(Ts &&... xs) const;
+};
Index: cfe/trunk/lib/Sema/SemaDecl.cpp
===
--- cfe/trunk/lib/Sema/SemaDecl.cpp
+++ cfe/trunk/lib/Sema/SemaDecl.cpp
@@ -8206,6 +8206,9 @@
 }
 
 SemaRef.CheckConversionDeclarator(D, R, SC);
+if (D.isInvalidType())
+  return nullptr;
+
 IsVirtualOkay = true;
 return CXXConversionDecl::Create(
 SemaRef.Context, cast(DC), D.getBeginLoc(), NameInfo, R,


Index: cfe/trunk/test/SemaCXX/PR31422.cpp
===
--- cfe/trunk/test/SemaCXX/PR31422.cpp
+++ cfe/trunk/test/SemaCXX/PR31422.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
+
+// expected-error@+3 {{cannot specify any part of a return type in the declaration of a conversion function; use an alias template to declare a conversion to 'auto (Ts &&...) const'}}
+// expected-error@+2 {{conversion function cannot convert to a function type}}
+struct S {
+  template  operator auto()(Ts &&... xs) const;
+};
Index: cfe/trunk/lib/Sema/SemaDecl.cpp
===
--- cfe/trunk/lib/Sema/SemaDecl.cpp
+++ cfe/trunk/lib/Sema/SemaDecl.cpp
@@ -8206,6 +8206,9 @@
 }
 
 SemaRef.CheckConversionDeclarator(D, R, SC);
+if (D.isInvalidType())
+  return nullptr;
+
 IsVirtualOkay = true;
 return CXXConversionDecl::Create(
 SemaRef.Context, cast(DC), D.getBeginLoc(), NameInfo, R,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r373866 - Implements CWG 1601 in [over.ics.rank/4.2]

2019-10-06 Thread Richard Smith via cfe-commits 
Author: rsmith
Date: Sun Oct  6 11:50:40 2019
New Revision: 373866

URL: http://llvm.org/viewvc/llvm-project?rev=373866&view=rev
Log:
Implements CWG 1601 in [over.ics.rank/4.2]

Summary:
The overload resolution for enums with a fixed underlying type has changed in 
the C++14 standard. This patch implements the new rule.

Patch by Mark de Wever!

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D65695

Modified:
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/test/CXX/drs/dr16xx.cpp
cfe/trunk/test/CXX/drs/dr6xx.cpp
cfe/trunk/www/cxx_dr_status.html

Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=373866&r1=373865&r2=373866&view=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Sun Oct  6 11:50:40 2019
@@ -3765,6 +3765,34 @@ isBetterReferenceBindingKind(const Stand
   !SCS2.IsLvalueReference && SCS2.BindsToFunctionLvalue);
 }
 
+enum class FixedEnumPromotion {
+  None,
+  ToUnderlyingType,
+  ToPromotedUnderlyingType
+};
+
+/// Returns kind of fixed enum promotion the \a SCS uses.
+static FixedEnumPromotion
+getFixedEnumPromtion(Sema &S, const StandardConversionSequence &SCS) {
+
+  if (SCS.Second != ICK_Integral_Promotion)
+return FixedEnumPromotion::None;
+
+  QualType FromType = SCS.getFromType();
+  if (!FromType->isEnumeralType())
+return FixedEnumPromotion::None;
+
+  EnumDecl *Enum = FromType->getAs()->getDecl();
+  if (!Enum->isFixed())
+return FixedEnumPromotion::None;
+
+  QualType UnderlyingType = Enum->getIntegerType();
+  if (S.Context.hasSameType(SCS.getToType(1), UnderlyingType))
+return FixedEnumPromotion::ToUnderlyingType;
+
+  return FixedEnumPromotion::ToPromotedUnderlyingType;
+}
+
 /// CompareStandardConversionSequences - Compare two standard
 /// conversion sequences to determine whether one is better than the
 /// other or if they are indistinguishable (C++ 13.3.3.2p3).
@@ -3806,6 +3834,20 @@ CompareStandardConversionSequences(Sema
  ? ImplicitConversionSequence::Better
  : ImplicitConversionSequence::Worse;
 
+  // C++14 [over.ics.rank]p4b2:
+  // This is retroactively applied to C++11 by CWG 1601.
+  //
+  //   A conversion that promotes an enumeration whose underlying type is fixed
+  //   to its underlying type is better than one that promotes to the promoted
+  //   underlying type, if the two are different.
+  FixedEnumPromotion FEP1 = getFixedEnumPromtion(S, SCS1);
+  FixedEnumPromotion FEP2 = getFixedEnumPromtion(S, SCS2);
+  if (FEP1 != FixedEnumPromotion::None && FEP2 != FixedEnumPromotion::None &&
+  FEP1 != FEP2)
+return FEP1 == FixedEnumPromotion::ToUnderlyingType
+   ? ImplicitConversionSequence::Better
+   : ImplicitConversionSequence::Worse;
+
   // C++ [over.ics.rank]p4b2:
   //
   //   If class B is derived directly or indirectly from class A,

Modified: cfe/trunk/test/CXX/drs/dr16xx.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/drs/dr16xx.cpp?rev=373866&r1=373865&r2=373866&view=diff
==
--- cfe/trunk/test/CXX/drs/dr16xx.cpp (original)
+++ cfe/trunk/test/CXX/drs/dr16xx.cpp Sun Oct  6 11:50:40 2019
@@ -23,6 +23,18 @@ namespace std {
 } // std
 #endif
 
+namespace dr1601 { // dr1601: 10
+enum E : char { e };
+#if __cplusplus < 201103L
+// expected-error@-2 {{enumeration types with a fixed underlying type are 
a C++11 extension}}
+#endif
+void f(char);
+void f(int);
+void g() {
+  f(e);
+}
+} // namespace dr1601
+
 namespace dr1611 { // dr1611: dup 1658
   struct A { A(int); };
   struct B : virtual A { virtual void f() = 0; };

Modified: cfe/trunk/test/CXX/drs/dr6xx.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/drs/dr6xx.cpp?rev=373866&r1=373865&r2=373866&view=diff
==
--- cfe/trunk/test/CXX/drs/dr6xx.cpp (original)
+++ cfe/trunk/test/CXX/drs/dr6xx.cpp Sun Oct  6 11:50:40 2019
@@ -987,14 +987,19 @@ namespace dr684 { // dr684: sup 1454
 }
 #endif
 
-#if __cplusplus >= 201103L
 namespace dr685 { // dr685: yes
   enum E : long { e };
+#if __cplusplus < 201103L
+// expected-error@-2 {{enumeration types with a fixed underlying type are 
a C++11 extension}}
+#endif
   void f(int);
   int f(long);
   int a = f(e);
 
   enum G : short { g };
+#if __cplusplus < 201103L
+// expected-error@-2 {{enumeration types with a fixed underlying type are 
a C++11 extension}}
+#endif
   int h(short);
   void h(long);
   int b = h(g);
@@ -1007,11 +1012,11 @@ namespace dr685 { // dr685: yes
   void j(long); // expected-note {{candidate}}
   int d = j(g); // expected-error {{ambiguous}}
 
-  int k(short); // expected-note {{cand

[PATCH] D65695: Implements CWG 1601 in [over.ics.rank/4.2]

2019-10-06 Thread Richard Smith - zygoloid via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL373866: Implements CWG 1601 in [over.ics.rank/4.2] (authored 
by rsmith, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65695?vs=218216&id=223437#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65695/new/

https://reviews.llvm.org/D65695

Files:
  cfe/trunk/lib/Sema/SemaOverload.cpp
  cfe/trunk/test/CXX/drs/dr16xx.cpp
  cfe/trunk/test/CXX/drs/dr6xx.cpp
  cfe/trunk/www/cxx_dr_status.html

Index: cfe/trunk/lib/Sema/SemaOverload.cpp
===
--- cfe/trunk/lib/Sema/SemaOverload.cpp
+++ cfe/trunk/lib/Sema/SemaOverload.cpp
@@ -3765,6 +3765,34 @@
   !SCS2.IsLvalueReference && SCS2.BindsToFunctionLvalue);
 }
 
+enum class FixedEnumPromotion {
+  None,
+  ToUnderlyingType,
+  ToPromotedUnderlyingType
+};
+
+/// Returns kind of fixed enum promotion the \a SCS uses.
+static FixedEnumPromotion
+getFixedEnumPromtion(Sema &S, const StandardConversionSequence &SCS) {
+
+  if (SCS.Second != ICK_Integral_Promotion)
+return FixedEnumPromotion::None;
+
+  QualType FromType = SCS.getFromType();
+  if (!FromType->isEnumeralType())
+return FixedEnumPromotion::None;
+
+  EnumDecl *Enum = FromType->getAs()->getDecl();
+  if (!Enum->isFixed())
+return FixedEnumPromotion::None;
+
+  QualType UnderlyingType = Enum->getIntegerType();
+  if (S.Context.hasSameType(SCS.getToType(1), UnderlyingType))
+return FixedEnumPromotion::ToUnderlyingType;
+
+  return FixedEnumPromotion::ToPromotedUnderlyingType;
+}
+
 /// CompareStandardConversionSequences - Compare two standard
 /// conversion sequences to determine whether one is better than the
 /// other or if they are indistinguishable (C++ 13.3.3.2p3).
@@ -3806,6 +3834,20 @@
  ? ImplicitConversionSequence::Better
  : ImplicitConversionSequence::Worse;
 
+  // C++14 [over.ics.rank]p4b2:
+  // This is retroactively applied to C++11 by CWG 1601.
+  //
+  //   A conversion that promotes an enumeration whose underlying type is fixed
+  //   to its underlying type is better than one that promotes to the promoted
+  //   underlying type, if the two are different.
+  FixedEnumPromotion FEP1 = getFixedEnumPromtion(S, SCS1);
+  FixedEnumPromotion FEP2 = getFixedEnumPromtion(S, SCS2);
+  if (FEP1 != FixedEnumPromotion::None && FEP2 != FixedEnumPromotion::None &&
+  FEP1 != FEP2)
+return FEP1 == FixedEnumPromotion::ToUnderlyingType
+   ? ImplicitConversionSequence::Better
+   : ImplicitConversionSequence::Worse;
+
   // C++ [over.ics.rank]p4b2:
   //
   //   If class B is derived directly or indirectly from class A,
Index: cfe/trunk/www/cxx_dr_status.html
===
--- cfe/trunk/www/cxx_dr_status.html
+++ cfe/trunk/www/cxx_dr_status.html
@@ -9421,7 +9421,7 @@
 http://wg21.link/cwg1601";>1601
 C++14
 Promotion of enumeration with fixed underlying type
-Unknown
+SVN
   
   
 http://wg21.link/cwg1602";>1602
Index: cfe/trunk/test/CXX/drs/dr6xx.cpp
===
--- cfe/trunk/test/CXX/drs/dr6xx.cpp
+++ cfe/trunk/test/CXX/drs/dr6xx.cpp
@@ -987,14 +987,19 @@
 }
 #endif
 
-#if __cplusplus >= 201103L
 namespace dr685 { // dr685: yes
   enum E : long { e };
+#if __cplusplus < 201103L
+// expected-error@-2 {{enumeration types with a fixed underlying type are a C++11 extension}}
+#endif
   void f(int);
   int f(long);
   int a = f(e);
 
   enum G : short { g };
+#if __cplusplus < 201103L
+// expected-error@-2 {{enumeration types with a fixed underlying type are a C++11 extension}}
+#endif
   int h(short);
   void h(long);
   int b = h(g);
@@ -1007,11 +1012,11 @@
   void j(long); // expected-note {{candidate}}
   int d = j(g); // expected-error {{ambiguous}}
 
-  int k(short); // expected-note {{candidate}}
-  void k(int); // expected-note {{candidate}}
-  int x = k(g); // expected-error {{ambiguous}}
+  // Valid per dr1601
+  int k(short);
+  void k(int);
+  int x = k(g);
 }
-#endif
 
 namespace dr686 { // dr686: yes
   void f() {
Index: cfe/trunk/test/CXX/drs/dr16xx.cpp
===
--- cfe/trunk/test/CXX/drs/dr16xx.cpp
+++ cfe/trunk/test/CXX/drs/dr16xx.cpp
@@ -23,6 +23,18 @@
 } // std
 #endif
 
+namespace dr1601 { // dr1601: 10
+enum E : char { e };
+#if __cplusplus < 201103L
+// expected-error@-2 {{enumeration types with a fixed underlying type are a C++11 extension}}
+#endif
+void f(char);
+void f(int);
+void g() {
+  f(e);
+}
+} // namespace dr1601
+
 namespace dr1611 { // dr1611: dup 1658
   struct A { A(int); };
   struct B : virtual A { virtual void f() = 0; };
___
cfe-commits mailing list
cfe-commits@lists.llvm

[PATCH] D68377: [Builtins] Teach Clang about memccpy

2019-10-06 Thread Dávid Bolvanský via Phabricator via cfe-commits 
xbolva00 updated this revision to Diff 223440.
xbolva00 added a comment.

Added some tests


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68377/new/

https://reviews.llvm.org/D68377

Files:
  include/clang/Basic/Builtins.def
  test/CodeGen/builtin-memfns.c
  test/CodeGen/memccpy-libcall.c


Index: test/CodeGen/memccpy-libcall.c
===
--- test/CodeGen/memccpy-libcall.c
+++ test/CodeGen/memccpy-libcall.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fno-builtin-memccpy -emit-llvm < %s| FileCheck %s
+
+typedef __SIZE_TYPE__ size_t;
+
+void *memccpy(void *, void const *, int, size_t);
+
+void test13(char *d, char *s, int c, size_t n) {
+  // CHECK: call i8* @memccpy{{.*}} #2
+  memccpy(d, s, c, n);
+}
+
+// CHECK: attributes #2 = { nobuiltin }
Index: test/CodeGen/builtin-memfns.c
===
--- test/CodeGen/builtin-memfns.c
+++ test/CodeGen/builtin-memfns.c
@@ -4,6 +4,7 @@
 typedef __SIZE_TYPE__ size_t;
 
 void *memcpy(void *, void const *, size_t);
+void *memccpy(void *, void const *, int, size_t);
 
 // CHECK: @test1
 // CHECK: call void @llvm.memset.p0i8.i32
@@ -118,3 +119,9 @@
   // CHECK: call void @llvm.memcpy{{.*}}(
   memcpy(&dest_array, &dest_array, 2);
 }
+
+// CHECK-LABEL: @test13
+void test13(char *d, char *s, int c, size_t n) {
+  // CHECK: call i8* @memccpy
+  memccpy(d, s, c, n);
+}
Index: include/clang/Basic/Builtins.def
===
--- include/clang/Basic/Builtins.def
+++ include/clang/Basic/Builtins.def
@@ -979,6 +979,7 @@
 // when these functions are used in non-GNU mode. PR16138.
 LIBBUILTIN(alloca, "v*z", "f", "stdlib.h", ALL_GNU_LANGUAGES)
 // POSIX string.h
+LIBBUILTIN(memccpy, "v*v*vC*iz",  "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(stpcpy, "c*c*cC*", "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(stpncpy, "c*c*cC*z",   "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(strdup, "c*cC*",   "f", "string.h", ALL_GNU_LANGUAGES)


Index: test/CodeGen/memccpy-libcall.c
===
--- test/CodeGen/memccpy-libcall.c
+++ test/CodeGen/memccpy-libcall.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fno-builtin-memccpy -emit-llvm < %s| FileCheck %s
+
+typedef __SIZE_TYPE__ size_t;
+
+void *memccpy(void *, void const *, int, size_t);
+
+void test13(char *d, char *s, int c, size_t n) {
+  // CHECK: call i8* @memccpy{{.*}} #2
+  memccpy(d, s, c, n);
+}
+
+// CHECK: attributes #2 = { nobuiltin }
Index: test/CodeGen/builtin-memfns.c
===
--- test/CodeGen/builtin-memfns.c
+++ test/CodeGen/builtin-memfns.c
@@ -4,6 +4,7 @@
 typedef __SIZE_TYPE__ size_t;
 
 void *memcpy(void *, void const *, size_t);
+void *memccpy(void *, void const *, int, size_t);
 
 // CHECK: @test1
 // CHECK: call void @llvm.memset.p0i8.i32
@@ -118,3 +119,9 @@
   // CHECK: call void @llvm.memcpy{{.*}}(
   memcpy(&dest_array, &dest_array, 2);
 }
+
+// CHECK-LABEL: @test13
+void test13(char *d, char *s, int c, size_t n) {
+  // CHECK: call i8* @memccpy
+  memccpy(d, s, c, n);
+}
Index: include/clang/Basic/Builtins.def
===
--- include/clang/Basic/Builtins.def
+++ include/clang/Basic/Builtins.def
@@ -979,6 +979,7 @@
 // when these functions are used in non-GNU mode. PR16138.
 LIBBUILTIN(alloca, "v*z", "f", "stdlib.h", ALL_GNU_LANGUAGES)
 // POSIX string.h
+LIBBUILTIN(memccpy, "v*v*vC*iz",  "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(stpcpy, "c*c*cC*", "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(stpncpy, "c*c*cC*z",   "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(strdup, "c*cC*",   "f", "string.h", ALL_GNU_LANGUAGES)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68377: [Builtins] Teach Clang about memccpy

2019-10-06 Thread Dávid Bolvanský via Phabricator via cfe-commits 
xbolva00 updated this revision to Diff 223441.
xbolva00 added a comment.

Added it for msvc too.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68377/new/

https://reviews.llvm.org/D68377

Files:
  include/clang/Basic/Builtins.def
  test/CodeGen/builtin-memfns.c
  test/CodeGen/memccpy-libcall.c


Index: test/CodeGen/memccpy-libcall.c
===
--- test/CodeGen/memccpy-libcall.c
+++ test/CodeGen/memccpy-libcall.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fno-builtin-memccpy -emit-llvm < %s| FileCheck %s
+
+typedef __SIZE_TYPE__ size_t;
+
+void *memccpy(void *, void const *, int, size_t);
+
+void test13(char *d, char *s, int c, size_t n) {
+  // CHECK: call i8* @memccpy{{.*}} #2
+  memccpy(d, s, c, n);
+}
+
+// CHECK: attributes #2 = { nobuiltin }
Index: test/CodeGen/builtin-memfns.c
===
--- test/CodeGen/builtin-memfns.c
+++ test/CodeGen/builtin-memfns.c
@@ -4,6 +4,7 @@
 typedef __SIZE_TYPE__ size_t;
 
 void *memcpy(void *, void const *, size_t);
+void *memccpy(void *, void const *, int, size_t);
 
 // CHECK: @test1
 // CHECK: call void @llvm.memset.p0i8.i32
@@ -118,3 +119,9 @@
   // CHECK: call void @llvm.memcpy{{.*}}(
   memcpy(&dest_array, &dest_array, 2);
 }
+
+// CHECK-LABEL: @test13
+void test13(char *d, char *s, int c, size_t n) {
+  // CHECK: call i8* @memccpy
+  memccpy(d, s, c, n);
+}
Index: include/clang/Basic/Builtins.def
===
--- include/clang/Basic/Builtins.def
+++ include/clang/Basic/Builtins.def
@@ -876,7 +876,8 @@
 LANGBUILTIN(__fastfail, "vUi","nr", ALL_MS_LANGUAGES)
 
 // Microsoft library builtins.
-LIBBUILTIN(_setjmpex, "iJ", "fj",   "setjmpex.h", ALL_MS_LANGUAGES)
+LIBBUILTIN(_setjmpex, "iJ", "fj", "setjmpex.h", ALL_MS_LANGUAGES)
+LIBBUILTIN(memccpy,   "v*v*vC*iz",  "f",  "string.h",   ALL_MS_LANGUAGES)
 
 // C99 library functions
 // C99 stdarg.h
@@ -979,6 +980,7 @@
 // when these functions are used in non-GNU mode. PR16138.
 LIBBUILTIN(alloca, "v*z", "f", "stdlib.h", ALL_GNU_LANGUAGES)
 // POSIX string.h
+LIBBUILTIN(memccpy, "v*v*vC*iz",  "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(stpcpy, "c*c*cC*", "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(stpncpy, "c*c*cC*z",   "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(strdup, "c*cC*",   "f", "string.h", ALL_GNU_LANGUAGES)


Index: test/CodeGen/memccpy-libcall.c
===
--- test/CodeGen/memccpy-libcall.c
+++ test/CodeGen/memccpy-libcall.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fno-builtin-memccpy -emit-llvm < %s| FileCheck %s
+
+typedef __SIZE_TYPE__ size_t;
+
+void *memccpy(void *, void const *, int, size_t);
+
+void test13(char *d, char *s, int c, size_t n) {
+  // CHECK: call i8* @memccpy{{.*}} #2
+  memccpy(d, s, c, n);
+}
+
+// CHECK: attributes #2 = { nobuiltin }
Index: test/CodeGen/builtin-memfns.c
===
--- test/CodeGen/builtin-memfns.c
+++ test/CodeGen/builtin-memfns.c
@@ -4,6 +4,7 @@
 typedef __SIZE_TYPE__ size_t;
 
 void *memcpy(void *, void const *, size_t);
+void *memccpy(void *, void const *, int, size_t);
 
 // CHECK: @test1
 // CHECK: call void @llvm.memset.p0i8.i32
@@ -118,3 +119,9 @@
   // CHECK: call void @llvm.memcpy{{.*}}(
   memcpy(&dest_array, &dest_array, 2);
 }
+
+// CHECK-LABEL: @test13
+void test13(char *d, char *s, int c, size_t n) {
+  // CHECK: call i8* @memccpy
+  memccpy(d, s, c, n);
+}
Index: include/clang/Basic/Builtins.def
===
--- include/clang/Basic/Builtins.def
+++ include/clang/Basic/Builtins.def
@@ -876,7 +876,8 @@
 LANGBUILTIN(__fastfail, "vUi","nr", ALL_MS_LANGUAGES)
 
 // Microsoft library builtins.
-LIBBUILTIN(_setjmpex, "iJ", "fj",   "setjmpex.h", ALL_MS_LANGUAGES)
+LIBBUILTIN(_setjmpex, "iJ", "fj", "setjmpex.h", ALL_MS_LANGUAGES)
+LIBBUILTIN(memccpy,   "v*v*vC*iz",  "f",  "string.h",   ALL_MS_LANGUAGES)
 
 // C99 library functions
 // C99 stdarg.h
@@ -979,6 +980,7 @@
 // when these functions are used in non-GNU mode. PR16138.
 LIBBUILTIN(alloca, "v*z", "f", "stdlib.h", ALL_GNU_LANGUAGES)
 // POSIX string.h
+LIBBUILTIN(memccpy, "v*v*vC*iz",  "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(stpcpy, "c*c*cC*", "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(stpncpy, "c*c*cC*z",   "f", "string.h", ALL_GNU_LANGUAGES)
 LIBBUILTIN(strdup, "c*cC*",   "f", "string.h", ALL_GNU_LANGUAGES)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68377: [Builtins] Teach Clang about memccpy

2019-10-06 Thread Dávid Bolvanský via Phabricator via cfe-commits 
xbolva00 added a subscriber: RKSimon.
xbolva00 added a comment.

Hm,
Maybe we have a bug in LLVM's TLI? TLI says Win32 has no memccpy.
https://llvm.org/doxygen/TargetLibraryInfo_8cpp_source.html line 333

cc @RKSimon since he knows windows-related things more.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68377/new/

https://reviews.llvm.org/D68377



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33029: [clang-format] add option for dangling parenthesis

2019-10-06 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay added a comment.

@stringham  you seemingly have marked this revision so that no one else can 
edit it, so I cannot add it to the clang-format project or reassign reviewers, 
could you please change it to be public, it also means others cannot request 
changes or approve it (if they wanted to)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D33029/new/

https://reviews.llvm.org/D33029



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31574: [clang-format] update documentation

2019-10-06 Thread Duncan Ogilvie via Phabricator via cfe-commits 
mrexodia updated this revision to Diff 223443.
mrexodia edited the summary of this revision.
mrexodia removed reviewers: klimek, djasper.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D31574/new/

https://reviews.llvm.org/D31574

Files:
  clang/include/clang/Format/Format.h


Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -1077,6 +1077,16 @@
   bool BreakAfterJavaFieldAnnotations;
 
   /// Allow breaking string literals when formatting.
+  /// \code
+  ///true:
+  ///const char* x = "veryVeryVeryVeryVeryVe"
+  ///"ryVeryVeryVeryVeryVery"
+  ///"VeryLongString";
+  ///
+  ///false:
+  ///const char* x =
+  ///  "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
+  /// \endcode
   bool BreakStringLiterals;
 
   /// The column limit. 


Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -1077,6 +1077,16 @@
   bool BreakAfterJavaFieldAnnotations;
 
   /// Allow breaking string literals when formatting.
+  /// \code
+  ///true:
+  ///const char* x = "veryVeryVeryVeryVeryVe"
+  ///"ryVeryVeryVeryVeryVery"
+  ///"VeryLongString";
+  ///
+  ///false:
+  ///const char* x =
+  ///  "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
+  /// \endcode
   bool BreakStringLiterals;
 
   /// The column limit. 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33029: [clang-format] add option for dangling parenthesis

2019-10-06 Thread Ryan Stringham via Phabricator via cfe-commits 
stringham added a comment.

@MyDeveloperDay done


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D33029/new/

https://reviews.llvm.org/D33029



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66046: Add new tautological compare warning for bitwise-or with a non-zero constant

2019-10-06 Thread Dávid Bolvanský via Phabricator via cfe-commits 
xbolva00 added a comment.

Could this patch solve https://bugs.llvm.org/show_bug.cgi?id=43573?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66046/new/

https://reviews.llvm.org/D66046



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66043: Add to -Wparentheses case of bitwise-and ("&") and bitwise-or ("|") verses conditional operator ("?:")

2019-10-06 Thread Dávid Bolvanský via Phabricator via cfe-commits 
xbolva00 added a comment.

Do you plan to land it?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66043/new/

https://reviews.llvm.org/D66043



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31574: [clang-format] update documentation

2019-10-06 Thread MyDeveloperDay via Phabricator via cfe-commits 
MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D31574/new/

https://reviews.llvm.org/D31574



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67980: [CLANG][BPF] do compile-once run-everywhere relocation for bitfields

2019-10-06 Thread Alexei Starovoitov via Phabricator via cfe-commits 
ast accepted this revision.
ast added a comment.
This revision is now accepted and ready to land.

lgtm. thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67980/new/

https://reviews.llvm.org/D67980



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68340: Add AIX toolchain and basic linker functionality

2019-10-06 Thread Jason Liu via Phabricator via cfe-commits 
jasonliu added a comment.

Any reason we are testing library search path using libgcc.a? We could use any 
dummy path there, and upload a dummy archive library for the testing purpose.




Comment at: clang/lib/Driver/ToolChains/AIX.cpp:112
+
+AIX::~AIX() {}
+

We are not doing anything with the destructor. Do we need to declare and define 
it?



Comment at: clang/lib/Driver/ToolChains/AIX.h:1
+//===--- AIX.h - AIX ToolChain Implementations --*- C++ -*-===//
+//

The length of this line should match with line 7. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68340/new/

https://reviews.llvm.org/D68340



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68340: Add AIX toolchain and basic linker functionality

2019-10-06 Thread Jason Liu via Phabricator via cfe-commits 
jasonliu added a comment.

nit: We might want to add period consistently for all the comments in the patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68340/new/

https://reviews.llvm.org/D68340



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r373874 - Fix behavior of __builtin_bit_cast when the From and To types are the

2019-10-06 Thread Richard Smith via cfe-commits 
Author: rsmith
Date: Sun Oct  6 19:45:12 2019
New Revision: 373874

URL: http://llvm.org/viewvc/llvm-project?rev=373874&view=rev
Log:
Fix behavior of __builtin_bit_cast when the From and To types are the
same.

We were missing the lvalue-to-rvalue conversion entirely in this case,
and in fact still need the full CK_LValueToRValueBitCast conversion to
perform a load with no TBAA.

Modified:
cfe/trunk/include/clang/AST/OperationKinds.def
cfe/trunk/lib/Sema/SemaCast.cpp
cfe/trunk/test/CodeGenCXX/builtin-bit-cast-no-tbaa.cpp
cfe/trunk/test/SemaCXX/constexpr-builtin-bit-cast.cpp

Modified: cfe/trunk/include/clang/AST/OperationKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/OperationKinds.def?rev=373874&r1=373873&r2=373874&view=diff
==
--- cfe/trunk/include/clang/AST/OperationKinds.def (original)
+++ cfe/trunk/include/clang/AST/OperationKinds.def Sun Oct  6 19:45:12 2019
@@ -66,8 +66,9 @@ CAST_OPERATION(BitCast)
 ///bool b; reinterpret_cast(b) = 'a';
 CAST_OPERATION(LValueBitCast)
 
-/// CK_LValueToRValueBitCast - A conversion that causes us to reinterpret an
-/// lvalue as an rvalue of a different type. Created by __builtin_bit_cast.
+/// CK_LValueToRValueBitCast - A conversion that causes us to reinterpret the
+/// object representation of an lvalue as an rvalue. Created by
+/// __builtin_bit_cast.
 CAST_OPERATION(LValueToRValueBitCast)
 
 /// CK_LValueToRValue - A conversion which causes the extraction of

Modified: cfe/trunk/lib/Sema/SemaCast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCast.cpp?rev=373874&r1=373873&r2=373874&view=diff
==
--- cfe/trunk/lib/Sema/SemaCast.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCast.cpp Sun Oct  6 19:45:12 2019
@@ -2835,11 +2835,6 @@ void CastOperation::CheckBuiltinBitCast(
 return;
   }
 
-  if (Self.Context.hasSameUnqualifiedType(DestType, SrcType)) {
-Kind = CK_NoOp;
-return;
-  }
-
   Kind = CK_LValueToRValueBitCast;
 }
 

Modified: cfe/trunk/test/CodeGenCXX/builtin-bit-cast-no-tbaa.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/builtin-bit-cast-no-tbaa.cpp?rev=373874&r1=373873&r2=373874&view=diff
==
--- cfe/trunk/test/CodeGenCXX/builtin-bit-cast-no-tbaa.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/builtin-bit-cast-no-tbaa.cpp Sun Oct  6 19:45:12 
2019
@@ -15,5 +15,10 @@ void test_scalar2() {
   // CHECK: load i32, i32* {{.*}}, align 4, !tbaa ![[MAY_ALIAS_TBAA]]
 }
 
+int test_same_type(int &r) {
+  // CHECK: load i32, i32* {{.*}}, align 4, !tbaa ![[MAY_ALIAS_TBAA]]
+  return __builtin_bit_cast(int, r);
+}
+
 // CHECK: ![[CHAR_TBAA:.*]] = !{!"omnipotent char", {{.*}}, i64 0}
 // CHECK: ![[MAY_ALIAS_TBAA]] = !{![[CHAR_TBAA]], ![[CHAR_TBAA]], i64 0}

Modified: cfe/trunk/test/SemaCXX/constexpr-builtin-bit-cast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/constexpr-builtin-bit-cast.cpp?rev=373874&r1=373873&r2=373874&view=diff
==
--- cfe/trunk/test/SemaCXX/constexpr-builtin-bit-cast.cpp (original)
+++ cfe/trunk/test/SemaCXX/constexpr-builtin-bit-cast.cpp Sun Oct  6 19:45:12 
2019
@@ -381,3 +381,19 @@ constexpr bool test_pad_buffer() {
   return x.a == z.a && x.b == z.b;
 }
 static_assert(test_pad_buffer());
+
+constexpr unsigned char identity1a = 42;
+constexpr unsigned char identity1b = __builtin_bit_cast(unsigned char, 
identity1a);
+static_assert(identity1b == 42);
+
+struct IdentityInStruct {
+  unsigned char n;
+};
+constexpr IdentityInStruct identity2a = {42};
+constexpr unsigned char identity2b = __builtin_bit_cast(unsigned char, 
identity2a.n);
+
+union IdentityInUnion {
+  unsigned char n;
+};
+constexpr IdentityInUnion identity3a = {42};
+constexpr unsigned char identity3b = __builtin_bit_cast(unsigned char, 
identity3a.n);


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r373875 - [c++20] Check for a class-specific operator delete when deleting an

2019-10-06 Thread Richard Smith via cfe-commits 
Author: rsmith
Date: Sun Oct  6 20:14:28 2019
New Revision: 373875

URL: http://llvm.org/viewvc/llvm-project?rev=373875&view=rev
Log:
[c++20] Check for a class-specific operator delete when deleting an
object of class type with a virtual destructor.

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/SemaCXX/constant-expression-cxx2a.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=373875&r1=373874&r2=373875&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Sun Oct  6 20:14:28 2019
@@ -6019,6 +6019,13 @@ static bool hasVirtualDestructor(QualTyp
   return false;
 }
 
+static const FunctionDecl *getVirtualOperatorDelete(QualType T) {
+  if (CXXRecordDecl *RD = T->getAsCXXRecordDecl())
+if (CXXDestructorDecl *DD = RD->getDestructor())
+  return DD->isVirtual() ? DD->getOperatorDelete() : nullptr;
+  return nullptr;
+}
+
 /// Check that the given object is a suitable pointer to a heap allocation that
 /// still exists and is of the right kind for the purpose of a deletion.
 ///
@@ -13208,6 +13215,18 @@ bool VoidExprEvaluator::VisitCXXDeleteEx
 return false;
   }
 
+  // For a class type with a virtual destructor, the selected operator delete
+  // is the one looked up when building the destructor.
+  if (!E->isArrayForm() && !E->isGlobalDelete()) {
+const FunctionDecl *VirtualDelete = getVirtualOperatorDelete(AllocType);
+if (VirtualDelete &&
+!VirtualDelete->isReplaceableGlobalAllocationFunction()) {
+  Info.FFDiag(E, diag::note_constexpr_new_non_replaceable)
+  << isa(VirtualDelete) << VirtualDelete;
+  return false;
+}
+  }
+
   if (!HandleDestruction(Info, E->getExprLoc(), Pointer.getLValueBase(),
  (*Alloc)->Value, AllocType))
 return false;

Modified: cfe/trunk/test/SemaCXX/constant-expression-cxx2a.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/constant-expression-cxx2a.cpp?rev=373875&r1=373874&r2=373875&view=diff
==
--- cfe/trunk/test/SemaCXX/constant-expression-cxx2a.cpp (original)
+++ cfe/trunk/test/SemaCXX/constant-expression-cxx2a.cpp Sun Oct  6 20:14:28 
2019
@@ -1190,6 +1190,25 @@ namespace dtor_call {
   static_assert(virt_dtor(3, "YX"));
   static_assert(virt_dtor(4, "X"));
 
+  constexpr bool virt_delete(bool global) {
+struct A {
+  virtual constexpr ~A() {}
+};
+struct B : A {
+  void operator delete(void *);
+  constexpr ~B() {}
+};
+
+A *p = new B;
+if (global)
+  ::delete p;
+else
+  delete p; // expected-note {{call to class-specific 'operator delete'}}
+return true;
+  }
+  static_assert(virt_delete(true));
+  static_assert(virt_delete(false)); // expected-error {{}} expected-note {{in 
call}}
+
   constexpr void use_after_virt_destroy() {
 char buff[4] = {};
 VU vu;


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits