Re: r338301 - Avoid returning an invalid end source loc

[David Blaikie via cfe-commits]

test case?

On Mon, Jul 30, 2018 at 1:39 PM Stephen Kelly via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: steveire
> Date: Mon Jul 30 13:39:14 2018
> New Revision: 338301
>
> URL: http://llvm.org/viewvc/llvm-project?rev=338301&view=rev
> Log:
> Avoid returning an invalid end source loc
>
> Modified:
> cfe/trunk/include/clang/AST/DeclarationName.h
> cfe/trunk/lib/AST/DeclarationName.cpp
>
> Modified: cfe/trunk/include/clang/AST/DeclarationName.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclarationName.h?rev=338301&r1=338300&r2=338301&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/DeclarationName.h (original)
> +++ cfe/trunk/include/clang/AST/DeclarationName.h Mon Jul 30 13:39:14 2018
> @@ -558,7 +558,7 @@ public:
>SourceLocation getBeginLoc() const { return NameLoc; }
>
>/// getEndLoc - Retrieve the location of the last token.
> -  SourceLocation getEndLoc() const;
> +  SourceLocation getEndLoc() const { return getLocEnd(); }
>
>/// getSourceRange - The range of the declaration name.
>SourceRange getSourceRange() const LLVM_READONLY {
> @@ -570,9 +570,11 @@ public:
>}
>
>SourceLocation getLocEnd() const LLVM_READONLY {
> -SourceLocation EndLoc = getEndLoc();
> +SourceLocation EndLoc = getEndLocPrivate();
>  return EndLoc.isValid() ? EndLoc : getLocStart();
>}
> +private:
> +  SourceLocation getEndLocPrivate() const;
>  };
>
>  /// Insertion operator for diagnostics.  This allows sending
> DeclarationName's
>
> Modified: cfe/trunk/lib/AST/DeclarationName.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclarationName.cpp?rev=338301&r1=338300&r2=338301&view=diff
>
> ==
> --- cfe/trunk/lib/AST/DeclarationName.cpp (original)
> +++ cfe/trunk/lib/AST/DeclarationName.cpp Mon Jul 30 13:39:14 2018
> @@ -689,7 +689,7 @@ void DeclarationNameInfo::printName(raw_
>llvm_unreachable("Unexpected declaration name kind");
>  }
>
> -SourceLocation DeclarationNameInfo::getEndLoc() const {
> +SourceLocation DeclarationNameInfo::getEndLocPrivate() const {
>switch (Name.getNameKind()) {
>case DeclarationName::Identifier:
>case DeclarationName::CXXDeductionGuideName:
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

[David Blaikie via cfe-commits]

What's the motivation for clangd to differ from clang here? (& if the first
letter is going to be capitalized, should there be a period at the end? But
also the phrasing of most/all diagnostic text isn't in the form of complete
sentences, so this might not make sense)

On Fri, Aug 3, 2018 at 1:44 PM Alex Lorenz via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rCTE338919: [clangd] capitalize diagnostic messages
> (authored by arphaman, committed by ).
>
> Changed prior to commit:
>   https://reviews.llvm.org/D50154?vs=159059&id=159080#toc
>
> Repository:
>   rCTE Clang Tools Extra
>
> https://reviews.llvm.org/D50154
>
> Files:
>   clangd/Diagnostics.cpp
>   test/clangd/diagnostics.test
>   test/clangd/did-change-configuration-params.test
>   test/clangd/execute-command.test
>   test/clangd/extra-flags.test
>   test/clangd/fixits.test
>   unittests/clangd/ClangdUnitTests.cpp
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r338467 - Avoid exposing name for range-based for '__range' variables in lifetime warnings.

[David Blaikie via cfe-commits]

Reckon there's a chance of improved diagnostic text in cases like this?
Will users understand what the problem is/how to fix it when they read
"temporary
implicitly bound to local reference will be destroyed at the end of the
full-expression" - feels very standard-ese-y to me? & I appreciate teh
desire/need for precision, I wonder if there's better ways to communicate
it to the user... :/

On Tue, Jul 31, 2018 at 6:03 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Jul 31 18:03:33 2018
> New Revision: 338467
>
> URL: http://llvm.org/viewvc/llvm-project?rev=338467&view=rev
> Log:
> Avoid exposing name for range-based for '__range' variables in lifetime
> warnings.
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/test/SemaCXX/attr-lifetimebound.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=338467&r1=338466&r2=338467&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Jul 31
> 18:03:33 2018
> @@ -7875,7 +7875,8 @@ def warn_ret_addr_label : Warning<
>  def err_ret_local_block : Error<
>"returning block that lives on the local stack">;
>  def note_local_var_initializer : Note<
> -  "%select{via initialization of|binding reference}0 variable %1 here">;
> +  "%select{via initialization of|binding reference}0 variable "
> +  "%select{%2 |}1here">;
>  def note_init_with_default_member_initalizer : Note<
>"initializing field %0 with default member initializer">;
>
> @@ -7907,13 +7908,14 @@ def note_lifetime_extending_member_decla
>"member with %select{reference|'std::initializer_list'}0 subobject}1 "
>"declared here">;
>  def warn_dangling_variable : Warning<
> -  "%select{temporary %select{whose address is used as value of|bound to}3
> "
> -  "%select{%select{|reference }3member of local variable|"
> -  "local %select{variable|reference}3}1|"
> +  "%select{temporary %select{whose address is used as value of|"
> +  "%select{|implicitly }2bound to}4 "
> +  "%select{%select{|reference }4member of local variable|"
> +  "local %select{variable|reference}4}1|"
>"array backing "
>"%select{initializer list subobject of local variable|"
>"local initializer list}1}0 "
> -  "%2 will be destroyed at the end of the full-expression">,
> +  "%select{%3 |}2will be destroyed at the end of the full-expression">,
>InGroup;
>  def warn_new_dangling_reference : Warning<
>"temporary bound to reference member of allocated object "
>
> Modified: cfe/trunk/lib/Sema/SemaInit.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=338467&r1=338466&r2=338467&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaInit.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaInit.cpp Tue Jul 31 18:03:33 2018
> @@ -6847,8 +6847,9 @@ void Sema::checkInitializerLifetime(cons
>return false;
>
>  Diag(DiagLoc, diag::warn_dangling_variable)
> -<< RK << !Entity.getParent() << ExtendingEntity->getDecl()
> -<< Init->isGLValue() << DiagRange;
> +<< RK << !Entity.getParent()
> +<< ExtendingEntity->getDecl()->isImplicit()
> +<< ExtendingEntity->getDecl() << Init->isGLValue() <<
> DiagRange;
>}
>break;
>  }
> @@ -6969,7 +6970,8 @@ void Sema::checkInitializerLifetime(cons
>case IndirectLocalPathEntry::VarInit:
>  const VarDecl *VD = cast(Elem.D);
>  Diag(VD->getLocation(), diag::note_local_var_initializer)
> -<< VD->getType()->isReferenceType() << VD->getDeclName()
> +<< VD->getType()->isReferenceType()
> +<< VD->isImplicit() << VD->getDeclName()
>  << nextPathEntryRange(Path, I + 1, L);
>  break;
>}
>
> Modified: cfe/trunk/test/SemaCXX/attr-lifetimebound.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/attr-lifetimebound.cpp?rev=338467&r1=338466&r2=338467&view=diff
>
> ==
> --- cfe/trunk/test/SemaCXX/attr-lifetimebound.cpp (original)
> +++ cfe/trunk/test/SemaCXX/attr-lifetimebound.cpp Tue Jul 31 18:03:33 2018
> @@ -101,7 +101,7 @@ namespace p0936r0_examples {
>std::vector make_vector();
>void use_reversed_range() {
>  // FIXME: Don't expose the name of the internal range variable.
> -for (auto x : reversed(make_vector())) {} // expected-warning
> {{temporary bound to local reference '__range1'}}
> +for (auto x : reversed(make_vector())) {} // expected-warning
> {{temporary implicitly bound to local reference will be 

Re: r338732 - [analyzer] Make RegionVector use const reference

[David Blaikie via cfe-commits]

Looks good! Though it may be useful in the future to describe, in the
commit message, the motivation for a change - how'd you find this? What
motivated you to make this particular fix just now, etc? ("identified using
clang-tidy" or "spotted during post-commit review of change r", etc...)

On Thu, Aug 2, 2018 at 9:29 AM Fangrui Song via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: maskray
> Date: Thu Aug  2 09:29:36 2018
> New Revision: 338732
>
> URL: http://llvm.org/viewvc/llvm-project?rev=338732&view=rev
> Log:
> [analyzer] Make RegionVector use const reference
>
> Modified:
> cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp?rev=338732&r1=338731&r2=338732&view=diff
>
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp (original)
> +++ cfe/trunk/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp Thu Aug  2
> 09:29:36 2018
> @@ -395,7 +395,7 @@ private:
>const Optional
>findRegionOfInterestInRecord(const RecordDecl *RD, ProgramStateRef
> State,
> const MemRegion *R,
> -   RegionVector Vec = {},
> +   const RegionVector &Vec = {},
> int depth = 0) {
>
>  if (depth == DEREFERENCE_LIMIT) // Limit the recursion depth.
> @@ -548,14 +548,10 @@ private:
>
>/// \return Diagnostics piece for region not modified in the current
> function.
>std::shared_ptr
> -  notModifiedDiagnostics(const LocationContext *Ctx,
> - CallExitBegin &CallExitLoc,
> - CallEventRef<> Call,
> - RegionVector FieldChain,
> - const MemRegion *MatchedRegion,
> - StringRef FirstElement,
> - bool FirstIsReferenceType,
> - unsigned IndirectionLevel) {
> +  notModifiedDiagnostics(const LocationContext *Ctx, CallExitBegin
> &CallExitLoc,
> + CallEventRef<> Call, const RegionVector
> &FieldChain,
> + const MemRegion *MatchedRegion, StringRef
> FirstElement,
> + bool FirstIsReferenceType, unsigned
> IndirectionLevel) {
>
>  PathDiagnosticLocation L;
>  if (const ReturnStmt *RS = CallExitLoc.getReturnStmt()) {
> @@ -579,7 +575,8 @@ private:
>/// Pretty-print region \p MatchedRegion to \p os.
>void prettyPrintRegionName(StringRef FirstElement, bool
> FirstIsReferenceType,
>   const MemRegion *MatchedRegion,
> - RegionVector FieldChain, int
> IndirectionLevel,
> + const RegionVector &FieldChain,
> + int IndirectionLevel,
>   llvm::raw_svector_ostream &os) {
>
>  if (FirstIsReferenceType)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

[David Blaikie via cfe-commits]

On Tue, Aug 7, 2018 at 10:33 AM Alex Lorenz via Phabricator <
revi...@reviews.llvm.org> wrote:

> arphaman added a comment.
>
> In https://reviews.llvm.org/D50154#1191002, @dblaikie wrote:
>
> > What's the motivation for clangd to differ from clang here? (& if the
> first
> >  letter is going to be capitalized, should there be a period at the end?
> But
> >  also the phrasing of most/all diagnostic text isn't in the form of
> complete
> >  sentences, so this might not make sense)
>
>
> It's mostly for the presentation purposes, to match the needs of our
> client. I first implemented it as an opt-in feature, but the consensus was
> to capitalize the messages all the time.
>

Doesn't seem like it'd be any more expensive (amount of code or
performance) to do that up in your client code, then, would it? I guess if
most users of this API in time ended up preferring capitalized values, it'd
make sense to share that implementation - but to me it seems like a strange
transformation to happen at this level. (since it depends on what kind of
client/how they want to render things - so it seems an odd choice to bake
in to the API (or even provide an option for, unless there are lots of
users/the code was especially complicated))

My 2c - I've no vested interest or authority here.


> I don't think it would make sense to insert the period at the end,
> because, as you said, not all diagnostics are complete sentences
>
>
> Repository:
>   rCTE Clang Tools Extra
>
> https://reviews.llvm.org/D50154
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

[David Blaikie via cfe-commits]

On Tue, Aug 7, 2018 at 11:22 AM Alex L  wrote:

> On Tue, 7 Aug 2018 at 10:52, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Aug 7, 2018 at 10:33 AM Alex Lorenz via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> arphaman added a comment.
>>>
>>> In https://reviews.llvm.org/D50154#1191002, @dblaikie wrote:
>>>
>>> > What's the motivation for clangd to differ from clang here? (& if the
>>> first
>>> >  letter is going to be capitalized, should there be a period at the
>>> end? But
>>> >  also the phrasing of most/all diagnostic text isn't in the form of
>>> complete
>>> >  sentences, so this might not make sense)
>>>
>>>
>>> It's mostly for the presentation purposes, to match the needs of our
>>> client. I first implemented it as an opt-in feature, but the consensus was
>>> to capitalize the messages all the time.
>>>
>>
>> Doesn't seem like it'd be any more expensive (amount of code or
>> performance) to do that up in your client code, then, would it? I guess if
>> most users of this API in time ended up preferring capitalized values, it'd
>> make sense to share that implementation - but to me it seems like a strange
>> transformation to happen at this level. (since it depends on what kind of
>> client/how they want to render things - so it seems an odd choice to bake
>> in to the API (or even provide an option for, unless there are lots of
>> users/the code was especially complicated))
>>
>> My 2c - I've no vested interest or authority here.
>>
>
> I think it's more in spirit with Clangd to provide output that's as close
> to the one presented by the client as possible.
>

That assumes there's one client though, right? Different clients might
reasonably have different needs for how they'd want the text rendered, I'd
imagine.


> I would argue there's already a precedence for this kind of
> transformations, for example, Clangd merges the diagnostic messages of
> notes and the main diagnostics into one, to make it a better presentation
> experience in the client:
>
>
> https://github.com/llvm-mirror/clang-tools-extra/blob/55bfabcc1bd75447d6338ffe6ff27c1624a8c15a/clangd/Diagnostics.cpp#L161
>

I'm assuming that's because the API/protocol only supports a single
message, so the multi-message/location nuance of LLVM's diagnostics are
necessarily lost when converting to that format?

If that's not the case, and the API/protocol does support a
multiple-message diagnostic & ClangD is collapsing them early - that also
seems like an unfortunate loss in fidelity.


>
>
>
>
>
>>
>>
>>> I don't think it would make sense to insert the period at the end,
>>> because, as you said, not all diagnostics are complete sentences
>>>
>>>
>>> Repository:
>>>   rCTE Clang Tools Extra
>>>
>>> https://reviews.llvm.org/D50154
>>>
>>>
>>>
>>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r338301 - Avoid returning an invalid end source loc

[David Blaikie via cfe-commits]

If it never comes up, maybe an assertion would suffice? (& if the assertion
ever does fire - hey, we've found a test case to use)

How'd you find this/what motivated you to make the change?

On Tue, Aug 7, 2018 at 3:11 PM Stephen Kelly  wrote:

>
> Hi David,
>
> I'm happy to add a test case, but I don't know how to catch this case.
> It's not obvious to me if any code path intentionally creates a
> DeclarationNameInfo with a valid start loc and an invalid end loc. Can you
> suggest a test case?
>
> Thanks,
>
> Stephen.
>
>
> On 07/08/18 03:23, David Blaikie wrote:
>
> test case?
>
> On Mon, Jul 30, 2018 at 1:39 PM Stephen Kelly via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: steveire
>> Date: Mon Jul 30 13:39:14 2018
>> New Revision: 338301
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=338301&view=rev
>> Log:
>> Avoid returning an invalid end source loc
>>
>> Modified:
>> cfe/trunk/include/clang/AST/DeclarationName.h
>> cfe/trunk/lib/AST/DeclarationName.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/DeclarationName.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclarationName.h?rev=338301&r1=338300&r2=338301&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/DeclarationName.h (original)
>> +++ cfe/trunk/include/clang/AST/DeclarationName.h Mon Jul 30 13:39:14 2018
>> @@ -558,7 +558,7 @@ public:
>>SourceLocation getBeginLoc() const { return NameLoc; }
>>
>>/// getEndLoc - Retrieve the location of the last token.
>> -  SourceLocation getEndLoc() const;
>> +  SourceLocation getEndLoc() const { return getLocEnd(); }
>>
>>/// getSourceRange - The range of the declaration name.
>>SourceRange getSourceRange() const LLVM_READONLY {
>> @@ -570,9 +570,11 @@ public:
>>}
>>
>>SourceLocation getLocEnd() const LLVM_READONLY {
>> -SourceLocation EndLoc = getEndLoc();
>> +SourceLocation EndLoc = getEndLocPrivate();
>>  return EndLoc.isValid() ? EndLoc : getLocStart();
>>}
>> +private:
>> +  SourceLocation getEndLocPrivate() const;
>>  };
>>
>>  /// Insertion operator for diagnostics.  This allows sending
>> DeclarationName's
>>
>> Modified: cfe/trunk/lib/AST/DeclarationName.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclarationName.cpp?rev=338301&r1=338300&r2=338301&view=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/DeclarationName.cpp (original)
>> +++ cfe/trunk/lib/AST/DeclarationName.cpp Mon Jul 30 13:39:14 2018
>> @@ -689,7 +689,7 @@ void DeclarationNameInfo::printName(raw_
>>llvm_unreachable("Unexpected declaration name kind");
>>  }
>>
>> -SourceLocation DeclarationNameInfo::getEndLoc() const {
>> +SourceLocation DeclarationNameInfo::getEndLocPrivate() const {
>>switch (Name.getNameKind()) {
>>case DeclarationName::Identifier:
>>case DeclarationName::CXXDeductionGuideName:
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r338301 - Avoid returning an invalid end source loc

[David Blaikie via cfe-commits]

*nod* Maybe consistency's enough for now. But yeah, if you can test whether
the assertion fires (though for invalid locs, that usually means invalid
code - and we don't have nice big repositories of weird invalid code - just
the clang regression tests).



On Tue, Aug 7, 2018 at 3:27 PM Stephen Kelly  wrote:

>
> Ok, I can look into adding the assertion and run the tests with it to see
> if anything comes up.
>
> I made a tool which dumps SourceLocations reachable from an AST node (I
> intend to integrate it into clang-query), and I noticed the large amount of
> mixing of get{Start,End}Loc and getLoc{Start,End} (see other pending
> reviews). I reviewed all of them and found that this method is the only
> case where a pair of methods of that name pattern differ in what they
> return (by eye, at least), so I thought it should be fixed.
>
> Thanks,
>
> Stephen.
>
>
> On 07/08/18 23:18, David Blaikie wrote:
>
> If it never comes up, maybe an assertion would suffice? (& if the
> assertion ever does fire - hey, we've found a test case to use)
>
> How'd you find this/what motivated you to make the change?
>
> On Tue, Aug 7, 2018 at 3:11 PM Stephen Kelly  wrote:
>
>>
>> Hi David,
>>
>> I'm happy to add a test case, but I don't know how to catch this case.
>> It's not obvious to me if any code path intentionally creates a
>> DeclarationNameInfo with a valid start loc and an invalid end loc. Can you
>> suggest a test case?
>>
>> Thanks,
>>
>> Stephen.
>>
>>
>> On 07/08/18 03:23, David Blaikie wrote:
>>
>> test case?
>>
>> On Mon, Jul 30, 2018 at 1:39 PM Stephen Kelly via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: steveire
>>> Date: Mon Jul 30 13:39:14 2018
>>> New Revision: 338301
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=338301&view=rev
>>> Log:
>>> Avoid returning an invalid end source loc
>>>
>>> Modified:
>>> cfe/trunk/include/clang/AST/DeclarationName.h
>>> cfe/trunk/lib/AST/DeclarationName.cpp
>>>
>>> Modified: cfe/trunk/include/clang/AST/DeclarationName.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclarationName.h?rev=338301&r1=338300&r2=338301&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/AST/DeclarationName.h (original)
>>> +++ cfe/trunk/include/clang/AST/DeclarationName.h Mon Jul 30 13:39:14
>>> 2018
>>> @@ -558,7 +558,7 @@ public:
>>>SourceLocation getBeginLoc() const { return NameLoc; }
>>>
>>>/// getEndLoc - Retrieve the location of the last token.
>>> -  SourceLocation getEndLoc() const;
>>> +  SourceLocation getEndLoc() const { return getLocEnd(); }
>>>
>>>/// getSourceRange - The range of the declaration name.
>>>SourceRange getSourceRange() const LLVM_READONLY {
>>> @@ -570,9 +570,11 @@ public:
>>>}
>>>
>>>SourceLocation getLocEnd() const LLVM_READONLY {
>>> -SourceLocation EndLoc = getEndLoc();
>>> +SourceLocation EndLoc = getEndLocPrivate();
>>>  return EndLoc.isValid() ? EndLoc : getLocStart();
>>>}
>>> +private:
>>> +  SourceLocation getEndLocPrivate() const;
>>>  };
>>>
>>>  /// Insertion operator for diagnostics.  This allows sending
>>> DeclarationName's
>>>
>>> Modified: cfe/trunk/lib/AST/DeclarationName.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclarationName.cpp?rev=338301&r1=338300&r2=338301&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/AST/DeclarationName.cpp (original)
>>> +++ cfe/trunk/lib/AST/DeclarationName.cpp Mon Jul 30 13:39:14 2018
>>> @@ -689,7 +689,7 @@ void DeclarationNameInfo::printName(raw_
>>>llvm_unreachable("Unexpected declaration name kind");
>>>  }
>>>
>>> -SourceLocation DeclarationNameInfo::getEndLoc() const {
>>> +SourceLocation DeclarationNameInfo::getEndLocPrivate() const {
>>>switch (Name.getNameKind()) {
>>>case DeclarationName::Identifier:
>>>case DeclarationName::CXXDeductionGuideName:
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

[David Blaikie via cfe-commits]

On Tue, Aug 7, 2018 at 4:02 PM Alex L  wrote:

> On Tue, 7 Aug 2018 at 11:38, David Blaikie  wrote:
>
>>
>>
>> On Tue, Aug 7, 2018 at 11:22 AM Alex L  wrote:
>>
>>> On Tue, 7 Aug 2018 at 10:52, David Blaikie via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Aug 7, 2018 at 10:33 AM Alex Lorenz via Phabricator <
>>>> revi...@reviews.llvm.org> wrote:
>>>>
>>>>> arphaman added a comment.
>>>>>
>>>>> In https://reviews.llvm.org/D50154#1191002, @dblaikie wrote:
>>>>>
>>>>> > What's the motivation for clangd to differ from clang here? (& if
>>>>> the first
>>>>> >  letter is going to be capitalized, should there be a period at the
>>>>> end? But
>>>>> >  also the phrasing of most/all diagnostic text isn't in the form of
>>>>> complete
>>>>> >  sentences, so this might not make sense)
>>>>>
>>>>>
>>>>> It's mostly for the presentation purposes, to match the needs of our
>>>>> client. I first implemented it as an opt-in feature, but the consensus was
>>>>> to capitalize the messages all the time.
>>>>>
>>>>
>>>> Doesn't seem like it'd be any more expensive (amount of code or
>>>> performance) to do that up in your client code, then, would it? I guess if
>>>> most users of this API in time ended up preferring capitalized values, it'd
>>>> make sense to share that implementation - but to me it seems like a strange
>>>> transformation to happen at this level. (since it depends on what kind of
>>>> client/how they want to render things - so it seems an odd choice to bake
>>>> in to the API (or even provide an option for, unless there are lots of
>>>> users/the code was especially complicated))
>>>>
>>>> My 2c - I've no vested interest or authority here.
>>>>
>>>
>>> I think it's more in spirit with Clangd to provide output that's as
>>> close to the one presented by the client as possible.
>>>
>>
>> That assumes there's one client though, right? Different clients might
>> reasonably have different needs for how they'd want the text rendered, I'd
>> imagine.
>>
>
> True. This transformation is lossless though, so the clients will still be
> able to get back the original text if needed.
>

I'm not sure that c == lower(upper(c)) - well, if the character is ever
uppercase to begin with, it's clearly not. But even in the case of a
lowercase character to start with I didn't think that was always true - I
guess for ASCII/English it is, and that's all we're dealing with here.


> And if the consensus about this particular text transformation changes I'm
> willing to revert this change for sure.
>

*nod* I mean if everyone who's invested in/working on clangd agrees with
your direction, that's cool/good. My 2c is that this sort of thing seems
like the responsibility of the client, not the API - but that's by no means
authoritative.


> I would argue there's already a precedence for this kind of
>>> transformations, for example, Clangd merges the diagnostic messages of
>>> notes and the main diagnostics into one, to make it a better presentation
>>> experience in the client:
>>>
>>>
>>> https://github.com/llvm-mirror/clang-tools-extra/blob/55bfabcc1bd75447d6338ffe6ff27c1624a8c15a/clangd/Diagnostics.cpp#L161
>>>
>>
>> I'm assuming that's because the API/protocol only supports a single
>> message, so the multi-message/location nuance of LLVM's diagnostics are
>> necessarily lost when converting to that format?
>>
>> If that's not the case, and the API/protocol does support a
>> multiple-message diagnostic & ClangD is collapsing them early - that also
>> seems like an unfortunate loss in fidelity.
>>
>
> Clangd sends out both the main diagnostic, and the attached notes (that
> don't have fixits) in a list (i.e. the hierarchy isn't directly preserved,
> although it can be recreated by the client).
> So it looks like they're collapsed early, but at the same time the client
> has enough information to do this transformation itself if desired.
> I'm planning to work on an option to remove this behavior if desired by
> the client.
>

*nod* I'd (completely in the abstract -

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

[David Blaikie via cfe-commits]

On Wed, Aug 8, 2018 at 5:00 AM Ilya Biryukov via Phabricator <
revi...@reviews.llvm.org> wrote:

> ilya-biryukov added a comment.
>
> In https://reviews.llvm.org/D50154#1191002, @dblaikie wrote:
>
> > What's the motivation for clangd to differ from clang here?
>
>
> The presentation of diagnostics to the users is different between clang
> and clangd:
>
> - clang diagnostics are always prefixed with the file, location and
> severity of the diagnostic, e.g. `main.cpp:1:2: error: expected '}'`
>

*nod* That's a fairly natural one - and I assume the information is
provided semantically - source, line, column, and text. A client can stitch
them together as clang does or it can render the information some other way
(by placing the text as a mouseover/popup at the source location). I don't
see that as a divergence - but providing the full fidelity of the
information (rather than prematurely stringifying it all together) &
leaving it up to the client to decide how to render it to the user.


> - In LSP clients (VSCode in particular), the diagnostic message is the
> first thing the user sees and it looks a little nicer (subjectively) if the
> first letter is capitalized.
>

It looks nicer in VSCode because that's the UI convention for mouseover
text (in Windows, at least) - first letter capitalized. But it seems hard
to me to generalize from there to all or most LSP clients. (& I also worry
that such a mechanical transformation might be erroneous in some messages)

(well, there's at least one case where reversing this would fail - there's
a diagnostic in Clang that starts with "ISO" - so uppercasing does nothing,
but lowercasing it to try to get back to the original would result in "iSO"
- several others like "Objective-C", "Neon", "GCC", etc)

(also, there's one that this will mangle: "ms_struct may not produce
Microsoft-compatible layouts" - I assume capitalizing "ms_struct" would be
incorrect (though arguably/mostly identifiers like that are quoted in error
messages - and that may be reasonable/correct/better to do that here).
Similar use of 'sizeof' at the start of a diagnostic, 'os_log()', -
those'll be an issue no matter where the implementation is (in clangd or
its client(s)) though - short of having a more customized thing in the
diagnostics table itself to record which things can be capitalized/how they
should be capitalized - but, yeah, arguably quoting might be the right
thing in many, maybe all, of those cases)




>
> See the screenshots from VSCode on how diagnostics are presented:
> F6901986: image.png  F6901990:
> image.png 
>
>
> Repository:
>   rCTE Clang Tools Extra
>
> https://reviews.llvm.org/D50154
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r339941 - Update for LLVM API change

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Aug 16 14:30:24 2018
New Revision: 339941

URL: http://llvm.org/viewvc/llvm-project?rev=339941&view=rev
Log:
Update for LLVM API change

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=339941&r1=339940&r2=339941&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Aug 16 14:30:24 2018
@@ -579,7 +579,8 @@ void CGDebugInfo::CreateCompileUnit() {
   CGOpts.DwarfDebugFlags, RuntimeVers,
   CGOpts.EnableSplitDwarf ? "" : CGOpts.SplitDwarfFile, EmissionKind,
   0 /* DWOid */, CGOpts.SplitDwarfInlining, CGOpts.DebugInfoForProfiling,
-  CGOpts.GnuPubnames);
+  CGOpts.GnuPubnames ? llvm::DICompileUnit::DebugNameTableKind::GNU
+ : llvm::DICompileUnit::DebugNameTableKind::Default);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) {


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

r339968 - Disable pubnames in NVPTX debug info using metadata

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Aug 16 16:56:32 2018
New Revision: 339968

URL: http://llvm.org/viewvc/llvm-project?rev=339968&view=rev
Log:
Disable pubnames in NVPTX debug info using metadata

Added:
cfe/trunk/test/CodeGen/debug-nvptx.c
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=339968&r1=339967&r2=339968&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Aug 16 16:56:32 2018
@@ -579,8 +579,11 @@ void CGDebugInfo::CreateCompileUnit() {
   CGOpts.DwarfDebugFlags, RuntimeVers,
   CGOpts.EnableSplitDwarf ? "" : CGOpts.SplitDwarfFile, EmissionKind,
   0 /* DWOid */, CGOpts.SplitDwarfInlining, CGOpts.DebugInfoForProfiling,
-  CGOpts.GnuPubnames ? llvm::DICompileUnit::DebugNameTableKind::GNU
- : llvm::DICompileUnit::DebugNameTableKind::Default);
+  CGM.getTarget().getTriple().isNVPTX()
+  ? llvm::DICompileUnit::DebugNameTableKind::None
+  : CGOpts.GnuPubnames
+? llvm::DICompileUnit::DebugNameTableKind::GNU
+: llvm::DICompileUnit::DebugNameTableKind::Default);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) {

Added: cfe/trunk/test/CodeGen/debug-nvptx.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-nvptx.c?rev=339968&view=auto
==
--- cfe/trunk/test/CodeGen/debug-nvptx.c (added)
+++ cfe/trunk/test/CodeGen/debug-nvptx.c Thu Aug 16 16:56:32 2018
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple nvptx-unknown-unknown -S -o - 
-debug-info-kind=limited %s -emit-llvm | FileCheck %s
+
+// CHECK: DICompileUnit({{.*}}, nameTableKind: None)
+
+void f1(void) {
+}


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

r340206 - DebugInfo: Add the ability to disable DWARF name tables entirely

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Mon Aug 20 13:14:08 2018
New Revision: 340206

URL: http://llvm.org/viewvc/llvm-project?rev=340206&view=rev
Log:
DebugInfo: Add the ability to disable DWARF name tables entirely

This changes the current default behavior (from emitting pubnames by
default, to not emitting them by default) & moves to matching GCC's
behavior* with one significant difference: -gno(-gnu)-pubnames disables
pubnames even in the presence of -gsplit-dwarf (though -gsplit-dwarf
still by default enables -ggnu-pubnames). This allows users to disable
pubnames (& the new DWARF5 accelerated access tables) when they might
not be worth the size overhead.

* GCC's behavior is that -ggnu-pubnames and -gpubnames override each
other, and that -gno-gnu-pubnames and -gno-pubnames act as synonyms and
disable either kind of pubnames if they come last. (eg: -gpubnames
-gno-gnu-pubnames causes no pubnames (neither gnu or standard) to be
emitted)

Added:
cfe/trunk/test/CodeGen/debug-info-names.c
Modified:
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/CodeGen/debug-info-global-constant.c
cfe/trunk/test/CodeGen/debug-info-macro.c
cfe/trunk/test/Driver/debug-options.c

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=340206&r1=340205&r2=340206&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Aug 20 13:14:08 2018
@@ -197,10 +197,6 @@ def dwarf_column_info : Flag<["-"], "dwa
   HelpText<"Turn on column location information.">;
 def split_dwarf : Flag<["-"], "split-dwarf">,
   HelpText<"Split out the dwarf .dwo sections">;
-def gnu_pubnames : Flag<["-"], "gnu-pubnames">,
-  HelpText<"Emit newer GNU style pubnames">;
-def arange_sections : Flag<["-"], "arange_sections">,
-  HelpText<"Emit DWARF .debug_arange sections">;
 def dwarf_ext_refs : Flag<["-"], "dwarf-ext-refs">,
   HelpText<"Generate debug info with external references to clang modules"
" or precompiled headers">;

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=340206&r1=340205&r2=340206&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Mon Aug 20 13:14:08 2018
@@ -1807,6 +1807,8 @@ def gno_column_info : Flag<["-"], "gno-c
 def gsplit_dwarf : Flag<["-"], "gsplit-dwarf">, Group;
 def ggnu_pubnames : Flag<["-"], "ggnu-pubnames">, Group, 
Flags<[CC1Option]>;
 def gno_gnu_pubnames : Flag<["-"], "gno-gnu-pubnames">, Group, 
Flags<[CC1Option]>;
+def gpubnames : Flag<["-"], "gpubnames">, Group, 
Flags<[CC1Option]>;
+def gno_pubnames : Flag<["-"], "gno-pubnames">, Group, 
Flags<[CC1Option]>;
 def gdwarf_aranges : Flag<["-"], "gdwarf-aranges">, Group;
 def gmodules : Flag <["-"], "gmodules">, Group,
   HelpText<"Generate debug info with external references to clang modules"

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=340206&r1=340205&r2=340206&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Mon Aug 20 13:14:08 2018
@@ -326,7 +326,7 @@ CODEGENOPT(DebugInfoForProfiling, 1, 0)
 CODEGENOPT(PreserveVec3Type, 1, 0)
 
 /// Whether to emit .debug_gnu_pubnames section instead of .debug_pubnames.
-CODEGENOPT(GnuPubnames, 1, 0)
+CODEGENOPT(DebugNameTable, 2, 0)
 
 CODEGENOPT(NoPLT, 1, 0)
 

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=340206&r1=340205&r2=340206&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Aug 20 13:14:08 2018
@@ -581,9 +581,8 @@ void CGDebugInfo::CreateCompileUnit() {
   0 /* DWOid */, CGOpts.SplitDwarfInlining, CGOpts.DebugInfoForProfiling,
   CGM.getTarget().getTriple().isNVPTX()
   ? llvm::DICompileUnit::DebugNameTableKind::None
-  : CGOpts.GnuPubnames
-? llvm::DICompileUnit::DebugNameTableKind::GNU
-: llvm::DICompileUnit::DebugNameTableKind::Default);
+  : static_cast(
+CGOpts.DebugNameTable));
 }
 
 llvm::DIType *CGDebugInfo::CreateType

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[David Blaikie via cfe-commits]

I haven't looked in detail here, but in general: Don't split an
implementation and its headers into different notional libraries, as that
breaks modular code generation (an implementation and its headers usually
have circular dependencies - inline functions that call non-inline
functions, and the other way around & so if they're in two different
libraries they won't be able to link (due to the way unix linkers
work/dependencies are resolved in a single pass, never looping back around).

On Fri, May 18, 2018 at 1:10 PM Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Fri, May 18, 2018 at 12:46 PM Bruno Cardoso Lopes <
> bruno.card...@gmail.com> wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 11:54 AM Vedant Kumar via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On May 18, 2018, at 11:48 AM, Eric Liu  wrote:
>>>
>>>
>>> So I have reverted this with r332751.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> I can't see how this introduced cyclic dependencies in module build, as
>>> the dependencies should be clangTooling -> clangFormat ->
>>> clangToolingInclusions. I'm wondering if there is any module configurations
>>> that I need to update to make this work. Right now, module doesn't seem to
>>> make any difference between clangTooling and clangToolingInclusions...
>>> I'd appreciate it if someone who knows how clang module build is set up
>>> could help take a look.
>>>
>>>
>>> + Bruno & David who have more experience in this area than I do.
>>>
>>
>> Gonna try to reproduce and take a look!
>>
>
> I could reproduce it. You should be good to go if you add another top
> level module for Inclusions (and break the dep):
>
> --- a/include/clang/module.modulemap
> +++ b/include/clang/module.modulemap
> @@ -153,3 +153,8 @@ module Clang_ToolingCore {
>requires cplusplus
>umbrella "Tooling/Core" module * { export * }
>  }
> +
> +module Clang_ToolingInclusions {
> +  requires cplusplus
> +  umbrella "Tooling/Inclusions" module * { export * }
> +}
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[David Blaikie via cfe-commits]

On Fri, May 18, 2018 at 2:22 PM Eric Liu  wrote:

> Thanks a lot for looking into this Bruno! The fix looks promising; I'll
> give it a try next week :D
>
> On Fri, May 18, 2018 at 10:33 PM David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> I haven't looked in detail here, but in general: Don't split an
>> implementation and its headers into different notional libraries, as that
>> breaks modular code generation (an implementation and its headers usually
>> have circular dependencies - inline functions that call non-inline
>> functions, and the other way around & so if they're in two different
>> libraries they won't be able to link (due to the way unix linkers
>> work/dependencies are resolved in a single pass, never looping back around).
>>
> David, I'm not exactly sure if I understand... This change pulls both
> declarations and implementations into a self-contained library which could
> be shared by clang-format and other tools that manipulate #includes. This
> seems to be a normal refactoring, and I hope this doesn't break modular
> code generation.
>

Sounds OK - so long as both header and implementation go together is all.

(by the name "Inclusions" I was worried maybe just the headers had been
pulled out, but not their implementation)


>
>> On Fri, May 18, 2018 at 1:10 PM Bruno Cardoso Lopes via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Fri, May 18, 2018 at 12:46 PM Bruno Cardoso Lopes <
>>> bruno.card...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 18, 2018 at 11:54 AM Vedant Kumar via cfe-commits <
>>>> cfe-commits@lists.llvm.org> wrote:
>>>>
>>>>> On May 18, 2018, at 11:48 AM, Eric Liu  wrote:
>>>>>
>>>>>
>>>>> So I have reverted this with r332751.
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> I can't see how this introduced cyclic dependencies in module build,
>>>>> as the dependencies should be clangTooling -> clangFormat ->
>>>>> clangToolingInclusions. I'm wondering if there is any module 
>>>>> configurations
>>>>> that I need to update to make this work. Right now, module doesn't seem to
>>>>> make any difference between clangTooling and clangToolingInclusions...
>>>>> I'd appreciate it if someone who knows how clang module build is set up
>>>>> could help take a look.
>>>>>
>>>>>
>>>>> + Bruno & David who have more experience in this area than I do.
>>>>>
>>>>
>>>> Gonna try to reproduce and take a look!
>>>>
>>>
>>> I could reproduce it. You should be good to go if you add another top
>>> level module for Inclusions (and break the dep):
>>>
>>> --- a/include/clang/module.modulemap
>>> +++ b/include/clang/module.modulemap
>>> @@ -153,3 +153,8 @@ module Clang_ToolingCore {
>>>requires cplusplus
>>>umbrella "Tooling/Core" module * { export * }
>>>  }
>>> +
>>> +module Clang_ToolingInclusions {
>>> +  requires cplusplus
>>> +  umbrella "Tooling/Inclusions" module * { export * }
>>> +}
>>>
>>> --
>>> Bruno Cardoso Lopes
>>> http://www.brunocardoso.cc
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r333141 - Use zeroinitializer for (trailing zero portion of) large array initializers

[David Blaikie via cfe-commits]

Probably nice to mention in the commit message what the fix was (& if/where
there was there a test added for it?) so readers don't have to try to
eyeball diff this commit against the otherone.

On Wed, May 23, 2018 at 4:45 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Wed May 23 16:41:38 2018
> New Revision: 333141
>
> URL: http://llvm.org/viewvc/llvm-project?rev=333141&view=rev
> Log:
> Use zeroinitializer for (trailing zero portion of) large array initializers
> more reliably.
>
> This re-commits r333044 with a fix for PR37560.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGExprConstant.cpp
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/test/CodeGen/init.c
> cfe/trunk/test/CodeGenCXX/cxx11-initializer-aggregate.cpp
> cfe/trunk/test/SemaCXX/aggregate-initialization.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGExprConstant.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprConstant.cpp?rev=333141&r1=333140&r2=333141&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGExprConstant.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExprConstant.cpp Wed May 23 16:41:38 2018
> @@ -635,6 +635,60 @@ static ConstantAddress tryEmitGlobalComp
>return ConstantAddress(GV, Align);
>  }
>
> +static llvm::Constant *
> +EmitArrayConstant(CodeGenModule &CGM, const ConstantArrayType *DestType,
> +  llvm::Type *CommonElementType, unsigned ArrayBound,
> +  SmallVectorImpl &Elements,
> +  llvm::Constant *Filler) {
> +  // Figure out how long the initial prefix of non-zero elements is.
> +  unsigned NonzeroLength = ArrayBound;
> +  if (Elements.size() < NonzeroLength && Filler->isNullValue())
> +NonzeroLength = Elements.size();
> +  if (NonzeroLength == Elements.size()) {
> +while (NonzeroLength > 0 && Elements[NonzeroLength -
> 1]->isNullValue())
> +  --NonzeroLength;
> +  }
> +
> +  if (NonzeroLength == 0) {
> +return llvm::ConstantAggregateZero::get(
> +CGM.getTypes().ConvertType(QualType(DestType, 0)));
> +  }
> +
> +  // Add a zeroinitializer array filler if we have lots of trailing
> zeroes.
> +  unsigned TrailingZeroes = ArrayBound - NonzeroLength;
> +  if (TrailingZeroes >= 8) {
> +assert(Elements.size() >= NonzeroLength &&
> +   "missing initializer for non-zero element");
> +Elements.resize(NonzeroLength + 1);
> +auto *FillerType =
> +CommonElementType
> +? CommonElementType
> +: CGM.getTypes().ConvertType(DestType->getElementType());
> +FillerType = llvm::ArrayType::get(FillerType, TrailingZeroes);
> +Elements.back() = llvm::ConstantAggregateZero::get(FillerType);
> +CommonElementType = nullptr;
> +  } else if (Elements.size() != ArrayBound) {
> +// Otherwise pad to the right size with the filler if necessary.
> +Elements.resize(ArrayBound, Filler);
> +if (Filler->getType() != CommonElementType)
> +  CommonElementType = nullptr;
> +  }
> +
> +  // If all elements have the same type, just emit an array constant.
> +  if (CommonElementType)
> +return llvm::ConstantArray::get(
> +llvm::ArrayType::get(CommonElementType, ArrayBound), Elements);
> +
> +  // We have mixed types. Use a packed struct.
> +  llvm::SmallVector Types;
> +  Types.reserve(Elements.size());
> +  for (llvm::Constant *Elt : Elements)
> +Types.push_back(Elt->getType());
> +  llvm::StructType *SType =
> +  llvm::StructType::get(CGM.getLLVMContext(), Types, true);
> +  return llvm::ConstantStruct::get(SType, Elements);
> +}
> +
>  /// This class only needs to handle two cases:
>  /// 1) Literals (this is used by APValue emission to emit literals).
>  /// 2) Arrays, structs and unions (outside C++11 mode, we don't currently
> @@ -832,68 +886,47 @@ public:
>}
>
>llvm::Constant *EmitArrayInitialization(InitListExpr *ILE, QualType T) {
> -llvm::ArrayType *AType =
> -cast(ConvertType(ILE->getType()));
> -llvm::Type *ElemTy = AType->getElementType();
> +auto *CAT = CGM.getContext().getAsConstantArrayType(ILE->getType());
> +assert(CAT && "can't emit array init for non-constant-bound array");
>  unsigned NumInitElements = ILE->getNumInits();
> -unsigned NumElements = AType->getNumElements();
> +unsigned NumElements = CAT->getSize().getZExtValue();
>
>  // Initialising an array requires us to automatically
>  // initialise any elements that have not been initialised explicitly
>  unsigned NumInitableElts = std::min(NumInitElements, NumElements);
>
> -QualType EltType =
> CGM.getContext().getAsArrayType(T)->getElementType();
> +QualType EltType = CAT->getElementType();
>
>  // Initialize remaining array elements.
> -llvm::Constant *fillC;
> -if (Expr *filler = ILE->getArrayFiller())
> +llvm::Constant *fillC = nullptr;
> +if (Expr *filler = ILE->getArrayFiller(

Re: r314079 - Fix implicit-fallthrough warning by adding missing break

[David Blaikie via cfe-commits]

Is there also missing test coverage here?

On Sun, Sep 24, 2017 at 8:19 AM Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rksimon
> Date: Sun Sep 24 08:17:46 2017
> New Revision: 314079
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314079&view=rev
> Log:
> Fix implicit-fallthrough warning by adding missing break
>
> Modified:
> cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp
>
> Modified: cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp?rev=314079&r1=314078&r2=314079&view=diff
>
> ==
> --- cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp (original)
> +++ cfe/trunk/lib/CrossTU/CrossTranslationUnit.cpp Sun Sep 24 08:17:46 2017
> @@ -185,6 +185,7 @@ void CrossTranslationUnitContext::emitCr
>case index_error_code::invalid_index_format:
>  Context.getDiagnostics().Report(diag::err_fnmap_parsing)
>  << IE.getFileName() << IE.getLineNum();
> +break;
>case index_error_code::multiple_definitions:
>  Context.getDiagnostics().Report(diag::err_multiple_def_index)
>  << IE.getLineNum();
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

[David Blaikie via cfe-commits]

On Wed, Sep 27, 2017 at 11:50 AM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson added a comment.
>
> In https://reviews.llvm.org/D14358#882445, @dblaikie wrote:
>
> > > I would prefer to eliminate the `` from the instance name as
> well, because our debugger reconstructs a name more to its liking from the
> parameter children.  However, IIUC the name with params is used for
> deduplication in LTO, so that is probably not such a good idea. :-)
> >
> > Though you have this out of tree? How do you cope with LTO there?
>
>
> We discovered that we had to keep them in the name for LTO.
>
> > I've not fully refreshed myself on the previous conversations - but it
> looks like my thought was that this state proposed here is
> weird/inconsistent: The parameters are already in the name, so adding them
> in the DIEs seems redundant. If the parameters weren't in the name then
> this change might make more sense.
>
> Our debugger throws away the params in the name, and relies on the
> children.  The names as rendered in DWARF by Clang are not textually
> consistent with names as rendered by the demangler.  Our debugger uses the
> children to construct names that are consistent with how the demangler
> works.  Then it can match up type names returned by the demangler to type
> names it has constructed.  Assuming I am not misunderstanding our debugger
> guys again, but that's my recollection.
>
> I believe we have talked previously about using a different scheme for
> deduplication that doesn't depend (or not so much) on the names.  If we had
> that, we could eliminate params from the name, and save probably a
> noticeable chunk of space in the string section.  I haven't tried to
> measure that, though.  But we have to have the children in place before we
> can experiment with other deduplication schemes.
>

Fair enough - yeah, I would agree with Adrian that this probably isn't a
driver flag (at least not yet), though. Either only driven by the debugger
tuning (though perhaps we had some position that debugger tuning wouldn't
ever be the only way to access functionality, only change defaults) or
additionally a cc1 flag. Haven't thought about the name.


>
> There is also the pedantic point that DWARF doesn't say these child
> entries are optional, or omitted for forward declarations.  I know gcc
> doesn't (or didn't, anyway; what I have locally is gcc 5.4) but gcc is not
> the arbiter of what constitutes conforming DWARF.
>
>
> https://reviews.llvm.org/D14358
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14358: DWARF's forward decl of a template should have template parameters.

[David Blaikie via cfe-commits]

On Wed, Sep 27, 2017 at 1:58 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson added a reviewer: rnk.
> probinson added a comment.
>
> +rnk for the CodeView question.
>
>
>
> 
> Comment at: include/clang/Frontend/CodeGenOptions.def:222
>  ///< of inline stack frames without
> .dwo files.
> +CODEGENOPT(DebugFwdTemplateParams, 1, 0) ///< Whether to emit complete
> + ///< template parameter
> descriptions in
> 
> dblaikie wrote:
> > Maybe 'Decl' rather than 'Fwd'.
> Well, in a sense they are all declarations, and 'Fwd' is a clearer
> statement of the distinction this flag is trying to make.  Unless you feel
> strongly I'd prefer to leave it as is.
>

Fair enough.


> 
> Comment at: lib/CodeGen/CGDebugInfo.cpp:836
>llvm::DINode::FlagFwdDecl, FullName);
> +  if (CGM.getCodeGenOpts().DebugFwdTemplateParams)
> +if (auto *TSpecial = dyn_cast(RD))
> 
> It just occurred to me... should CodeView care about this?
>

Not sure

Reid?


>
>
> 
> Comment at: test/CodeGenCXX/debug-info-fwd-template-param.cpp:7
> +template class A;
> +A *p;
> +
> 
> dblaikie wrote:
> > Any particular reason for const int, rather than int?
> It was the illustrative example of the difference between the demangler
> ("int const") and clang ("const int") that the debugger guys tripped over,
> and so was in the source I started with when creating this test.  I think
> you are correct, it is not important to have it.
>

*nod* I understand that it's part of the original issue, but doesn't seem
needed/relevant here.  Thanks! :)


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

Re: [PATCH] D38464: [clangd] less boilerplate in RPC dispatch

[David Blaikie via cfe-commits]

hey Lang (& folks here) any chance there's some overlap between the RPC
functionality here and the RPC functionality in ORC that could be
deduplicated/refactored?

On Fri, Oct 6, 2017 at 5:30 AM Ilya Biryukov via Phabricator via
cfe-commits  wrote:

> ilya-biryukov accepted this revision.
> ilya-biryukov added a comment.
> This revision is now accepted and ready to land.
>
> LGTM.
> Note there's a new LSP method handler added upstream
> (`textDocument/signatureHelp`), we should add it to this change before
> submitting.
>
>
>
> 
> Comment at: clangd/ClangdLSPServer.h:47
>// Implement ProtocolCallbacks.
> -  void onInitialize(StringRef ID, InitializeParams IP,
> -JSONOutput &Out) override;
> -  void onShutdown(JSONOutput &Out) override;
> -  void onDocumentDidOpen(DidOpenTextDocumentParams Params,
> - JSONOutput &Out) override;
> -  void onDocumentDidChange(DidChangeTextDocumentParams Params,
> -   JSONOutput &Out) override;
> -  void onDocumentDidClose(DidCloseTextDocumentParams Params,
> -  JSONOutput &Out) override;
> -  void onDocumentOnTypeFormatting(DocumentOnTypeFormattingParams Params,
> -  StringRef ID, JSONOutput &Out) override;
> -  void onDocumentRangeFormatting(DocumentRangeFormattingParams Params,
> - StringRef ID, JSONOutput &Out) override;
> -  void onDocumentFormatting(DocumentFormattingParams Params, StringRef ID,
> -JSONOutput &Out) override;
> -  void onCodeAction(CodeActionParams Params, StringRef ID,
> -JSONOutput &Out) override;
> -  void onCompletion(TextDocumentPositionParams Params, StringRef ID,
> -JSONOutput &Out) override;
> -  void onGoToDefinition(TextDocumentPositionParams Params, StringRef ID,
> -JSONOutput &Out) override;
> -  void onSwitchSourceHeader(TextDocumentIdentifier Params, StringRef ID,
> -JSONOutput &Out) override;
> +  void onInitialize(Ctx &C, InitializeParams &Params) override;
> +  void onShutdown(Ctx &C, NoParams &Params) override;
> 
> sammccall wrote:
> > ilya-biryukov wrote:
> > > ilya-biryukov wrote:
> > > > Maybe there's a way to have a typed return value instead of `Ctx`?
> > > > This would give an interface that's harder to misuse: one can't
> forget to call `reply` or call it twice.
> > > >
> > > > Here's on design that comes to mind.
> > > > Notification handlers could have `void` return, normal requests can
> return `Optional` or `Optional` (with result json).
> > > > `Optional` is be used to indicate whether error occurred while
> processing the request.
> > > >
> > > After putting more thought into it, `Ctx`-based API seems to have an
> advantage: it will allow us to easily implement async responses.
> > > E.g., we can run code completion on a background thread and continue
> processing other requests. When completion is ready, we will simply call
> `Ctx.reply` to return results to the language client.
> > >
> > > To make that possible, can we allow moving `RequestContext` and pass
> it by-value instead of by-ref?
> > Yeah I thought about returning a value... it certainly reads more
> nicely, but I don't think we're ready to do a good job in this patch:
> >  - return value should be an object ready to be serialized (rather than
> a JSON string) - I don't want to bring that in scope here, but it might
> affect the details of the API
> >  - there's several cases we know about (return object, no reply, error
> reply) and some we're not sure about (async as you mention - any multiple
> responses)? I think this needs some design, and I don't yet know the
> project well enough to drive it.
> >
> > I've switched to passing Ctx by value as you suggest (though it's
> certainly cheap enough to copy, too).
> Yeah, copy is also fine there performance-wise.
>
> I do think move-only interface fits slightly better. We can check a whole
> bunch of invariants if `Ctx` is move-only (i.e., that request wasn't
> dropped without response or `reply` was not called twice).
>
>
> 
> Comment at: clangd/ClangdLSPServer.h:48
> +  void onInitialize(Ctx &C, InitializeParams &Params) override;
> +  void onShutdown(Ctx &C, NoParams &Params) override;
> +  void onDocumentDidOpen(Ctx &C, DidOpenTextDocumentParams &Params)
> override;
> 
> sammccall wrote:
> > ilya-biryukov wrote:
> > > Maybe there's a way to get rid of `NoParams`?
> > > E.g. by adding a overload to `HandlerRegisterer`?
> > Even if there was, I think I prefer the regularity (changed this to
> ShutdownParams - oops!).
> >
> > Otherwise the signature's dependent on some combination of {current LSP,
> whether we actually implement the options, whether we've defined any
> extensions}. It's harder to remember, means changing lots of places when
> these factors change, and complica

Re: [PATCH] D38464: [clangd] less boilerplate in RPC dispatch

[David Blaikie via cfe-commits]

I mention it only out of interest of deduplication of functionality/code
within the LLVM project as a whole. Be nice not to maintain two things if
one would suffice.

On Thu, Oct 12, 2017 at 6:21 AM Sam McCall  wrote:

> Interesting - this is pretty primitive, and still fairly tightly coupled
> to JSON-RPC.
> I can't easily tell from the code how the ORC RPC functionality - would it
> be easy to use with JSON-RPC, does it make sense to use serialization only,
> does it have opinions about threading models? And really, what would we
> expect to gain vs using the current more naive code (it looks more
> complicated, probably having more complex requirements).
>
> On Mon, Oct 9, 2017 at 11:16 PM, David Blaikie  wrote:
>
>> hey Lang (& folks here) any chance there's some overlap between the RPC
>> functionality here and the RPC functionality in ORC that could be
>> deduplicated/refactored?
>>
>> On Fri, Oct 6, 2017 at 5:30 AM Ilya Biryukov via Phabricator via
>> cfe-commits  wrote:
>>
>>> ilya-biryukov accepted this revision.
>>> ilya-biryukov added a comment.
>>> This revision is now accepted and ready to land.
>>>
>>> LGTM.
>>> Note there's a new LSP method handler added upstream
>>> (`textDocument/signatureHelp`), we should add it to this change before
>>> submitting.
>>>
>>>
>>>
>>> 
>>> Comment at: clangd/ClangdLSPServer.h:47
>>>// Implement ProtocolCallbacks.
>>> -  void onInitialize(StringRef ID, InitializeParams IP,
>>> -JSONOutput &Out) override;
>>> -  void onShutdown(JSONOutput &Out) override;
>>> -  void onDocumentDidOpen(DidOpenTextDocumentParams Params,
>>> - JSONOutput &Out) override;
>>> -  void onDocumentDidChange(DidChangeTextDocumentParams Params,
>>> -   JSONOutput &Out) override;
>>> -  void onDocumentDidClose(DidCloseTextDocumentParams Params,
>>> -  JSONOutput &Out) override;
>>> -  void onDocumentOnTypeFormatting(DocumentOnTypeFormattingParams Params,
>>> -  StringRef ID, JSONOutput &Out)
>>> override;
>>> -  void onDocumentRangeFormatting(DocumentRangeFormattingParams Params,
>>> - StringRef ID, JSONOutput &Out)
>>> override;
>>> -  void onDocumentFormatting(DocumentFormattingParams Params, StringRef
>>> ID,
>>> -JSONOutput &Out) override;
>>> -  void onCodeAction(CodeActionParams Params, StringRef ID,
>>> -JSONOutput &Out) override;
>>> -  void onCompletion(TextDocumentPositionParams Params, StringRef ID,
>>> -JSONOutput &Out) override;
>>> -  void onGoToDefinition(TextDocumentPositionParams Params, StringRef ID,
>>> -JSONOutput &Out) override;
>>> -  void onSwitchSourceHeader(TextDocumentIdentifier Params, StringRef ID,
>>> -JSONOutput &Out) override;
>>> +  void onInitialize(Ctx &C, InitializeParams &Params) override;
>>> +  void onShutdown(Ctx &C, NoParams &Params) override;
>>> 
>>> sammccall wrote:
>>> > ilya-biryukov wrote:
>>> > > ilya-biryukov wrote:
>>> > > > Maybe there's a way to have a typed return value instead of `Ctx`?
>>> > > > This would give an interface that's harder to misuse: one can't
>>> forget to call `reply` or call it twice.
>>> > > >
>>> > > > Here's on design that comes to mind.
>>> > > > Notification handlers could have `void` return, normal requests
>>> can return `Optional` or `Optional` (with result json).
>>> > > > `Optional` is be used to indicate whether error occurred while
>>> processing the request.
>>> > > >
>>> > > After putting more thought into it, `Ctx`-based API seems to have an
>>> advantage: it will allow us to easily implement async responses.
>>> > > E.g., we can run code completion on a background thread and continue
>>> processing other requests. When completion is ready, we will simply call
>>> `Ctx.reply` to return results to the language client.
>>> > >
>>> > > To make that possible, can we allow moving `RequestContext` and pass
>>> it by-value instead of by-ref?
>>> > Yeah I thought about returning a value... it certainly reads more
>>> nicely, but I don't think we're ready to do a good job in this patch:
>>> >  - return value should be an object ready to be serialized (rather
>>> than a JSON string) - I don't want to bring that in scope here, but it
>>> might affect the details of the API
>>> >  - there's several cases we know about (return object, no reply, error
>>> reply) and some we're not sure about (async as you mention - any multiple
>>> responses)? I think this needs some design, and I don't yet know the
>>> project well enough to drive it.
>>> >
>>> > I've switched to passing Ctx by value as you suggest (though it's
>>> certainly cheap enough to copy, too).
>>> Yeah, copy is also fine there performance-wise.
>>>
>>> I do think move-only interface fits slightly better. We can check a
>>> whole bunch of invariants if 

Re: [libcxx] r315874 - Silence clang's -Wtautological-constant-compare in last_write_time.pass.cpp

[David Blaikie via cfe-commits]

Would it be better/possible to improve the warning to not have this false
positive, rather than suppressing it?

On Sun, Oct 15, 2017 at 1:12 PM Roman Lebedev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: lebedevri
> Date: Sun Oct 15 13:12:42 2017
> New Revision: 315874
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315874&view=rev
> Log:
> Silence clang's -Wtautological-constant-compare in last_write_time.pass.cpp
>
> Previously this broke the builders, when D38101 was committed.
> Silence the warning so that it can be re-landed.
>
> Modified:
>
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
>
> Modified:
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp?rev=315874&r1=315873&r2=315874&view=diff
>
> ==
> ---
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
> (original)
> +++
> libcxx/trunk/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp
> Sun Oct 15 13:12:42 2017
> @@ -88,6 +88,13 @@ bool TestSupportsNegativeTimes() {
>  return !ec && new_write_time <= -5;
>  }
>
> +// In some configurations, the comparison is tautological and the test is
> valid.
> +// We disable the warning so that we can actually test it regardless.
> +#if defined(__clang__)
> +#pragma clang diagnostic push
> +#pragma clang diagnostic ignored "-Wtautological-constant-compare"
> +#endif
> +
>  bool TestSupportsMaxTime() {
>  using namespace std::chrono;
>  using Lim = std::numeric_limits;
> @@ -106,11 +113,22 @@ bool TestSupportsMaxTime() {
>  return !ec && new_write_time > max_sec - 1;
>  }
>
> +#if defined(__clang__)
> +#pragma clang diagnostic pop
> +#endif
> +
>  static const bool SupportsNegativeTimes = TestSupportsNegativeTimes();
>  static const bool SupportsMaxTime = TestSupportsMaxTime();
>
>  } // end namespace
>
> +// In some configurations, the comparison is tautological and the test is
> valid.
> +// We disable the warning so that we can actually test it regardless.
> +#if defined(__clang__)
> +#pragma clang diagnostic push
> +#pragma clang diagnostic ignored "-Wtautological-constant-compare"
> +#endif
> +
>  // Check if a time point is representable on a given filesystem. Check
> that:
>  // (A) 'tp' is representable as a time_t
>  // (B) 'tp' is non-negative or the filesystem supports negative times.
> @@ -127,6 +145,10 @@ inline bool TimeIsRepresentableByFilesys
>  return true;
>  }
>
> +#if defined(__clang__)
> +#pragma clang diagnostic pop
> +#endif
> +
>  TEST_SUITE(exists_test_suite)
>
>  TEST_CASE(signature_test)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r315755 - Fix -Woverloaded-virtual warning in clang-refactor

[David Blaikie via cfe-commits]

Is there a test that could be added to cover this new code?

On Fri, Oct 13, 2017 at 2:15 PM Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Fri Oct 13 14:15:25 2017
> New Revision: 315755
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315755&view=rev
> Log:
> Fix -Woverloaded-virtual warning in clang-refactor
>
> Modified:
> cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
>
> Modified: cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-refactor/ClangRefactor.cpp?rev=315755&r1=315754&r2=315755&view=diff
>
> ==
> --- cfe/trunk/tools/clang-refactor/ClangRefactor.cpp (original)
> +++ cfe/trunk/tools/clang-refactor/ClangRefactor.cpp Fri Oct 13 14:15:25
> 2017
> @@ -314,6 +314,10 @@ public:
>  SourceChanges.insert(SourceChanges.begin(), Changes.begin(),
> Changes.end());
>}
>
> +  void handle(SymbolOccurrences Occurrences) override {
> +RefactoringResultConsumer::handle(std::move(Occurrences));
> +  }
> +
>const AtomicChanges &getSourceChanges() const { return SourceChanges; }
>
>  private:
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r315323 - [clangd] Added forgotten return in UniqueFunction.

[David Blaikie via cfe-commits]

Is there missing test coverage for this?

On Tue, Oct 10, 2017 at 9:12 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ibiryukov
> Date: Tue Oct 10 09:12:47 2017
> New Revision: 315323
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315323&view=rev
> Log:
> [clangd] Added forgotten return in UniqueFunction.
>
> This hasn't bitten us because we only used functions returning
> 'void'.
>
> Modified:
> clang-tools-extra/trunk/clangd/Function.h
>
> Modified: clang-tools-extra/trunk/clangd/Function.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Function.h?rev=315323&r1=315322&r2=315323&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/Function.h (original)
> +++ clang-tools-extra/trunk/clangd/Function.h Tue Oct 10 09:12:47 2017
> @@ -46,7 +46,7 @@ public:
>
>Ret operator()(Args... As) {
>  assert(CallablePtr);
> -CallablePtr->Call(std::forward(As)...);
> +return CallablePtr->Call(std::forward(As)...);
>}
>
>  private:
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r315755 - Fix -Woverloaded-virtual warning in clang-refactor

[David Blaikie via cfe-commits]

Generally it's preferably to avoid adding dead code (partly for this reason
- it's hard to track when it gets used and ensure it's appropriately
tested) could the member function's body be replaced with llvm_unreachable
for now, then?

On Mon, Oct 16, 2017 at 10:27 AM Alex L  wrote:

> At the moment this method override is not used by the clang-refactor tool,
> so I don't think I can add a test for it.
>
> On 16 October 2017 at 10:11, David Blaikie  wrote:
>
>> Is there a test that could be added to cover this new code?
>>
>> On Fri, Oct 13, 2017 at 2:15 PM Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Fri Oct 13 14:15:25 2017
>>> New Revision: 315755
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=315755&view=rev
>>> Log:
>>> Fix -Woverloaded-virtual warning in clang-refactor
>>>
>>> Modified:
>>> cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
>>>
>>> Modified: cfe/trunk/tools/clang-refactor/ClangRefactor.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-refactor/ClangRefactor.cpp?rev=315755&r1=315754&r2=315755&view=diff
>>>
>>> ==
>>> --- cfe/trunk/tools/clang-refactor/ClangRefactor.cpp (original)
>>> +++ cfe/trunk/tools/clang-refactor/ClangRefactor.cpp Fri Oct 13 14:15:25
>>> 2017
>>> @@ -314,6 +314,10 @@ public:
>>>  SourceChanges.insert(SourceChanges.begin(), Changes.begin(),
>>> Changes.end());
>>>}
>>>
>>> +  void handle(SymbolOccurrences Occurrences) override {
>>> +RefactoringResultConsumer::handle(std::move(Occurrences));
>>> +  }
>>> +
>>>const AtomicChanges &getSourceChanges() const { return SourceChanges;
>>> }
>>>
>>>  private:
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39069: CodeGen: Fix missing debug loc due to alloca

[David Blaikie via cfe-commits]

What John said, but also a narrower test would be good - checking that the
appropriate call instruction gets a debug location, rather than checking
that a bunch of inlining doesn't cause the assertion/verifier failure,
would be good. (Clang tests should, as much as possible, not rely on or run
the LLVM optimization passes - but check the IR coming directly from Clang
before any of that)

On Wed, Oct 18, 2017 at 2:15 PM Yaxun Liu via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> yaxunl created this revision.
>
> Builder save/restores insertion pointer when emitting addr space cast
> for alloca, but does not save/restore debug loc, which causes verifier
> failure for certain call instructions.
>
> This patch fixes that.
>
>
> https://reviews.llvm.org/D39069
>
> Files:
>   lib/CodeGen/CGExpr.cpp
>   test/CodeGenOpenCL/func-call-dbg-loc.cl
>
>
> Index: test/CodeGenOpenCL/func-call-dbg-loc.cl
> ===
> --- /dev/null
> +++ test/CodeGenOpenCL/func-call-dbg-loc.cl
> @@ -0,0 +1,34 @@
> +// RUN: %clang_cc1 -triple amdgcn---amdgizcl -debug-info-kind=limited
> -dwarf-version=2 -debugger-tuning=gdb -O0 -emit-llvm -o - %s | FileCheck %s
> +// Checks the file compiles without verifier error: inlinable function
> call in a function with debug info must have a !dbg location.
> +
> +typedef struct
> +{
> +float m_max;
> +} Struct;
> +
> +typedef struct
> +{
> +Struct m_volume;
> +} Node;
> +
> +
> +Struct buzz(Node node)
> +{
> +return node.m_volume;
> +}
> +
> +__attribute__((always_inline))
> +float bar(Struct aabb)
> +{
> +return 0.0f;
> +}
> +
> +__attribute__((used))
> +void foo()
> +{
> +Node node;
> +// CHECK: store float 0.00e+00, float addrspace(5)* %f, align 4,
> !dbg !{{[0-9]+}}
> +float f = bar(buzz(node));
> +}
> +
> +
> Index: lib/CodeGen/CGExpr.cpp
> ===
> --- lib/CodeGen/CGExpr.cpp
> +++ lib/CodeGen/CGExpr.cpp
> @@ -75,11 +75,13 @@
>if (CastToDefaultAddrSpace && getASTAllocaAddressSpace() !=
> LangAS::Default) {
>  auto DestAddrSpace =
> getContext().getTargetAddressSpace(LangAS::Default);
>  auto CurIP = Builder.saveIP();
> +auto DbgLoc = Builder.getCurrentDebugLocation();
>  Builder.SetInsertPoint(AllocaInsertPt);
>  V = getTargetHooks().performAddrSpaceCast(
>  *this, V, getASTAllocaAddressSpace(), LangAS::Default,
>  Ty->getPointerTo(DestAddrSpace), /*non-null*/ true);
>  Builder.restoreIP(CurIP);
> +Builder.SetCurrentDebugLocation(DbgLoc);
>}
>
>return Address(V, Align);
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r324498 - [Driver] Add option to manually control discarding value names in LLVM IR.

[David Blaikie via cfe-commits]

On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Wed Feb  7 10:36:51 2018
> New Revision: 324498
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
> Log:
> [Driver] Add option to manually control discarding value names in LLVM IR.
>
> Summary:
> Currently, assertion-disabled Clang builds emit value names when
> generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not
> easily overridable. In order to get IR output containing names from a
> release build of Clang, the user must manually construct the CC1 invocation
> w/o the `-discard-value-names` option. This is less than ideal.
>
> For example, Godbolt uses a release build of Clang, and so when asked to
> emit LLVM IR the result lacks names, making it harder to read. Manually
> invoking CC1 on Compiler Explorer is not feasible.
>

It wouldn't necessarily have to invoke CC1, it could use "-Xclang
-discard-value-names".


>
> This patch adds the driver options `-fdiscard-value-names` and
> `-fno-discard-value-names` which allow the user to override the default
> behavior. If neither is specified, the old behavior remains.
>
> Reviewers: erichkeane, aaron.ballman, lebedev.ri
>
> Reviewed By: aaron.ballman
>
> Subscribers: bogner, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D42887
>
> Modified:
> cfe/trunk/docs/UsersManual.rst
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/test/Driver/clang_f_opts.c
>
> Modified: cfe/trunk/docs/UsersManual.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/docs/UsersManual.rst (original)
> +++ cfe/trunk/docs/UsersManual.rst Wed Feb  7 10:36:51 2018
> @@ -1855,6 +1855,27 @@ features. You can "tune" the debug info
>must come first.)
>
>
> +Controlling LLVM IR Output
> +--
> +
> +Controlling Value Names in LLVM IR
> +^^
> +
> +Emitting value names in LLVM IR increases the size and verbosity of the
> IR.
> +By default, value names are only emitted in assertion-enabled builds of
> Clang.
> +However, when reading IR it can be useful to re-enable the emission of
> value
> +names to improve readability.
> +
> +.. option:: -fdiscard-value-names
> +
> +  Discard value names when generating LLVM IR.
> +
> +.. option:: -fno-discard-value-names
> +
> +  Do not discard value names when generating LLVM IR. This option can be
> used
> +  to re-enable names for release builds of Clang.
> +
> +
>  Comment Parsing Options
>  ---
>
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb  7 10:36:51 2018
> @@ -790,6 +790,10 @@ def fdiagnostics_show_template_tree : Fl
>  HelpText<"Print a template comparison tree for differing templates">;
>  def fdeclspec : Flag<["-"], "fdeclspec">, Group,
>HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
> +def fdiscard_value_names : Flag<["-"], "fdiscard-value-names">,
> Group,
> +  HelpText<"Discard value names in LLVM IR">, Flags<[DriverOption]>;
> +def fno_discard_value_names : Flag<["-"], "fno-discard-value-names">,
> Group,
> +  HelpText<"Do not discard value names in LLVM IR">,
> Flags<[DriverOption]>;
>  def fdollars_in_identifiers : Flag<["-"], "fdollars-in-identifiers">,
> Group,
>HelpText<"Allow '$' in identifiers">, Flags<[CC1Option]>;
>  def fdwarf2_cfi_asm : Flag<["-"], "fdwarf2-cfi-asm">,
> Group;
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Wed Feb  7 10:36:51 2018
> @@ -3266,13 +3266,24 @@ void Clang::ConstructJob(Compilation &C,
>if (!C.isForDiagnostics())
>  CmdArgs.push_back("-disable-free");
>
> -// Disable the verification pass in -asserts builds.
>  #ifdef NDEBUG
> -  CmdArgs.push_back("-disable-llvm-verifier");
> -  // Discard LLVM value names in -asserts builds.
> -  CmdArgs.push_back("-discard-value-names");
> +  const bool IsAssertBuild = false;
> +#else
> +  const bool IsAssertBuild = true;
>  #endif
>
> +  // Disable the verification pass in -asserts builds.
> +  if (!IsAssertBuild)
> +CmdArgs.push_back("disable-llvm-verifier");
> +
> +  // Discard value names in asse

Re: [PATCH] D43128: Introduce an API for LLDB to compute the default module cache path

[David Blaikie via cfe-commits]

Unit test?

On Fri, Feb 9, 2018 at 10:45 AM Phabricator via Phabricator via
llvm-commits  wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL324761: Introduce an API for LLDB to compute the
> default module cache path (authored by adrian, committed by ).
> Herald added a subscriber: llvm-commits.
>
> Changed prior to commit:
>   https://reviews.llvm.org/D43128?vs=133631&id=133650#toc
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D43128
>
> Files:
>   cfe/trunk/include/clang/Driver/Driver.h
>   cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>
>
> Index: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> ===
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> @@ -2500,6 +2500,13 @@
>  CmdArgs.push_back("-fno-math-builtin");
>  }
>
> +void Driver::getDefaultModuleCachePath(SmallVectorImpl &Result) {
> +  llvm::sys::path::system_temp_directory(/*erasedOnReboot=*/false,
> Result);
> +  llvm::sys::path::append(Result, "org.llvm.clang.");
> +  appendUserToPath(Result);
> +  llvm::sys::path::append(Result, "ModuleCache");
> +}
> +
>  static void RenderModulesOptions(Compilation &C, const Driver &D,
>   const ArgList &Args, const InputInfo
> &Input,
>   const InputInfo &Output,
> @@ -2560,10 +2567,7 @@
>llvm::sys::path::append(Path, "modules");
>  } else if (Path.empty()) {
>// No module path was provided: use the default.
> -  llvm::sys::path::system_temp_directory(/*erasedOnReboot=*/false,
> Path);
> -  llvm::sys::path::append(Path, "org.llvm.clang.");
> -  appendUserToPath(Path);
> -  llvm::sys::path::append(Path, "ModuleCache");
> +  Driver::getDefaultModuleCachePath(Path);
>  }
>
>  const char Arg[] = "-fmodules-cache-path=";
> Index: cfe/trunk/include/clang/Driver/Driver.h
> ===
> --- cfe/trunk/include/clang/Driver/Driver.h
> +++ cfe/trunk/include/clang/Driver/Driver.h
> @@ -572,6 +572,8 @@
>/// no extra characters remaining at the end.
>static bool GetReleaseVersion(StringRef Str,
>  MutableArrayRef Digits);
> +  /// Compute the default -fmodule-cache-path.
> +  static void getDefaultModuleCachePath(SmallVectorImpl &Result);
>  };
>
>  /// \return True if the last defined optimization level is -Ofast.
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r324433 - [NFC] Change odd cast-through-unknown behavior to an Optional

[David Blaikie via cfe-commits]

FWIW, you can write "*M" rather than M.getValue() if you reckon that's
neater.

And you could roll the declaration/initialization of M into the 'if'
condition - but I can understand why you might prefer not to, given it's a
many-line statement, etc.

On Tue, Feb 6, 2018 at 4:39 PM Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: erichkeane
> Date: Tue Feb  6 16:37:19 2018
> New Revision: 324433
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324433&view=rev
> Log:
> [NFC] Change odd cast-through-unknown behavior to an Optional
>
> This bit of code in the driver uses '~0U' as a sentinel value.
> The result is an odd mishmash of casts just to work.  This replaces
> it with an optional,  which is a little less crazy looking.
> --ehis line, and those below, will be ignored--
>
> Mlib/Driver/Driver.cpp
>
> Modified:
> cfe/trunk/lib/Driver/Driver.cpp
>
> Modified: cfe/trunk/lib/Driver/Driver.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=324433&r1=324432&r2=324433&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/Driver.cpp (original)
> +++ cfe/trunk/lib/Driver/Driver.cpp Tue Feb  6 16:37:19 2018
> @@ -148,15 +148,15 @@ void Driver::setDriverModeFromOption(Str
>  return;
>StringRef Value = Opt.drop_front(OptName.size());
>
> -  const unsigned M = llvm::StringSwitch(Value)
> - .Case("gcc", GCCMode)
> - .Case("g++", GXXMode)
> - .Case("cpp", CPPMode)
> - .Case("cl", CLMode)
> - .Default(~0U);
> +  auto M = llvm::StringSwitch>(Value)
> +   .Case("gcc", GCCMode)
> +   .Case("g++", GXXMode)
> +   .Case("cpp", CPPMode)
> +   .Case("cl", CLMode)
> +   .Default(None);
>
> -  if (M != ~0U)
> -Mode = static_cast(M);
> +  if (M)
> +Mode = M.getValue();
>else
>  Diag(diag::err_drv_unsupported_option_argument) << OptName << Value;
>  }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r324498 - [Driver] Add option to manually control discarding value names in LLVM IR.

[David Blaikie via cfe-commits]

On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier  wrote:

> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie  wrote:
>
>>
>>
>> On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ericwf
>>> Date: Wed Feb  7 10:36:51 2018
>>> New Revision: 324498
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
>>> Log:
>>> [Driver] Add option to manually control discarding value names in LLVM
>>> IR.
>>>
>>> Summary:
>>> Currently, assertion-disabled Clang builds emit value names when
>>> generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not
>>> easily overridable. In order to get IR output containing names from a
>>> release build of Clang, the user must manually construct the CC1 invocation
>>> w/o the `-discard-value-names` option. This is less than ideal.
>>>
>>> For example, Godbolt uses a release build of Clang, and so when asked to
>>> emit LLVM IR the result lacks names, making it harder to read. Manually
>>> invoking CC1 on Compiler Explorer is not feasible.
>>>
>>
>> It wouldn't necessarily have to invoke CC1, it could use "-Xclang
>> -discard-value-names".
>>
>
> If you were using an assertion build, and wanted to disable value names,
> then yes -- that would work. However it's the opposite case that is of
> interest:
> When you're using a non-assertion build and want to keep value names. In
> that case invoking CC1 directly is required; otherwise the driver would pass
> "-discard-value-names".
>

Ah, thanks for explaining!


>
>
>>
>>
>>>
>>> This patch adds the driver options `-fdiscard-value-names` and
>>> `-fno-discard-value-names` which allow the user to override the default
>>> behavior. If neither is specified, the old behavior remains.
>>>
>>> Reviewers: erichkeane, aaron.ballman, lebedev.ri
>>>
>>> Reviewed By: aaron.ballman
>>>
>>> Subscribers: bogner, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D42887
>>>
>>> Modified:
>>> cfe/trunk/docs/UsersManual.rst
>>> cfe/trunk/include/clang/Driver/Options.td
>>> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>>> cfe/trunk/test/Driver/clang_f_opts.c
>>>
>>> Modified: cfe/trunk/docs/UsersManual.rst
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/docs/UsersManual.rst (original)
>>> +++ cfe/trunk/docs/UsersManual.rst Wed Feb  7 10:36:51 2018
>>> @@ -1855,6 +1855,27 @@ features. You can "tune" the debug info
>>>must come first.)
>>>
>>>
>>> +Controlling LLVM IR Output
>>> +--
>>> +
>>> +Controlling Value Names in LLVM IR
>>> +^^
>>> +
>>> +Emitting value names in LLVM IR increases the size and verbosity of the
>>> IR.
>>> +By default, value names are only emitted in assertion-enabled builds of
>>> Clang.
>>> +However, when reading IR it can be useful to re-enable the emission of
>>> value
>>> +names to improve readability.
>>> +
>>> +.. option:: -fdiscard-value-names
>>> +
>>> +  Discard value names when generating LLVM IR.
>>> +
>>> +.. option:: -fno-discard-value-names
>>> +
>>> +  Do not discard value names when generating LLVM IR. This option can
>>> be used
>>> +  to re-enable names for release builds of Clang.
>>> +
>>> +
>>>  Comment Parsing Options
>>>  ---
>>>
>>>
>>> Modified: cfe/trunk/include/clang/Driver/Options.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Driver/Options.td (original)
>>> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb  7 10:36:51 2018
>>> @@ -790,6 +790,10 @@ def fdiagnostics_show_template_tree : Fl
>>>  HelpText<"Print a template comparison tree for differing
>>> templates">;
>>>  def fdeclspec : Flag<["-"], "fdeclspec">, Group,
>>>HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
>>> +def fdiscard_value_names : Flag<["-"], "fdiscard-value-names">,
>>> Group,
>>> +  HelpText<"Discard value names in LLVM IR">, Flags<[DriverOption]>;
>>> +def fno_discard_value_names : Flag<["-"], "fno-discard-value-names">,
>>> Group,
>>> +  HelpText<"Do not discard value names in LLVM IR">,
>>> Flags<[DriverOption]>;
>>>  def fdollars_in_identifiers : Flag<["-"], "fdollars-in-identifiers">,
>>> Group,
>>>HelpText<"Allow '$' in identifiers">, Flags<[CC1Option]>;
>>>  def fdwarf2_cfi_asm : Flag<["-"], "fdwarf2-cfi-asm">,
>>> Group;
>>>
>>> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Driver

Re: r324498 - [Driver] Add option to manually control discarding value names in LLVM IR.

[David Blaikie via cfe-commits]

ah, sweet :)

On Mon, Feb 12, 2018 at 2:59 PM Eric Fiselier  wrote:

> On Mon, Feb 12, 2018 at 3:35 PM, David Blaikie  wrote:
>
>>
>>
>> On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier  wrote:
>>
>>> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie 
>>> wrote:
>>>


 On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Wed Feb  7 10:36:51 2018
> New Revision: 324498
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
> Log:
> [Driver] Add option to manually control discarding value names in LLVM
> IR.
>
> Summary:
> Currently, assertion-disabled Clang builds emit value names when
> generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not
> easily overridable. In order to get IR output containing names from a
> release build of Clang, the user must manually construct the CC1 
> invocation
> w/o the `-discard-value-names` option. This is less than ideal.
>
> For example, Godbolt uses a release build of Clang, and so when asked
> to emit LLVM IR the result lacks names, making it harder to read. Manually
> invoking CC1 on Compiler Explorer is not feasible.
>

 It wouldn't necessarily have to invoke CC1, it could use "-Xclang
 -discard-value-names".

>>>
>>> If you were using an assertion build, and wanted to disable value names,
>>> then yes -- that would work. However it's the opposite case that is of
>>> interest:
>>> When you're using a non-assertion build and want to keep value names. In
>>> that case invoking CC1 directly is required; otherwise the driver would pass
>>> "-discard-value-names".
>>>
>>
>> Ah, thanks for explaining!
>>
>>
>>>
>>>


>
> This patch adds the driver options `-fdiscard-value-names` and
> `-fno-discard-value-names` which allow the user to override the default
> behavior. If neither is specified, the old behavior remains.
>
> Reviewers: erichkeane, aaron.ballman, lebedev.ri
>
> Reviewed By: aaron.ballman
>
> Subscribers: bogner, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D42887
>
> Modified:
> cfe/trunk/docs/UsersManual.rst
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/test/Driver/clang_f_opts.c
>
> Modified: cfe/trunk/docs/UsersManual.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/docs/UsersManual.rst (original)
> +++ cfe/trunk/docs/UsersManual.rst Wed Feb  7 10:36:51 2018
> @@ -1855,6 +1855,27 @@ features. You can "tune" the debug info
>must come first.)
>
>
> +Controlling LLVM IR Output
> +--
> +
> +Controlling Value Names in LLVM IR
> +^^
> +
> +Emitting value names in LLVM IR increases the size and verbosity of
> the IR.
> +By default, value names are only emitted in assertion-enabled builds
> of Clang.
> +However, when reading IR it can be useful to re-enable the emission
> of value
> +names to improve readability.
> +
> +.. option:: -fdiscard-value-names
> +
> +  Discard value names when generating LLVM IR.
> +
> +.. option:: -fno-discard-value-names
> +
> +  Do not discard value names when generating LLVM IR. This option can
> be used
> +  to re-enable names for release builds of Clang.
> +
> +
>  Comment Parsing Options
>  ---
>
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=324498&r1=324497&r2=324498&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb  7 10:36:51 2018
> @@ -790,6 +790,10 @@ def fdiagnostics_show_template_tree : Fl
>  HelpText<"Print a template comparison tree for differing
> templates">;
>  def fdeclspec : Flag<["-"], "fdeclspec">, Group,
>HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
> +def fdiscard_value_names : Flag<["-"], "fdiscard-value-names">,
> Group,
> +  HelpText<"Discard value names in LLVM IR">, Flags<[DriverOption]>;
> +def fno_discard_value_names : Flag<["-"], "fno-discard-value-names">,
> Group,
> +  HelpText<"Do not discard value names in LLVM IR">,
> Flags<[DriverOption]>;
>  def fdollars_in_identifiers : Flag<["-"], "fdollars-in-identifiers">,
> Group,
>HelpText<"Allow '$' in ident

Re: r324498 - [Driver] Add option to manually control discarding value names in LLVM IR.

[David Blaikie via cfe-commits]

Ah.. hrm :/

On Mon, Feb 12, 2018 at 6:03 PM Eric Fiselier  wrote:

> On Mon, Feb 12, 2018 at 4:01 PM, David Blaikie  wrote:
>
>> ah, sweet :)
>>
>> On Mon, Feb 12, 2018 at 2:59 PM Eric Fiselier  wrote:
>>
>>> On Mon, Feb 12, 2018 at 3:35 PM, David Blaikie 
>>> wrote:
>>>


 On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier  wrote:

> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie 
> wrote:
>
>>
>>
>> On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ericwf
>>> Date: Wed Feb  7 10:36:51 2018
>>> New Revision: 324498
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
>>> Log:
>>> [Driver] Add option to manually control discarding value names in
>>> LLVM IR.
>>>
>>> Summary:
>>> Currently, assertion-disabled Clang builds emit value names when
>>> generating LLVM IR. This is controlled by the `NDEBUG` macro, and is not
>>> easily overridable. In order to get IR output containing names from a
>>> release build of Clang, the user must manually construct the CC1 
>>> invocation
>>> w/o the `-discard-value-names` option. This is less than ideal.
>>>
>>> For example, Godbolt uses a release build of Clang, and so when
>>> asked to emit LLVM IR the result lacks names, making it harder to read.
>>> Manually invoking CC1 on Compiler Explorer is not feasible.
>>>
>>
>> It wouldn't necessarily have to invoke CC1, it could use "-Xclang
>> -discard-value-names".
>>
>
> If you were using an assertion build, and wanted to disable value
> names, then yes -- that would work. However it's the opposite case that is
> of interest:
> When you're using a non-assertion build and want to keep value names.
> In that case invoking CC1 directly is required; otherwise the driver would
> pass
> "-discard-value-names".
>

 Ah, thanks for explaining!


>
>
>>
>>
>>>
>>> This patch adds the driver options `-fdiscard-value-names` and
>>> `-fno-discard-value-names` which allow the user to override the default
>>> behavior. If neither is specified, the old behavior remains.
>>>
>>> Reviewers: erichkeane, aaron.ballman, lebedev.ri
>>>
>>> Reviewed By: aaron.ballman
>>>
>>> Subscribers: bogner, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D42887
>>>
>>> Modified:
>>> cfe/trunk/docs/UsersManual.rst
>>> cfe/trunk/include/clang/Driver/Options.td
>>> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>>> cfe/trunk/test/Driver/clang_f_opts.c
>>>
>>> Modified: cfe/trunk/docs/UsersManual.rst
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/docs/UsersManual.rst (original)
>>> +++ cfe/trunk/docs/UsersManual.rst Wed Feb  7 10:36:51 2018
>>> @@ -1855,6 +1855,27 @@ features. You can "tune" the debug info
>>>must come first.)
>>>
>>>
>>> +Controlling LLVM IR Output
>>> +--
>>> +
>>> +Controlling Value Names in LLVM IR
>>> +^^
>>> +
>>> +Emitting value names in LLVM IR increases the size and verbosity of
>>> the IR.
>>> +By default, value names are only emitted in assertion-enabled
>>> builds of Clang.
>>> +However, when reading IR it can be useful to re-enable the emission
>>> of value
>>> +names to improve readability.
>>> +
>>> +.. option:: -fdiscard-value-names
>>> +
>>> +  Discard value names when generating LLVM IR.
>>> +
>>> +.. option:: -fno-discard-value-names
>>> +
>>> +  Do not discard value names when generating LLVM IR. This option
>>> can be used
>>> +  to re-enable names for release builds of Clang.
>>> +
>>> +
>>>  Comment Parsing Options
>>>  ---
>>>
>>>
>>> Modified: cfe/trunk/include/clang/Driver/Options.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=324498&r1=324497&r2=324498&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Driver/Options.td (original)
>>> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb  7 10:36:51
>>> 2018
>>> @@ -790,6 +790,10 @@ def fdiagnostics_show_template_tree : Fl
>>>  HelpText<"Print a template comparison tree for differing
>>> templates">;
>>>  def fdeclspec : Flag<["-"], "fdeclspec">, Group,
>>>HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
>>> +def fdiscard_value_names : Flag<["-"], "fdiscard-v

Re: [PATCH] D43259: Implement function attribute artificial

[David Blaikie via cfe-commits]

Maybe - though that'd actually make for larger debug info & not be much
use.

With nodebug+always_inline (which is how the intrinsics are provided) the
function call dissolves into the raw instruction it's meant to represent.
The debug info describes that instruction as if it had been written at the
point of the call.

With this artificial+always_inline a description of inlining would be
provided (DWARF's inlining description is a bit heavy/verbose) & the
debugger would step over it, rather than into it.

For longer functions (inlined or outlined), marking as artificial makes
sense, I think, but /probably/ not for those places already using
nodebug+always_inline.

On Tue, Feb 13, 2018 at 3:18 PM Reid Kleckner via Phabricator <
revi...@reviews.llvm.org> wrote:

> rnk accepted this revision.
> rnk added subscribers: probinson, aprantl, dblaikie.
> rnk added a comment.
> This revision is now accepted and ready to land.
>
> lgtm
>
> ---
>
> Clang's builtin headers use `__attribute__((__nodebug__))` for this
> purpose. Do you think we should follow this up by using artificial instead?
> It seems like it would be a representational improvement. @aprantl
> @probinson @dblaikie
>
>
>
> 
> Comment at: test/Sema/artificial.c:3
> +
> +void __attribute__((artificial)) bar() {} // expected-warning
> {{'artificial' attribute only applies to inline functions}}
> 
> I think it's worth adding the `foo` function from the CodeGen test here to
> show we don't generate warnings when the function is inline specified.
>
>
> https://reviews.llvm.org/D43259
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r325594 - PR36442: Correct description of -fsplit-dwarf-inlining

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Feb 20 08:35:08 2018
New Revision: 325594

URL: http://llvm.org/viewvc/llvm-project?rev=325594&view=rev
Log:
PR36442: Correct description of -fsplit-dwarf-inlining

Modified:
cfe/trunk/include/clang/Driver/Options.td

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=325594&r1=325593&r2=325594&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Feb 20 08:35:08 2018
@@ -1631,7 +1631,7 @@ def fdebug_types_section: Flag <["-"], "
 def fno_debug_types_section: Flag<["-"], "fno-debug-types-section">, 
Group,
   Flags<[CC1Option]>;
 def fsplit_dwarf_inlining: Flag <["-"], "fsplit-dwarf-inlining">, 
Group,
-  Flags<[CC1Option]>, HelpText<"Place debug types in their own section (ELF 
Only)">;
+  Flags<[CC1Option]>, HelpText<"Provide gmlt-like debug info in the 
object/executable to facilitate online symbolication/stack traces in the 
absence of .dwo/.dwp files when using Split DWARF">;
 def fno_split_dwarf_inlining: Flag<["-"], "fno-split-dwarf-inlining">, 
Group,
   Flags<[CC1Option]>;
 def fdebug_prefix_map_EQ


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

r325692 - Remove use of the 'gmlt' term from the -fsplit-dwarf-inlining flag description to make it more readily legible

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Wed Feb 21 08:00:50 2018
New Revision: 325692

URL: http://llvm.org/viewvc/llvm-project?rev=325692&view=rev
Log:
Remove use of the 'gmlt' term from the -fsplit-dwarf-inlining flag description 
to make it more readily legible

Modified:
cfe/trunk/include/clang/Driver/Options.td

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=325692&r1=325691&r2=325692&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed Feb 21 08:00:50 2018
@@ -1631,7 +1631,7 @@ def fdebug_types_section: Flag <["-"], "
 def fno_debug_types_section: Flag<["-"], "fno-debug-types-section">, 
Group,
   Flags<[CC1Option]>;
 def fsplit_dwarf_inlining: Flag <["-"], "fsplit-dwarf-inlining">, 
Group,
-  Flags<[CC1Option]>, HelpText<"Provide gmlt-like debug info in the 
object/executable to facilitate online symbolication/stack traces in the 
absence of .dwo/.dwp files when using Split DWARF">;
+  Flags<[CC1Option]>, HelpText<"Provide minimal debug info in the 
object/executable to facilitate online symbolication/stack traces in the 
absence of .dwo/.dwp files when using Split DWARF">;
 def fno_split_dwarf_inlining: Flag<["-"], "fno-split-dwarf-inlining">, 
Group,
   Flags<[CC1Option]>;
 def fdebug_prefix_map_EQ


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

Re: r304127 - IRGen: Add optnone attribute on function during O0

[David Blaikie via cfe-commits]

I'm assuming  most of these tests aren't actually testing for attributes -
perhaps it'd be better to remove their dependence on a particular attribute
list number so future changes to attributes don't require so many touches?

On Sun, May 28, 2017 at 10:38 PM Mehdi Amini via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: mehdi_amini
> Date: Mon May 29 00:38:20 2017
> New Revision: 304127
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304127&view=rev
> Log:
> IRGen: Add optnone attribute on function during O0
>
> Amongst other, this will help LTO to correctly handle/honor files
> compiled with O0, helping debugging failures.
> It also seems in line with how we handle other options, like how
> -fnoinline adds the appropriate attribute as well.
>
> Differential Revision: https://reviews.llvm.org/D28404
>
> Modified:
> cfe/trunk/include/clang/Driver/CC1Options.td
> cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/test/CodeGen/aarch64-neon-2velem.c
> cfe/trunk/test/CodeGen/aarch64-neon-3v.c
> cfe/trunk/test/CodeGen/aarch64-neon-across.c
> cfe/trunk/test/CodeGen/aarch64-neon-extract.c
> cfe/trunk/test/CodeGen/aarch64-neon-fcvt-intrinsics.c
> cfe/trunk/test/CodeGen/aarch64-neon-fma.c
> cfe/trunk/test/CodeGen/aarch64-neon-intrinsics.c
> cfe/trunk/test/CodeGen/aarch64-neon-ldst-one.c
> cfe/trunk/test/CodeGen/aarch64-neon-misc.c
> cfe/trunk/test/CodeGen/aarch64-neon-perm.c
> cfe/trunk/test/CodeGen/aarch64-neon-scalar-copy.c
> cfe/trunk/test/CodeGen/aarch64-neon-scalar-x-indexed-elem.c
> cfe/trunk/test/CodeGen/aarch64-neon-shifts.c
> cfe/trunk/test/CodeGen/aarch64-neon-tbl.c
> cfe/trunk/test/CodeGen/aarch64-neon-vcombine.c
> cfe/trunk/test/CodeGen/aarch64-neon-vget-hilo.c
> cfe/trunk/test/CodeGen/aarch64-neon-vget.c
> cfe/trunk/test/CodeGen/aarch64-poly128.c
> cfe/trunk/test/CodeGen/aarch64-poly64.c
> cfe/trunk/test/CodeGen/address-safety-attr-kasan.cpp
> cfe/trunk/test/CodeGen/address-safety-attr.cpp
> cfe/trunk/test/CodeGen/arm-crc32.c
> cfe/trunk/test/CodeGen/arm-neon-directed-rounding.c
> cfe/trunk/test/CodeGen/arm-neon-fma.c
> cfe/trunk/test/CodeGen/arm-neon-numeric-maxmin.c
> cfe/trunk/test/CodeGen/arm-neon-shifts.c
> cfe/trunk/test/CodeGen/arm-neon-vcvtX.c
> cfe/trunk/test/CodeGen/arm-neon-vget.c
> cfe/trunk/test/CodeGen/arm64-crc32.c
> cfe/trunk/test/CodeGen/arm64-lanes.c
> cfe/trunk/test/CodeGen/arm64_vcopy.c
> cfe/trunk/test/CodeGen/arm64_vdupq_n_f64.c
> cfe/trunk/test/CodeGen/attr-coldhot.c
> cfe/trunk/test/CodeGen/attr-naked.c
> cfe/trunk/test/CodeGen/builtins-arm-exclusive.c
> cfe/trunk/test/CodeGen/builtins-arm.c
> cfe/trunk/test/CodeGen/builtins-arm64.c
> cfe/trunk/test/CodeGen/noduplicate-cxx11-test.cpp
> cfe/trunk/test/CodeGen/pragma-weak.c
> cfe/trunk/test/CodeGen/unwind-attr.c
> cfe/trunk/test/CodeGenCXX/apple-kext-indirect-virtual-dtor-call.cpp
> cfe/trunk/test/CodeGenCXX/apple-kext-no-staticinit-section.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
> cfe/trunk/test/CodeGenCXX/optnone-templates.cpp
> cfe/trunk/test/CodeGenCXX/static-init-wasm.cpp
> cfe/trunk/test/CodeGenCXX/thunks.cpp
> cfe/trunk/test/CodeGenObjC/gnu-exceptions.m
> cfe/trunk/test/CodeGenOpenCL/amdgpu-attrs.cl
> cfe/trunk/test/Driver/darwin-iphone-defaults.m
>
> Modified: cfe/trunk/include/clang/Driver/CC1Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=304127&r1=304126&r2=304127&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/CC1Options.td (original)
> +++ cfe/trunk/include/clang/Driver/CC1Options.td Mon May 29 00:38:20 2017
> @@ -172,6 +172,8 @@ def disable_llvm_optzns : Flag<["-"], "d
>  def disable_lifetimemarkers : Flag<["-"], "disable-lifetime-markers">,
>HelpText<"Disable lifetime-markers emission even when optimizations are
> "
> "enabled">;
> +def disable_O0_optnone : Flag<["-"], "disable-O0-optnone">,
> +  HelpText<"Disable adding the optnone attribute to functions at O0">;
>  def disable_red_zone : Flag<["-"], "disable-red-zone">,
>HelpText<"Do not emit code that uses the red zone.">;
>  def dwarf_column_info : Flag<["-"], "dwarf-column-info">,
>
> Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=304127&r1=304126&r2=304127&view=diff
>
> ==
> --- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
> +++ cfe/trunk/include/clang/

Re: r303934 - "*" => "+" to avoid matching on empty string.

[David Blaikie via cfe-commits]

Why would matching on an empty string be bad in this case?

On Thu, May 25, 2017 at 4:25 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rtrieu
> Date: Thu May 25 18:25:36 2017
> New Revision: 303934
>
> URL: http://llvm.org/viewvc/llvm-project?rev=303934&view=rev
> Log:
> "*" => "+" to avoid matching on empty string.
>
> Modified:
> cfe/trunk/test/Driver/baremetal.cpp
>
> Modified: cfe/trunk/test/Driver/baremetal.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/baremetal.cpp?rev=303934&r1=303933&r2=303934&view=diff
>
> ==
> --- cfe/trunk/test/Driver/baremetal.cpp (original)
> +++ cfe/trunk/test/Driver/baremetal.cpp Thu May 25 18:25:36 2017
> @@ -4,7 +4,7 @@
>  // RUN: -L some/directory/user/asked/for \
>  // RUN: --sysroot=%S/Inputs/baremetal_arm \
>  // RUN:   | FileCheck --check-prefix=CHECK-V6M-C %s
> -// CHECK-V6M-C:
> "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]*}}{{[/\\]+}}clang{{.*}}" "-cc1"
> "-triple" "thumbv6m-none--eabi"
> +// CHECK-V6M-C:
> "[[PREFIX_DIR:.*]]{{[/\\]+}}{{[^/^\\]+}}{{[/\\]+}}clang{{.*}}" "-cc1"
> "-triple" "thumbv6m-none--eabi"
>  // CHECK-V6M-C-SAME: "-resource-dir"
> "[[PREFIX_DIR]]{{[/\\]+}}lib{{[/\\]+}}clang{{[/\\]+}}[[VERSION:[^"]*]]"
>  // CHECK-V6M-C-SAME: "-isysroot" "[[SYSROOT:[^"]*]]"
>  // CHECK-V6M-C-SAME: "-internal-isystem"
> "[[SYSROOT]]{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r303714 - [coroutines] Fix leak in CGCoroutine.cpp

[David Blaikie via cfe-commits]

Could you avoid creating the FinalBB unless it's needed rather than
creating it and then adding it so it can be removed? (or, if the creation
can't be avoided, maybe it's OK to 'delete FinalBB' here, rather than
adding it for it to be removed later?)

(also bracing seems off - could you run your changes through clang-format?
I'd expect '} else {' on the same line.

On Tue, May 23, 2017 at 6:54 PM Gor Nishanov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: gornishanov
> Date: Tue May 23 20:54:37 2017
> New Revision: 303714
>
> URL: http://llvm.org/viewvc/llvm-project?rev=303714&view=rev
> Log:
> [coroutines] Fix leak in CGCoroutine.cpp
>
> FinalBB need to be emitted even when unused to make sure it is deleted
>
> Modified:
> cfe/trunk/lib/CodeGen/CGCoroutine.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGCoroutine.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCoroutine.cpp?rev=303714&r1=303713&r2=303714&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGCoroutine.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGCoroutine.cpp Tue May 23 20:54:37 2017
> @@ -430,6 +430,10 @@ void CodeGenFunction::EmitCoroutineBody(
>CurCoro.Data->CurrentAwaitKind = AwaitKind::Final;
>EmitStmt(S.getFinalSuspendStmt());
>  }
> +else {
> +  // We don't need FinalBB. Emit it to make sure the block is deleted.
> +  EmitBlock(FinalBB, /*IsFinished=*/true);
> +}
>}
>
>EmitBlock(RetBB);
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r303714 - [coroutines] Fix leak in CGCoroutine.cpp

[David Blaikie via cfe-commits]

On Mon, May 29, 2017 at 2:12 PM Gor Nishanov  wrote:

> It is not known in advance whether the final block is needed or not. It
> will become known once the user-authored body of the coroutine is emitted.
> I cannot defer creation of it up until that point, since final bb acts as a
> jump target for co_returns which could be in the user authored body and I
> need it to set up a jump destination beforehand.
>

Not sure I follow - presumably those jumps could only be emitted if the
block would be emitted - so if the entity is created the first time it's
needed as a jump destination,then that should be OK?


>
> Ack on formatting change.
>
> On Mon, May 29, 2017 at 12:11 PM, David Blaikie 
> wrote:
>
>> Could you avoid creating the FinalBB unless it's needed rather than
>> creating it and then adding it so it can be removed? (or, if the creation
>> can't be avoided, maybe it's OK to 'delete FinalBB' here, rather than
>> adding it for it to be removed later?)
>>
>> (also bracing seems off - could you run your changes through
>> clang-format? I'd expect '} else {' on the same line.
>>
>> On Tue, May 23, 2017 at 6:54 PM Gor Nishanov via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: gornishanov
>>> Date: Tue May 23 20:54:37 2017
>>> New Revision: 303714
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=303714&view=rev
>>> Log:
>>> [coroutines] Fix leak in CGCoroutine.cpp
>>>
>>> FinalBB need to be emitted even when unused to make sure it is deleted
>>>
>>> Modified:
>>> cfe/trunk/lib/CodeGen/CGCoroutine.cpp
>>>
>>> Modified: cfe/trunk/lib/CodeGen/CGCoroutine.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCoroutine.cpp?rev=303714&r1=303713&r2=303714&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/CodeGen/CGCoroutine.cpp (original)
>>> +++ cfe/trunk/lib/CodeGen/CGCoroutine.cpp Tue May 23 20:54:37 2017
>>> @@ -430,6 +430,10 @@ void CodeGenFunction::EmitCoroutineBody(
>>>CurCoro.Data->CurrentAwaitKind = AwaitKind::Final;
>>>EmitStmt(S.getFinalSuspendStmt());
>>>  }
>>> +else {
>>> +  // We don't need FinalBB. Emit it to make sure the block is
>>> deleted.
>>> +  EmitBlock(FinalBB, /*IsFinished=*/true);
>>> +}
>>>}
>>>
>>>EmitBlock(RetBB);
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r303714 - [coroutines] Fix leak in CGCoroutine.cpp

[David Blaikie via cfe-commits]

Fair enough. I don't have all the context there either.

Perhaps Richard Smith could sanity check what the right memory management
scheme is here.

On Mon, May 29, 2017 at 3:54 PM Gor Nishanov  wrote:

> My clang-foo is not strong enough :) .
>
> I wanted to make sure that: "CurCoro.Data->FinalJD =
> getJumpDestInCurrentScope(FinalBB);" is in the correct scope where I want
> it. As opposed to creating it in whatever scope co_return statement is
> encountered. But that could be simply my misundersanding of the
> frontend/scopes/etc and it is quite possible that the code can be
> refactored along the lines you are thinking about.
>
> On Mon, May 29, 2017 at 3:44 PM, David Blaikie  wrote:
>
>>
>>
>> On Mon, May 29, 2017 at 2:12 PM Gor Nishanov 
>> wrote:
>>
>>> It is not known in advance whether the final block is needed or not. It
>>> will become known once the user-authored body of the coroutine is emitted.
>>> I cannot defer creation of it up until that point, since final bb acts as a
>>> jump target for co_returns which could be in the user authored body and I
>>> need it to set up a jump destination beforehand.
>>>
>>
>> Not sure I follow - presumably those jumps could only be emitted if the
>> block would be emitted - so if the entity is created the first time it's
>> needed as a jump destination,then that should be OK?
>>
>>
>>>
>>> Ack on formatting change.
>>>
>>> On Mon, May 29, 2017 at 12:11 PM, David Blaikie 
>>> wrote:
>>>
 Could you avoid creating the FinalBB unless it's needed rather than
 creating it and then adding it so it can be removed? (or, if the creation
 can't be avoided, maybe it's OK to 'delete FinalBB' here, rather than
 adding it for it to be removed later?)

 (also bracing seems off - could you run your changes through
 clang-format? I'd expect '} else {' on the same line.

 On Tue, May 23, 2017 at 6:54 PM Gor Nishanov via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: gornishanov
> Date: Tue May 23 20:54:37 2017
> New Revision: 303714
>
> URL: http://llvm.org/viewvc/llvm-project?rev=303714&view=rev
> Log:
> [coroutines] Fix leak in CGCoroutine.cpp
>
> FinalBB need to be emitted even when unused to make sure it is deleted
>
> Modified:
> cfe/trunk/lib/CodeGen/CGCoroutine.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGCoroutine.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCoroutine.cpp?rev=303714&r1=303713&r2=303714&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGCoroutine.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGCoroutine.cpp Tue May 23 20:54:37 2017
> @@ -430,6 +430,10 @@ void CodeGenFunction::EmitCoroutineBody(
>CurCoro.Data->CurrentAwaitKind = AwaitKind::Final;
>EmitStmt(S.getFinalSuspendStmt());
>  }
> +else {
> +  // We don't need FinalBB. Emit it to make sure the block is
> deleted.
> +  EmitBlock(FinalBB, /*IsFinished=*/true);
> +}
>}
>
>EmitBlock(RetBB);
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>

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

Re: [PATCH] D33705: [CGVTables] Finalize SP before attempting to clone it

[David Blaikie via cfe-commits]

If SPs are now all finalized early - I'm assuming there's some other code
that finalizes SPs that's no longer needed?

Also - this seems like a layering/separation issue - does other code call
into the DI as casually/explicitly as this code being added to CGVTables?
(Or should the callback go through some more generic entry point in
CGDebugInfo to delegate/handle that?) & is there nothing in CGDebugInfo
that is already called back in a timely fashion to handle this? I'm
guessing what's needed is a "IR has finished being generated for this
function, opt/codegen is about to start"? That seems like a good generic
callback & probably shouldn't be coming from something called CGVTables?
(presuming there's a more general place to put that)

On Tue, May 30, 2017 at 5:30 PM Keno Fischer via Phabricator <
revi...@reviews.llvm.org> wrote:

> loladiro created this revision.
>
> LLVM commit https://reviews.llvm.org/D33655 was reverted, because it
> exposed an assertion failure,
> in `GenerateVarArgsThunk`. That function attempts to clone a function
> before clang is entirely done generating the debug info for the current
> compliation unit. That is not a valid use of the API, because it expects
> that there are no temporary MD nodes in the nodes that it needs to clone.
> However, until now, this did not cause any problems (though could have
> caused assertions in the backend due to mismatched debug info metadata).
>
> Attempt to rectify this by finalizing the SP before attempting to clone it.
> The requisite LLVM API is being introduced in
> https://reviews.llvm.org/D33704.
>
>
> https://reviews.llvm.org/D33705
>
> Files:
>   lib/CodeGen/CGDebugInfo.h
>   lib/CodeGen/CGVTables.cpp
>
>
> Index: lib/CodeGen/CGVTables.cpp
> ===
> --- lib/CodeGen/CGVTables.cpp
> +++ lib/CodeGen/CGVTables.cpp
> @@ -152,6 +152,12 @@
>llvm::Value *Callee = CGM.GetAddrOfFunction(GD, Ty, /*ForVTable=*/true);
>llvm::Function *BaseFn = cast(Callee);
>
> +  // We may not clone a subprogram that contains temporary metadata, so
> finalize
> +  // it now - we will not be modifying it.
> +  if (CGDebugInfo *DI = CGM.getModuleDebugInfo())
> +if (llvm::DISubprogram *SP = BaseFn->getSubprogram())
> +  DI->finalizeSP(SP);
> +
>// Clone to thunk.
>llvm::ValueToValueMapTy VMap;
>llvm::Function *NewFn = llvm::CloneFunction(BaseFn, VMap);
> Index: lib/CodeGen/CGDebugInfo.h
> ===
> --- lib/CodeGen/CGDebugInfo.h
> +++ lib/CodeGen/CGDebugInfo.h
> @@ -308,6 +308,7 @@
>~CGDebugInfo();
>
>void finalize();
> +  void finalizeSP(llvm::DISubprogram *SP) { DBuilder.finalizeSP(SP); }
>
>/// Module debugging: Support for building PCMs.
>/// @{
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33705: [CGVTables] Finalize SP before attempting to clone it

[David Blaikie via cfe-commits]

I'll let Adrian weigh in - but I suspect, if possible, it'd be better to
just finalize them all once IRGen for the function finishes.
On Tue, May 30, 2017 at 6:02 PM Keno Fischer 
wrote:

> For some reason your comments aren't showing up on Phabricator, so
> replying via email - hope everybody sees it.
>
> If SPs are now all finalized early - I'm assuming there's some other code
>> that finalizes SPs that's no longer needed?
>>
>
> Not all of them, just the one before cloning. I wanted to make the minimal
> change possible here, since this already seems like a bit of a hack to work
> around the fact that we can't properly forward variadic function calls at
> the IR level.
>
>
>> Also - this seems like a layering/separation issue - does other code call
>> into the DI as casually/explicitly as this code being added to CGVTables?
>> (Or should the callback go through some more generic entry point in
>> CGDebugInfo to delegate/handle that?) & is there nothing in CGDebugInfo
>> that is already called back in a timely fashion to handle this? I'm
>> guessing what's needed is a "IR has finished being generated for this
>> function, opt/codegen is about to start"? That seems like a good generic
>> callback & probably shouldn't be coming from something called CGVTables?
>> (presuming there's a more general place to put that)
>>
>
> I suppose there's CGDebugInfo::EmitFunctionEnd, so if we did want to
> finalize every SP as soon as we're done with it, we could put an explicit
> call to that extent there. Frankly though I don't really know the clang
> code too well, I just want to unbreak LLVM ;).
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r304456 - Add compatibility alias for -Wno-#warnings

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Jun  1 14:08:34 2017
New Revision: 304456

URL: http://llvm.org/viewvc/llvm-project?rev=304456&view=rev
Log:
Add compatibility alias for -Wno-#warnings

GCC uses -Wno-cpp for this, so seems reasonable to add an alias to
match.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/test/Misc/diag-mapping2.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=304456&r1=304455&r2=304456&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Thu Jun  1 14:08:34 2017
@@ -733,6 +733,7 @@ def Pedantic : DiagGroup<"pedantic">;
 // Aliases.
 def : DiagGroup<"", [Extra]>;   // -W = -Wextra
 def : DiagGroup<"endif-labels", [ExtraTokens]>; // 
-Wendif-labels=-Wextra-tokens
+def : DiagGroup<"cpp", [PoundWarning]>; // -Wcpp = -W#warnings
 def : DiagGroup<"comments", [Comment]>; // -Wcomments = -Wcomment
 def : DiagGroup<"conversion-null",
 [NullConversion]>; // -Wconversion-null = -Wnull-conversion

Modified: cfe/trunk/test/Misc/diag-mapping2.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/diag-mapping2.c?rev=304456&r1=304455&r2=304456&view=diff
==
--- cfe/trunk/test/Misc/diag-mapping2.c (original)
+++ cfe/trunk/test/Misc/diag-mapping2.c Thu Jun  1 14:08:34 2017
@@ -4,6 +4,7 @@
 // This should not emit anything.
 // RUN: %clang_cc1 %s -w 2>&1 | not grep diagnostic
 // RUN: %clang_cc1 %s -Wno-#warnings 2>&1 | not grep diagnostic
+// RUN: %clang_cc1 %s -Wno-cpp 2>&1 | not grep diagnostic
 
 // -Werror can map all warnings to error.
 // RUN: not %clang_cc1 %s -Werror 2>&1 | grep "error: foo"


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

Re: [PATCH] D33660: [coroutines] Fix assertion during -Wuninitialized analysis

[David Blaikie via cfe-commits]

On Mon, May 29, 2017 at 3:28 PM Eric Fiselier via Phabricator via
cfe-commits  wrote:

> EricWF created this revision.
>
> @rsmith Is there a better place to put this test?
>
>
> https://reviews.llvm.org/D33660
>
> Files:
>   lib/Sema/SemaCoroutine.cpp
>   test/SemaCXX/coreturn.cpp
>   test/SemaCXX/coroutine-uninitialized-warning-crash.cpp
>
>
> Index: test/SemaCXX/coroutine-uninitialized-warning-crash.cpp
> ===
> --- /dev/null
> +++ test/SemaCXX/coroutine-uninitialized-warning-crash.cpp
> @@ -0,0 +1,44 @@
> +// RUN: %clang_cc1 -triple x86_64-apple-darwin9 %s -std=c++14
> -fcoroutines-ts -fsyntax-only -Wall -Wextra -Wuninitialized  -fblocks
>

A test case that tests only "this doesn't crash" is usually a bit of a hint
to me, at least, that something's under-tested. I assume there's some
specific behavior that's desired more than "does anything other than
crashing" that should be being tested for here?


> +#include "Inputs/std-coroutine.h"
> +
> +using namespace std::experimental;
> +
> +
> +struct A {
> +  bool await_ready() { return true; }
> +  int await_resume() { return 42; }
> +  template 
> +  void await_suspend(F) {}
> +};
> +
> +
> +struct coro_t {
> +  struct promise_type {
> +coro_t get_return_object() { return {}; }
> +suspend_never initial_suspend() { return {}; }
> +suspend_never final_suspend() { return {}; }
> +A yield_value(int) { return {}; }
> +void return_void() {}
> +static void unhandled_exception() {}
> +  };
> +};
> +
> +coro_t f(int n) {
> +  if (n == 0)
> +co_return;
> +  co_yield 42;
> +  int x = co_await A{};
> +}
> +
> +template 
> +coro_t g(int n) {
> +  if (n == 0)
> +co_return;
> +  co_yield 42;
> +  int x = co_await Await{};
> +}
> +
> +int main() {
> +  f(0);
> +  g(0);
> +}
> Index: test/SemaCXX/coreturn.cpp
> ===
> --- test/SemaCXX/coreturn.cpp
> +++ test/SemaCXX/coreturn.cpp
> @@ -1,4 +1,4 @@
> -// RUN: %clang_cc1 -triple x86_64-apple-darwin9 %s -std=c++14
> -fcoroutines-ts -fsyntax-only -Wignored-qualifiers -Wno-error=return-type
> -verify -fblocks -Wno-unreachable-code -Wno-unused-value
> +// RUN: %clang_cc1 -triple x86_64-apple-darwin9 %s -std=c++14
> -fcoroutines-ts -fsyntax-only -Wignored-qualifiers -Wno-error=return-type
> -verify -fblocks -Wall -Wextra -Wno-error=unreachable-code
>  #include "Inputs/std-coroutine.h"
>
>  using std::experimental::suspend_always;
> Index: lib/Sema/SemaCoroutine.cpp
> ===
> --- lib/Sema/SemaCoroutine.cpp
> +++ lib/Sema/SemaCoroutine.cpp
> @@ -437,6 +437,7 @@
>if (VD->isInvalidDecl())
>  return nullptr;
>ActOnUninitializedDecl(VD);
> +  FD->addDecl(VD);
>assert(!VD->isInvalidDecl());
>return VD;
>  }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r304190 - Diagnose attempts to build a preprocessed module that defines an unavailable submodule.

[David Blaikie via cfe-commits]

On Mon, May 29, 2017 at 10:23 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue May 30 00:22:59 2017
> New Revision: 304190
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304190&view=rev
> Log:
> Diagnose attempts to build a preprocessed module that defines an
> unavailable submodule.
>
> The errors we would otherwise get are incomprehensible, as we would enter
> the
> module but not make its contents visible to itself.
>
> Added:
> cfe/trunk/test/Modules/preprocess-unavailable.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
> cfe/trunk/lib/Lex/Pragma.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=304190&r1=304189&r2=304190&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Tue May 30
> 00:22:59 2017
> @@ -525,6 +525,8 @@ def err_pp_module_begin_without_module_e
>  def err_pp_module_end_without_module_begin : Error<
>"no matching '#pragma clang module begin' for this "
>"'#pragma clang module end'">;
> +def note_pp_module_begin_here : Note<
> +  "entering module '%0' due to this pragma">;
>
>  def err_defined_macro_name : Error<"'defined' cannot be used as a macro
> name">;
>  def err_paste_at_start : Error<
>
> Modified: cfe/trunk/lib/Lex/Pragma.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=304190&r1=304189&r2=304190&view=diff
>
> ==
> --- cfe/trunk/lib/Lex/Pragma.cpp (original)
> +++ cfe/trunk/lib/Lex/Pragma.cpp Tue May 30 00:22:59 2017
> @@ -1407,6 +1407,24 @@ struct PragmaModuleBeginHandler : public
>M = NewM;
>  }
>
> +// If the module isn't available, it doesn't make sense to enter it.
> +if (!M->isAvailable()) {
> +  Module::Requirement Requirement;
> +  Module::UnresolvedHeaderDirective MissingHeader;
> +  (void)M->isAvailable(PP.getLangOpts(), PP.getTargetInfo(),
> +   Requirement, MissingHeader);
>

This looks a tad weird ^ should this function have a different name (or a
version of the function that only does the side-effecting work that I'm
guessing is desired here)?


> +  if (MissingHeader.FileNameLoc.isValid()) {
> +PP.Diag(MissingHeader.FileNameLoc,
> diag::err_module_header_missing)
> +  << MissingHeader.IsUmbrella << MissingHeader.FileName;
> +  } else {
> +PP.Diag(M->DefinitionLoc, diag::err_module_unavailable)
> +  << M->getFullModuleName() << Requirement.second <<
> Requirement.first;
> +  }
> +  PP.Diag(BeginLoc, diag::note_pp_module_begin_here)
> +<< M->getTopLevelModuleName();
> +  return;
> +}
> +
>  // Enter the scope of the submodule.
>  PP.EnterSubmodule(M, BeginLoc, /*ForPragma*/true);
>  PP.EnterAnnotationToken(SourceRange(BeginLoc,
> ModuleName.back().second),
>
> Added: cfe/trunk/test/Modules/preprocess-unavailable.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/preprocess-unavailable.cpp?rev=304190&view=auto
>
> ==
> --- cfe/trunk/test/Modules/preprocess-unavailable.cpp (added)
> +++ cfe/trunk/test/Modules/preprocess-unavailable.cpp Tue May 30 00:22:59
> 2017
> @@ -0,0 +1,12 @@
> +// RUN: %clang_cc1 -x c++-module-map %s -fmodule-name=a -verify
> +module a {
> +  module b {
> +requires cplusplus11
> +  }
> +}
> +#pragma clang module contents
> +// expected-error@3 {{module 'a.b' requires feature 'cplusplus11'}}
> +#pragma clang module begin a.b // expected-note {{entering module 'a' due
> to this pragma}}
> +int f();
> +int g() { f(); }
> +#pragma clang module end // expected-error {{no matching '#pragma clang
> module begin'}}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33708: [test] [libcxx] Disable MSVC++'s compare(a, b) implies !compare(b, a) assertion in predicate application count tests

[David Blaikie via cfe-commits]

Alternatively, you could disable the check (or change the count it checks)
if this is defined. (& if you disable the check when this is defined, you
could change an existing build/test config (or add a new one) to have this
disabled)

On Tue, May 30, 2017 at 8:19 PM Billy Robert O'Neal III via Phabricator via
cfe-commits  wrote:

> BillyONeal abandoned this revision.
> BillyONeal added a comment.
>
> Stephan pointed out that the force include breaks this. Backing it out for
> now :(
>
>
> https://reviews.llvm.org/D33708
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33750: CGCleanup: (NFC) add a test that used to trigger broken IR

[David Blaikie via cfe-commits]

On Wed, May 31, 2017 at 5:45 PM Gor Nishanov via Phabricator via
cfe-commits  wrote:

> GorNishanov created this revision.
>
> Coroutine related test that used to trigger broken IR prior to r304335.
>
>
> https://reviews.llvm.org/D33750
>
> Files:
>   test/CodeGenCoroutines/coro-await-domination.cpp
>
>
> Index: test/CodeGenCoroutines/coro-await-domination.cpp
> ===
> --- /dev/null
> +++ test/CodeGenCoroutines/coro-await-domination.cpp
> @@ -0,0 +1,38 @@
> +// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fcoroutines-ts
> -std=c++14 -emit-llvm %s -o - | FileCheck %s

+#include "Inputs/coroutine.h"
> +
> +using namespace std::experimental;
> +
> +struct coro {
> +  struct promise_type {
> +coro get_return_object();
> +suspend_never initial_suspend();
> +suspend_never final_suspend();
> +void return_void();
> +static void unhandled_exception();
> +  };
> +};
> +
> +struct A {
> +  ~A();
> +  bool await_ready();
> +  int await_resume() { return 8; }
> +  template  void await_suspend(F);
> +};
> +
> +extern "C" void consume(int);
> +
> +// Verifies that domination is properly built during cleanup.
> +// Without CGCleanup.cpp fix verifier was reporting:
> +// Instruction does not dominate all uses!
> +//  %tmp.exprcleanup = alloca i32*, align 8
> +//  store i32* %x, i32** %tmp.exprcleanup, align 8
> +
> +
> +// CHECK-LABEL: f(
>

This doesn't seem to check much. Should this test check that the IR
instructions have the 'good' layout, more than that the verifier doesn't
fail?

Or is that already tested by the test case added in r304335? In that case I
wouldn't add this test. If the change can/is tested in isolation in Clang,
that should be sufficient/tends to be how testing is done in the regression
test suites in the LLVM project. (the test-suite is the place for
broader/end-to-end testing)


> +extern "C" coro f(int) {
> +  int x = 42;
> +  x = co_await A{};
> +  consume(x);
> +}
> +
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33765: Show correct column nr. when multi-byte utf8 chars are used.

[David Blaikie via cfe-commits]

Is it right to only change the behavior of this caller? Presumably other
callers (like getSpellingColumnNumber, getExpansionColumnNumber, etc)
probably want the same handling? Do any callers /not/ want this behavior?

On Thu, Jun 1, 2017 at 3:14 AM Erik Verbruggen via Phabricator via
cfe-commits  wrote:

> erikjv created this revision.
>
> Previously, the column number in a diagnostic would be the byte position
> in the line. This results in incorrect column numbers when a multi-byte
> UTF-8 character would be present in the input. By ignoring all bytes
> starting with 0b10 the correct column number is created.
>
> This fixes PR21144.
>
>
> https://reviews.llvm.org/D33765
>
> Files:
>   include/clang/Basic/SourceManager.h
>   lib/Basic/SourceManager.cpp
>   test/Misc/diag-utf8.cpp
>
>
> Index: test/Misc/diag-utf8.cpp
> ===
> --- /dev/null
> +++ test/Misc/diag-utf8.cpp
> @@ -0,0 +1,11 @@
> +// RUN: not %clang_cc1 -fsyntax-only %s 2>&1 | FileCheck %s
> +
> +struct Foo { int member; };
> +
> +void f(Foo foo)
> +{
> +"ideeen" << foo; // CHECK: {{.*[/\\]}}diag-utf8.cpp:7:14: error:
> invalid operands to binary expression ('const char *' and 'Foo')
> +"ideëen" << foo; // CHECK: {{.*[/\\]}}diag-utf8.cpp:8:14: error:
> invalid operands to binary expression ('const char *' and 'Foo')
> +}
> +
> +
> Index: lib/Basic/SourceManager.cpp
> ===
> --- lib/Basic/SourceManager.cpp
> +++ lib/Basic/SourceManager.cpp
> @@ -1055,11 +1055,22 @@
>return Buffer->getBufferStart() + (CharDataInvalid? 0 : LocInfo.second);
>  }
>
> +static unsigned correctForMultiByteChars(const char *Buf, unsigned
> LineStart,
> + unsigned Column)
> +{
> +unsigned CorrectedColumn = Column;
> +for (unsigned I = 0; I < Column; ++I) {
> +if ((Buf[LineStart + I] & 0xc0) == 0x80)
> +--CorrectedColumn;
> +}
> +return CorrectedColumn;
> +}
>
>  /// getColumnNumber - Return the column # for the specified file position.
>  /// this is significantly cheaper to compute than the line number.
>  unsigned SourceManager::getColumnNumber(FileID FID, unsigned FilePos,
> -bool *Invalid) const {
> +bool *Invalid,
> +bool BytePosition) const {
>bool MyInvalid = false;
>llvm::MemoryBuffer *MemBuf = getBuffer(FID, &MyInvalid);
>if (Invalid)
> @@ -1093,14 +1104,18 @@
>  if (Buf[FilePos - 1] == '\r' || Buf[FilePos - 1] == '\n')
>--FilePos;
>}
> -  return FilePos - LineStart + 1;
> +  unsigned Column = FilePos - LineStart + 1;
> +  return BytePosition ? Column : correctForMultiByteChars(Buf,
> LineStart,
> +  Column);
>  }
>}
>
>unsigned LineStart = FilePos;
>while (LineStart && Buf[LineStart-1] != '\n' && Buf[LineStart-1] !=
> '\r')
>  --LineStart;
> -  return FilePos-LineStart+1;
> +  unsigned Column = FilePos - LineStart + 1;
> +  return BytePosition ? Column : correctForMultiByteChars(Buf, LineStart,
> +  Column);
>  }
>
>  // isInvalid - Return the result of calling loc.isInvalid(), and
> @@ -1425,7 +1440,8 @@
>unsigned LineNo = getLineNumber(LocInfo.first, LocInfo.second,
> &Invalid);
>if (Invalid)
>  return PresumedLoc();
> -  unsigned ColNo  = getColumnNumber(LocInfo.first, LocInfo.second,
> &Invalid);
> +  unsigned ColNo  = getColumnNumber(LocInfo.first, LocInfo.second,
> &Invalid,
> +false);
>if (Invalid)
>  return PresumedLoc();
>
> Index: include/clang/Basic/SourceManager.h
> ===
> --- include/clang/Basic/SourceManager.h
> +++ include/clang/Basic/SourceManager.h
> @@ -1275,7 +1275,8 @@
>/// on a file sloc, so you must choose a spelling or expansion location
>/// before calling this method.
>unsigned getColumnNumber(FileID FID, unsigned FilePos,
> -   bool *Invalid = nullptr) const;
> +   bool *Invalid = nullptr,
> +   bool BytePosition = true) const;
>unsigned getSpellingColumnNumber(SourceLocation Loc,
> bool *Invalid = nullptr) const;
>unsigned getExpansionColumnNumber(SourceLocation Loc,
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r304583 - [clang-tidy] Add `const` to operator() to fix a warning.

[David Blaikie via cfe-commits]

what was the warning?

On Fri, Jun 2, 2017 at 11:48 AM Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: alexfh
> Date: Fri Jun  2 13:47:50 2017
> New Revision: 304583
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304583&view=rev
> Log:
> [clang-tidy] Add `const` to operator() to fix a warning.
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/misc/LambdaFunctionNameCheck.h
>
> Modified: clang-tools-extra/trunk/clang-tidy/misc/LambdaFunctionNameCheck.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/LambdaFunctionNameCheck.h?rev=304583&r1=304582&r2=304583&view=diff
>
> ==
> --- clang-tools-extra/trunk/clang-tidy/misc/LambdaFunctionNameCheck.h
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/misc/LambdaFunctionNameCheck.h Fri
> Jun  2 13:47:50 2017
> @@ -25,7 +25,7 @@ namespace misc {
>  class LambdaFunctionNameCheck : public ClangTidyCheck {
>  public:
>struct SourceRangeLessThan {
> -bool operator()(const SourceRange &L, const SourceRange &R) {
> +bool operator()(const SourceRange &L, const SourceRange &R) const {
>if (L.getBegin() == R.getBegin()) {
>  return L.getEnd() < R.getEnd();
>}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r299921 - [lsan] Enable LSan on arm Linux, clang part

[David Blaikie via cfe-commits]

This change seemed to be buggy (& I assume missing test coverage to
demonstrate that). Galina fixed it in
http://llvm.org/viewvc/llvm-project?rev=304663&view=rev based on a compiler
warning.

Can you add test coverage to this code to exercise these untested codepaths?

On Tue, Apr 11, 2017 at 12:34 AM Maxim Ostapenko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: chefmax
> Date: Tue Apr 11 02:22:11 2017
> New Revision: 299921
>
> URL: http://llvm.org/viewvc/llvm-project?rev=299921&view=rev
> Log:
> [lsan] Enable LSan on arm Linux, clang part
>
> This is a compiler part of https://reviews.llvm.org/D29586. Enable LSan
> on arm Linux.
>
> Differential Revision: https://reviews.llvm.org/D31760
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/Linux.cpp
> cfe/trunk/test/Driver/fsanitize.c
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Linux.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Linux.cpp?rev=299921&r1=299920&r2=299921&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Linux.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Linux.cpp Tue Apr 11 02:22:11 2017
> @@ -864,6 +864,9 @@ SanitizerMask Linux::getSupportedSanitiz
> getTriple().getArch() == llvm::Triple::ppc64le;
>const bool IsAArch64 = getTriple().getArch() == llvm::Triple::aarch64 ||
>   getTriple().getArch() ==
> llvm::Triple::aarch64_be;
> +  const bool IsArmArch = getTriple().getArch() == llvm::Triple::arm ||
> + llvm::Triple::thumb || llvm::Triple::armeb ||
> + llvm::Triple::thumbeb;
>SanitizerMask Res = ToolChain::getSupportedSanitizers();
>Res |= SanitizerKind::Address;
>Res |= SanitizerKind::KernelAddress;
> @@ -871,7 +874,7 @@ SanitizerMask Linux::getSupportedSanitiz
>Res |= SanitizerKind::SafeStack;
>if (IsX86_64 || IsMIPS64 || IsAArch64)
>  Res |= SanitizerKind::DataFlow;
> -  if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86)
> +  if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsArmArch)
>  Res |= SanitizerKind::Leak;
>if (IsX86_64 || IsMIPS64 || IsAArch64 || IsPowerPC64)
>  Res |= SanitizerKind::Thread;
>
> Modified: cfe/trunk/test/Driver/fsanitize.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize.c?rev=299921&r1=299920&r2=299921&view=diff
>
> ==
> --- cfe/trunk/test/Driver/fsanitize.c (original)
> +++ cfe/trunk/test/Driver/fsanitize.c Tue Apr 11 02:22:11 2017
> @@ -237,6 +237,30 @@
>  // RUN: %clang -target i686-linux-gnu -fsanitize=address,leak
> -fno-sanitize=address %s -### 2>&1 | FileCheck %s
> --check-prefix=CHECK-SANA-SANL-NO-SANA-X86
>  // CHECK-SANA-SANL-NO-SANA-X86: "-fsanitize=leak"
>
> +// RUN: %clang -target arm-linux-gnu -fsanitize=leak %s -### 2>&1 |
> FileCheck %s --check-prefix=CHECK-SANL-ARM
> +// CHECK-SANL-ARM: "-fsanitize=leak"
> +
> +// RUN: %clang -target arm-linux-gnu -fsanitize=address,leak
> -fno-sanitize=address %s -### 2>&1 | FileCheck %s
> --check-prefix=CHECK-SANA-SANL-NO-SANA-ARM
> +// CHECK-SANA-SANL-NO-SANA-ARM: "-fsanitize=leak"
> +
> +// RUN: %clang -target thumb-linux -fsanitize=leak %s -### 2>&1 |
> FileCheck %s --check-prefix=CHECK-SANL-THUMB
> +// CHECK-SANL-THUMB: "-fsanitize=leak"
> +
> +// RUN: %clang -target thumb-linux -fsanitize=address,leak
> -fno-sanitize=address %s -### 2>&1 | FileCheck %s
> --check-prefix=CHECK-SANA-SANL-NO-SANA-THUMB
> +// CHECK-SANA-SANL-NO-SANA-THUMB: "-fsanitize=leak"
> +
> +// RUN: %clang -target armeb-linux-gnu -fsanitize=leak %s -### 2>&1 |
> FileCheck %s --check-prefix=CHECK-SANL-ARMEB
> +// CHECK-SANL-ARMEB: "-fsanitize=leak"
> +
> +// RUN: %clang -target armeb-linux-gnu -fsanitize=address,leak
> -fno-sanitize=address %s -### 2>&1 | FileCheck %s
> --check-prefix=CHECK-SANA-SANL-NO-SANA-ARMEB
> +// CHECK-SANA-SANL-NO-SANA-ARMEB: "-fsanitize=leak"
> +
> +// RUN: %clang -target thumbeb-linux -fsanitize=leak %s -### 2>&1 |
> FileCheck %s --check-prefix=CHECK-SANL-THUMBEB
> +// CHECK-SANL-THUMBEB: "-fsanitize=leak"
> +
> +// RUN: %clang -target thumbeb-linux -fsanitize=address,leak
> -fno-sanitize=address %s -### 2>&1 | FileCheck %s
> --check-prefix=CHECK-SANA-SANL-NO-SANA-THUMBEB
> +// CHECK-SANA-SANL-NO-SANA-THUMBEB: "-fsanitize=leak"
> +
>  // RUN: %clang -target x86_64-linux-gnu -fsanitize=memory %s -### 2>&1 |
> FileCheck %s --check-prefix=CHECK-MSAN
>  // CHECK-MSAN: "-fno-assume-sane-operator-new"
>  // RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 |
> FileCheck %s --check-prefix=CHECK-ASAN
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

Re: r304663 - Fixed warning: enum constant in boolean context.

[David Blaikie via cfe-commits]

I followed up on the original commit (r299921) to request that as well.

On Sat, Jun 3, 2017 at 1:26 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Can we get a testcase for this bug? Seems like we can't have any coverage
> for the case where IsArmArch is supposed to be false.
>
>
> On 3 Jun 2017 9:47 am, "Galina Kistanova via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: gkistanova
> Date: Sat Jun  3 11:47:06 2017
> New Revision: 304663
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304663&view=rev
> Log:
> Fixed warning: enum constant in boolean context.
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/Linux.cpp
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Linux.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Linux.cpp?rev=304663&r1=304662&r2=304663&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Linux.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Linux.cpp Sat Jun  3 11:47:06 2017
> @@ -822,8 +822,9 @@ SanitizerMask Linux::getSupportedSanitiz
>const bool IsAArch64 = getTriple().getArch() == llvm::Triple::aarch64 ||
>   getTriple().getArch() ==
> llvm::Triple::aarch64_be;
>const bool IsArmArch = getTriple().getArch() == llvm::Triple::arm ||
> - llvm::Triple::thumb || llvm::Triple::armeb ||
> - llvm::Triple::thumbeb;
> + getTriple().getArch() == llvm::Triple::thumb ||
> + getTriple().getArch() == llvm::Triple::armeb ||
> + getTriple().getArch() == llvm::Triple::thumbeb;
>SanitizerMask Res = ToolChain::getSupportedSanitizers();
>Res |= SanitizerKind::Address;
>Res |= SanitizerKind::Fuzzer;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r299921 - [lsan] Enable LSan on arm Linux, clang part

[David Blaikie via cfe-commits]

On Mon, Jun 5, 2017 at 10:28 AM Maxim Ostapenko  wrote:

> On 05/06/17 20:16, David Blaikie wrote:
> > This change seemed to be buggy (& I assume missing test coverage to
> > demonstrate that). Galina fixed it in
> > http://llvm.org/viewvc/llvm-project?rev=304663&view=rev based on a
> > compiler warning.
>
> Oh, right, I've missed that. Sorry!
>
> >
> > Can you add test coverage to this code to exercise these untested
> > codepaths?
>
> But doesn't https://reviews.llvm.org/rL299921 introduce testcases for
> arm, thumb, armeb and thumbeb targets to clang driver?


Right, but none of the checks were being done - it was just always true.

The test coverage that's missing is something that would cause the 'if' on
line 877 in that patch to return false. So something that isn't x86_64,
isn't mips64, isn't aarch64, and isn't arm (so, maybe PPC? for example).
That test would demonstrate that lsan is still enabled in that case when it
shouldn't be, because the 'IsArmArch' is always true.


> Or perhaps I'm
> missing something?
>
> -Maxim
>
> >
> > On Tue, Apr 11, 2017 at 12:34 AM Maxim Ostapenko via cfe-commits
> > mailto:cfe-commits@lists.llvm.org>> wrote:
> >
> > Author: chefmax
> > Date: Tue Apr 11 02:22:11 2017
> > New Revision: 299921
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=299921&view=rev
> > Log:
> > [lsan] Enable LSan on arm Linux, clang part
> >
> > This is a compiler part of https://reviews.llvm.org/D29586. Enable
> > LSan on arm Linux.
> >
> > Differential Revision: https://reviews.llvm.org/D31760
> >
> > Modified:
> > cfe/trunk/lib/Driver/ToolChains/Linux.cpp
> > cfe/trunk/test/Driver/fsanitize.c
> >
> > Modified: cfe/trunk/lib/Driver/ToolChains/Linux.cpp
> > URL:
> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Linux.cpp?rev=299921&r1=299920&r2=299921&view=diff
> >
>  
> ==
> > --- cfe/trunk/lib/Driver/ToolChains/Linux.cpp (original)
> > +++ cfe/trunk/lib/Driver/ToolChains/Linux.cpp Tue Apr 11 02:22:11
> 2017
> > @@ -864,6 +864,9 @@ SanitizerMask Linux::getSupportedSanitiz
> > getTriple().getArch() ==
> > llvm::Triple::ppc64le;
> >const bool IsAArch64 = getTriple().getArch() ==
> > llvm::Triple::aarch64 ||
> >   getTriple().getArch() ==
> > llvm::Triple::aarch64_be;
> > +  const bool IsArmArch = getTriple().getArch() ==
> > llvm::Triple::arm ||
> > + llvm::Triple::thumb ||
> > llvm::Triple::armeb ||
> > + llvm::Triple::thumbeb;
> >SanitizerMask Res = ToolChain::getSupportedSanitizers();
> >Res |= SanitizerKind::Address;
> >Res |= SanitizerKind::KernelAddress;
> > @@ -871,7 +874,7 @@ SanitizerMask Linux::getSupportedSanitiz
> >Res |= SanitizerKind::SafeStack;
> >if (IsX86_64 || IsMIPS64 || IsAArch64)
> >  Res |= SanitizerKind::DataFlow;
> > -  if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86)
> > +  if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsArmArch)
> >  Res |= SanitizerKind::Leak;
> >if (IsX86_64 || IsMIPS64 || IsAArch64 || IsPowerPC64)
> >  Res |= SanitizerKind::Thread;
> >
> > Modified: cfe/trunk/test/Driver/fsanitize.c
> > URL:
> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize.c?rev=299921&r1=299920&r2=299921&view=diff
> >
>  
> ==
> > --- cfe/trunk/test/Driver/fsanitize.c (original)
> > +++ cfe/trunk/test/Driver/fsanitize.c Tue Apr 11 02:22:11 2017
> > @@ -237,6 +237,30 @@
> >  // RUN: %clang -target i686-linux-gnu -fsanitize=address,leak
> > -fno-sanitize=address %s -### 2>&1 | FileCheck %s
> > --check-prefix=CHECK-SANA-SANL-NO-SANA-X86
> >  // CHECK-SANA-SANL-NO-SANA-X86: "-fsanitize=leak"
> >
> > +// RUN: %clang -target arm-linux-gnu -fsanitize=leak %s -### 2>&1
> > | FileCheck %s --check-prefix=CHECK-SANL-ARM
> > +// CHECK-SANL-ARM: "-fsanitize=leak"
> > +
> > +// RUN: %clang -target arm-linux-gnu -fsanitize=address,leak
> > -fno-sanitize=address %s -### 2>&1 | FileCheck %s
> > --check-prefix=CHECK-SANA-SANL-NO-SANA-ARM
> > +// CHECK-SANA-SANL-NO-SANA-ARM: "-fsanitize=leak"
> > +
> > +// RUN: %clang -target thumb-linux -fsanitize=leak %s -### 2>&1 |
> > FileCheck %s --check-prefix=CHECK-SANL-THUMB
> > +// CHECK-SANL-THUMB: "-fsanitize=leak"
> > +
> > +// RUN: %clang -target thumb-linux -fsanitize=address,leak
> > -fno-sanitize=address %s -### 2>&1 | FileCheck %s
> > --check-prefix=CHECK-SANA-SANL-NO-SANA-THUMB
> > +// CHECK-SANA-SANL-NO-SANA-THUMB: "-fsanitize=leak"
> > +
> > +// RUN: %clang -target armeb-linux-gnu -fsanitize=leak %s -###
> > 2>&1 | FileCheck %

Re: [PATCH] D33102: [clang] Implement -Wcast-qual for C++

[David Blaikie via cfe-commits]

On Tue, Jun 6, 2017 at 3:59 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D33102#773296, @dblaikie wrote:
>
> > I still feel like that's more testing than would be ideal (does the
> context of the cast matter? Wether it's dereferenced, a struct member
> access, assigned, initialized, etc - it doesn't look like it from the code,
> etc).
>
>
> Looking at the `CastsAwayConstness()` function in lib/Sema/SemaCast.cpp:
> https://github.com/llvm-mirror/clang/blob/432ed0e4a6d58f7dda8992a167aad43bc91f76c6/lib/Sema/SemaCast.cpp#L505-L510
> You can see that it asserts that the pointer is one of three types. So i
> think it it is best to have maybe slightly overlapping test coverage here,
> rather than be surprised one day that such trivial cases no longer warn...
>
> > But sure. Could you also (manually, I guess) confirm that this matches
> GCC's cast-qual behavior (insofar as the warning fires in the same
> situations). If there are any deviations, let's chat about them.
>
> Sure.
>
> 1. Gcc produces the same //count// of the warnings:
>
>   $ pwd
>   llvm/tools/clang/test
>   $ grep -o "expected-warning" Sema/warn-cast-qual.c | wc -l
>   14
>   $ gcc -x c -fsyntax-only -Wcast-qual -c Sema/warn-cast-qual.c 2>&1 |
> grep ": warning: " | wc -l
>   14
>   $ gcc -x c++ -fsyntax-only -Wcast-qual -c Sema/warn-cast-qual.c 2>&1 |
> grep ": warning: " | wc -l
>   14
>   $ grep -o "expected-warning" SemaCXX/warn-cast-qual.cpp | wc -l
>   39
>   $ gcc -x c++ -fsyntax-only -Wcast-qual -c SemaCXX/warn-cast-qual.cpp
> 2>&1 | grep ": warning: " | wc -l
>   39
>
> 2. I'm not quite sure how to non-manually compare the warnings, so i'll
> just show the gcc output on these three cases. Since the clang warnings are
> appended as comments at the end of the each line that should warn, visual
> comparison is possible:
>

Works for the positive cases, not the negative ones. (though if the counts
are exactly the same, then so long as there are no false positives there
aren't any false negatives either)


>
> 2.1.
>
>   $ gcc -x c -fsyntax-only -Wcast-qual -c Sema/warn-cast-qual.c
>   Sema/warn-cast-qual.c: In function ‘foo’:
>   Sema/warn-cast-qual.c:9:13: warning: cast discards ‘const’ qualifier
> from pointer target type [-Wcast-qual]
>  char *y = (char *)ptr; // expected-warning {{cast from 'const char *'
> to 'char *' drops const qualifier}}
>^
>   Sema/warn-cast-qual.c:10:15: warning: cast discards ‘const’ qualifier
> from pointer target type [-Wcast-qual]
>  char **y1 = (char **)ptrptr; // expected-warning {{cast from 'const
> char *const' to 'char *' drops const qualifier}}
>  ^
>   Sema/warn-cast-qual.c:11:21: warning: cast discards ‘const’ qualifier
> from pointer target type [-Wcast-qual]
>  const char **y2 = (const char **)ptrptr; // expected-warning {{cast
> from 'const char *const *' to 'const char **' drops const qualifier}}
>^
>   Sema/warn-cast-qual.c:14:14: warning: cast discards ‘const’ qualifier
> from pointer target type [-Wcast-qual]
>  char *z1 = (char *)(const void *)ptr; // expected-warning {{cast from
> 'const void *' to 'char *' drops const qualifier}}
> ^
>   Sema/warn-cast-qual.c:17:16: warning: cast discards ‘volatile’ qualifier
> from pointer target type [-Wcast-qual]
>  char *vol2 = (char *)vol; // expected-warning {{cast from 'volatile
> char *' to 'char *' drops volatile qualifier}}
>   ^
>   Sema/warn-cast-qual.c:19:17: warning: cast discards ‘const volatile’
> qualifier from pointer target type [-Wcast-qual]
>  char *volc2 = (char *)volc; // expected-warning {{cast from 'const
> volatile char *' to 'char *' drops const and volatile qualifiers}}
>^
>   Sema/warn-cast-qual.c:22:28: warning: to be safe all intermediate
> pointers in cast from ‘int **’ to ‘const int **’ must be ‘const’ qualified
> [-Wcast-qual]
>  const int **intptrptrc = (const int **)intptrptr; // expected-warning
> {{cast from 'int **' to 'const int **' must have all intermediate pointers
> const qualified}}
>   ^
>   Sema/warn-cast-qual.c:23:31: warning: to be safe all intermediate
> pointers in cast from ‘int **’ to ‘volatile int **’ must be ‘const’
> qualified [-Wcast-qual]
>  volatile int **intptrptrv = (volatile int **)intptrptr; //
> expected-warning {{cast from 'int **' to 'volatile int **' must have all
> intermediate pointers const qualified}}
>  ^
>   Sema/warn-cast-qual.c:29:23: warning: cast discards ‘const’ qualifier
> from pointer target type [-Wcast-qual]
>  char **charptrptr = (char **)charptrptrc; // expected-warning {{cast
> from 'const char *' to 'char *' drops const qualifier}}
>  ^
>   Sema/warn-cast-qual.c:32:19: warning: cast discards ‘const’ qualifier
> from pointer target type [-Wcast-qual]
>  char *charp

Re: [PATCH] D33102: [clang] Implement -Wcast-qual for C++

[David Blaikie via cfe-commits]

Looks all good, please commit whenever you're ready - if you don't have
commit access, I (or anyone else with commit access) can commit this for
you.

On Tue, Jun 6, 2017 at 1:57 PM Roman Lebedev  wrote:

> On Tue, Jun 6, 2017 at 8:52 PM, David Blaikie  wrote:
> >
> >
> > On Tue, Jun 6, 2017 at 3:59 AM Roman Lebedev via Phabricator
> >  wrote:
> >>
> >> lebedev.ri added a comment.
> >>
> >> In https://reviews.llvm.org/D33102#773296, @dblaikie wrote:
> >>
> >> > I still feel like that's more testing than would be ideal (does the
> >> > context of the cast matter? Wether it's dereferenced, a struct member
> >> > access, assigned, initialized, etc - it doesn't look like it from the
> code,
> >> > etc).
> >>
> >>
> >> Looking at the `CastsAwayConstness()` function in lib/Sema/SemaCast.cpp:
> >>
> https://github.com/llvm-mirror/clang/blob/432ed0e4a6d58f7dda8992a167aad43bc91f76c6/lib/Sema/SemaCast.cpp#L505-L510
> >> You can see that it asserts that the pointer is one of three types. So i
> >> think it it is best to have maybe slightly overlapping test coverage
> here,
> >> rather than be surprised one day that such trivial cases no longer
> warn...
> >>
> >> > But sure. Could you also (manually, I guess) confirm that this matches
> >> > GCC's cast-qual behavior (insofar as the warning fires in the same
> >> > situations). If there are any deviations, let's chat about them.
> >>
> >> Sure.
> >>
> >> 1. Gcc produces the same //count// of the warnings:
> >>
> >>   $ pwd
> >>   llvm/tools/clang/test
> >>   $ grep -o "expected-warning" Sema/warn-cast-qual.c | wc -l
> >>   14
> >>   $ gcc -x c -fsyntax-only -Wcast-qual -c Sema/warn-cast-qual.c 2>&1 |
> >> grep ": warning: " | wc -l
> >>   14
> >>   $ gcc -x c++ -fsyntax-only -Wcast-qual -c Sema/warn-cast-qual.c 2>&1 |
> >> grep ": warning: " | wc -l
> >>   14
> >>   $ grep -o "expected-warning" SemaCXX/warn-cast-qual.cpp | wc -l
> >>   39
> >>   $ gcc -x c++ -fsyntax-only -Wcast-qual -c SemaCXX/warn-cast-qual.cpp
> >> 2>&1 | grep ": warning: " | wc -l
> >>   39
> >>
> >> 2. I'm not quite sure how to non-manually compare the warnings, so i'll
> >> just show the gcc output on these three cases. Since the clang warnings
> are
> >> appended as comments at the end of the each line that should warn,
> visual
> >> comparison is possible:
>
> > Works for the positive cases, not the negative ones. (though if the
> counts
> > are exactly the same, then so long as there are no false positives there
> > aren't any false negatives either)
> Yes, fair enough, i do not have anything to add here.
>
> >>
> >>
> >> 2.1.
> >>
> >>   $ gcc -x c -fsyntax-only -Wcast-qual -c Sema/warn-cast-qual.c
> >>   Sema/warn-cast-qual.c: In function ‘foo’:
> >>   Sema/warn-cast-qual.c:9:13: warning: cast discards ‘const’ qualifier
> >> from pointer target type [-Wcast-qual]
> >>  char *y = (char *)ptr; // expected-warning {{cast from 'const char
> *'
> >> to 'char *' drops const qualifier}}
> >>^
> >>   Sema/warn-cast-qual.c:10:15: warning: cast discards ‘const’ qualifier
> >> from pointer target type [-Wcast-qual]
> >>  char **y1 = (char **)ptrptr; // expected-warning {{cast from 'const
> >> char *const' to 'char *' drops const qualifier}}
> >>  ^
> >>   Sema/warn-cast-qual.c:11:21: warning: cast discards ‘const’ qualifier
> >> from pointer target type [-Wcast-qual]
> >>  const char **y2 = (const char **)ptrptr; // expected-warning {{cast
> >> from 'const char *const *' to 'const char **' drops const qualifier}}
> >>^
> >>   Sema/warn-cast-qual.c:14:14: warning: cast discards ‘const’ qualifier
> >> from pointer target type [-Wcast-qual]
> >>  char *z1 = (char *)(const void *)ptr; // expected-warning {{cast
> from
> >> 'const void *' to 'char *' drops const qualifier}}
> >> ^
> >>   Sema/warn-cast-qual.c:17:16: warning: cast discards ‘volatile’
> qualifier
> >> from pointer target type [-Wcast-qual]
> >>  char *vol2 = (char *)vol; // expected-warning {{cast from 'volatile
> >> char *' to 'char *' drops volatile qualifier}}
> >>   ^
> >>   Sema/warn-cast-qual.c:19:17: warning: cast discards ‘const volatile’
> >> qualifier from pointer target type [-Wcast-qual]
> >>  char *volc2 = (char *)volc; // expected-warning {{cast from 'const
> >> volatile char *' to 'char *' drops const and volatile qualifiers}}
> >>^
> >>   Sema/warn-cast-qual.c:22:28: warning: to be safe all intermediate
> >> pointers in cast from ‘int **’ to ‘const int **’ must be ‘const’
> qualified
> >> [-Wcast-qual]
> >>  const int **intptrptrc = (const int **)intptrptr; //
> expected-warning
> >> {{cast from 'int **' to 'const int **' must have all intermediate
> pointers
> >> const qualified}}
> >>   ^
> >>   Sema/warn-cast-qual.c:23:31: warning: to be safe all intermediate
> >> pointers in cast from ‘int **’ to ‘volatile int **’ must be ‘const’
> >> qualified [-Wcast-qual]
> 

Re: [PATCH] D33102: [clang] Implement -Wcast-qual for C++

[David Blaikie via cfe-commits]

On Sat, Jun 10, 2017 at 3:33 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri planned changes to this revision.
> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D33102#773296, @dblaikie wrote:
>
> > But sure. Could you also (manually, I guess) confirm that this matches
> GCC's cast-qual behavior (insofar as the warning fires in the same
> situations). If there are any deviations, let's chat about them.
>
>
> Great, you were right :)
> Found a false-negative:
>
>   $ cat /tmp/tst.c
>   int main() {
> void* p1 = (void*)"txt";
> char* p2 = (char*)"txt";
>   }
>   $ gcc -x c -Wcast-qual /tmp/tst.c
>   $ gcc -x c++ -Wcast-qual /tmp/tst.c
>   /tmp/tst.c: In function ‘int main()’:
>   /tmp/tst.c:2:21: warning: cast from type ‘const char*’ to type ‘void*’
> casts away qualifiers [-Wcast-qual]
>  void* p1 = (void*)"txt";
>^
>   /tmp/tst.c:3:21: warning: cast from type ‘const char*’ to type ‘char*’
> casts away qualifiers [-Wcast-qual]
>  char* p2 = (char*)"txt";
>^
>
>   $ ./bin/clang -x c -Wcast-qual /tmp/tst.c
>   $ ./bin/clang -x c++ -Wcast-qual /tmp/tst.c
>   /tmp/tst.c:3:21: warning: cast from 'const char *' to 'char *' drops
> const qualifier [-Wcast-qual]
> char* p2 = (char*)"txt";
>   ^
>   1 warning generated.
>
> So at least, in C++ mode, it should warn on both lines.
>

Seems reasonable that it should, yes.

(aside: You're still welcome to commit this patch as-is, and provide
patches for improvements as follow-up (mostly false positives would be more
of a concern to address before commit))


> I'm not sure, should that really not produce a warning in C?
> (gcc version 6.3.0 20170516 (Debian 6.3.0-18) )
>

Probably not, no - string literals have some weird mutability in C (& in
older versions of C++, even).

- Dave


>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D33102
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33932: [clang-format] Add support for case-insensitive header matching and use it to improve support for LLVM-style include sorting.

[David Blaikie via cfe-commits]

On Tue, Jun 6, 2017 at 3:56 AM Chandler Carruth via Phabricator via
cfe-commits  wrote:

> chandlerc created this revision.
> Herald added subscribers: mcrosier, sanjoy, klimek.
>
> This really is a collection of improvements to the rules for LLVM
> include sorting:
>
> - We have gmock headers now, so it adds support for those to one of the
> categories.
> - LLVM does use 'FooTest.cpp' files to test 'Foo.h' so it adds that suffix
> for finding a main header.
> - At times the test file's case may not match the header file's case, so
> adds support for case-insensitive regex matching of these things.
>

Curious - where does this last one come up? Can we fix those, or do they
look good/intentional/worth keeping?


>
> With this set of changes, I can't spot any misbehaviors when re-sorting
> all of LLVM's unittest '#include' lines.
>
> Note that I don't know the first thing about testing clang-format, so
> please
> feel free to tell me what all I need to be doing here.
>
>
> https://reviews.llvm.org/D33932
>
> Files:
>   include/clang/Format/Format.h
>   lib/Format/Format.cpp
>   unittests/Format/SortIncludesTest.cpp
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r304892 - [Sema] Silence unused variable warning.

[David Blaikie via cfe-commits]

Richard, looks like this might be better as:

if (auto QL = OE->getQualifierLoc())
  ... QL.getBeginLoc() ...

?


On Wed, Jun 7, 2017 at 3:23 AM Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: d0k
> Date: Wed Jun  7 05:23:17 2017
> New Revision: 304892
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304892&view=rev
> Log:
> [Sema] Silence unused variable warning.
>
> Modified:
> cfe/trunk/lib/Sema/SemaExpr.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=304892&r1=304891&r2=304892&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Wed Jun  7 05:23:17 2017
> @@ -11843,7 +11843,7 @@ ExprResult Sema::BuildBinOp(Scope *S, So
>std::any_of(OE->decls_begin(), OE->decls_end(), [](NamedDecl
> *ND) {
>  return isa(ND);
>})) {
> -if (auto *Q = OE->getQualifier()) {
> +if (OE->getQualifier()) {
>Diag(OE->getQualifierLoc().getBeginLoc(),
> diag::err_template_kw_missing)
>  << OE->getName().getAsString() << "";
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33102: [clang] Implement -Wcast-qual for C++

[David Blaikie via cfe-commits]

On Mon, Jun 12, 2017 at 10:10 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri added a comment.
>
> So i'm trying to analyze that stage2 warning.
>

Could you link to the buildbot failure to see the original LLVM project
code triggering this situation?


> The testcase //seems// to be: (autogenerated all the variants)
>
>   void test_nop() {
> unsigned char **ptr1 = 0;
> void **ptr2 = (void **)ptr1;
>   }
>   void test_bad() {
> unsigned char **ptr1 = 0;
> const void **ptr2 = (const void **)ptr1; // expected-warning {{cast
> from 'unsigned char **' to 'const void **' must have all intermediate
> pointers const qualified to be safe}}
>   }
>   void test_good0() {
> unsigned char **ptr1 = 0;
> void *const *ptr2 = (void *const *)ptr1;
>   }
>   void test_good1() {
> unsigned char **ptr1 = 0;
> const void *const *ptr2 = (const void *const *)ptr1;
>   }
>   void test_good2() {
> unsigned char *const *ptr1 = 0;
> void *const *ptr2 = (void *const *)ptr1;
>   }
>   void test_good3() {
> unsigned char *const *ptr1 = 0;
> const void *const *ptr2 = (const void *const *)ptr1;
>   }
>   void test_good4() {
> const unsigned char **ptr1 = 0;
> const void **ptr2 = (const void **)ptr1;
>   }
>   void test_good5() {
> const unsigned char **ptr1 = 0;
> const void *const *ptr2 = (const void *const *)ptr1;
>   }
>   void test_good6() {
> const unsigned char *const *ptr1 = 0;
> const void *const *ptr2 = (const void *const *)ptr1;
>   }
>
> GCC does not warn about such code at all, clang in C mode does warn about
> only one combination:
>
>   $ gcc -c /tmp/test.c -Wcast-qual
>   $ echo $?
>   0
>   $ clang -c /tmp/test.c -Wcast-qual
>   /tmp/test.c:7:38: warning: cast from 'unsigned char **' to 'const void
> **' must have all intermediate pointers const qualified to be safe
> [-Wcast-qual]
> const void **ptr2 = (const void **)ptr1; // expected-warning {{cast
> from 'unsigned char **' to 'const void **' must have all intermediate
> pointers const qualified to be safe}}
>^
>   1 warning generated.
>
> David, you reviewed the original `-Wcast-qual` patch, does all that ^ make
> sense?
>

That seems like a reasonable warning, do you agree?

But maybe it's best to put it under another flag name so it doesn't collide
with GCC.

But really - *shrug* I'd probably leave it under the same flag, fix the
LLVM project code that causes it, and carry on.


>
> F3429854: gen.cpp 
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D33102
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r305213 - Add regression test for r305179.

[David Blaikie via cfe-commits]

Prefer FileCheck over grep, generally?

On Mon, Jun 12, 2017 at 11:05 AM Yaron Keren via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: yrnkrn
> Date: Mon Jun 12 13:05:13 2017
> New Revision: 305213
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305213&view=rev
> Log:
> Add regression test for r305179.
>
>
> Added:
> cfe/trunk/test/Misc/pr32207.c
>
> Added: cfe/trunk/test/Misc/pr32207.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/pr32207.c?rev=305213&view=auto
>
> ==
> --- cfe/trunk/test/Misc/pr32207.c (added)
> +++ cfe/trunk/test/Misc/pr32207.c Mon Jun 12 13:05:13 2017
> @@ -0,0 +1,3 @@
> +// test for r305179
> +// RUN: %clang_cc1 -emit-llvm -O -mllvm -print-after-all %s -o %t 2>&1 |
> grep '*** IR Dump After Function Integration/Inlining ***'
> +void foo() {}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33102: [clang] Implement -Wcast-qual for C++

[David Blaikie via cfe-commits]

Yeah, looks like the UB is baked in pretty deep here, so it's not
reasonable to try to fix it just because of this.

I'd probably suggest trying making that cast in PointerUnion.h into a
reinterpret cast? Would that suffice to address the const issues? Otherwise
a const_cast + reinterpret_cast?



On Mon, Jun 12, 2017 at 10:35 AM Roman Lebedev  wrote:

> On Mon, Jun 12, 2017 at 8:16 PM, David Blaikie  wrote:
> >
> >
> > On Mon, Jun 12, 2017 at 10:10 AM Roman Lebedev via Phabricator
> >  wrote:
> >>
> >> lebedev.ri added a comment.
> >>
> >> So i'm trying to analyze that stage2 warning.
> >
> >
> > Could you link to the buildbot failure to see the original LLVM project
> code
> > triggering this situation?
> http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/3249
>
> http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/3249/steps/build-stage2-LLVMgold.so/logs/stdio
>
> FAILED:
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/install/stage1/bin/clang++
>   -DGTEST_HAS_RTTI=0 -DLLVM_BUILD_GLOBAL_ISEL -D_DEBUG -D_GNU_SOURCE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Ilib/CodeGen/AsmPrinter
>
> -I/home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/lib/CodeGen/AsmPrinter
> -Iinclude
> -I/home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/include
> -fPIC -fvisibility-inlines-hidden -Werror -Werror=date-time -std=c++11
> -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> -Wstring-conversion -fcolor-diagnostics -ffunction-sections
> -fdata-sections -O3-UNDEBUG  -fno-exceptions -fno-rtti -MMD -MT
> lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/CodeViewDebug.cpp.o
> -MF
> lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/CodeViewDebug.cpp.o.d
> -o lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/CodeViewDebug.cpp.o
> -c
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
> In file included from
>
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp:14:
> In file included from
>
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/lib/CodeGen/AsmPrinter/CodeViewDebug.h:17:
> In file included from
>
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/lib/CodeGen/AsmPrinter/DbgValueHistoryCalculator.h:15:
> In file included from
>
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/include/llvm/IR/DebugInfoMetadata.h:26:
> In file included from
>
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/include/llvm/IR/Metadata.h:23:
>
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/include/llvm/ADT/PointerUnion.h:161:19:
> error: cast from 'void **' to 'const llvm::DISubprogram **' must have
> all intermediate pointers const qualified to be safe
> [-Werror,-Wcast-qual]
> return (PT1 *)Val.getAddrOfPointer();
>   ^
>
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/include/llvm/ADT/TinyPtrVector.h:177:18:
> note: in instantiation of member function 'llvm::PointerUnion llvm::DISubprogram *, llvm::SmallVector
> *>::getAddrOfPtr1' requested here
>   return Val.getAddrOfPtr1();
>  ^
>
> /home/buildbot/Buildbot/Slave1a/clang-with-lto-ubuntu/llvm.src/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp:1885:33:
> note: in instantiation of member function 'llvm::TinyPtrVector llvm::DISubprogram *>::begin' requested here
> for (const DISubprogram *SP : MethodItr.second) {
> ^
>
>
> >>
> >> The testcase //seems// to be: (autogenerated all the variants)
> >>
> >>   void test_nop() {
> >> unsigned char **ptr1 = 0;
> >> void **ptr2 = (void **)ptr1;
> >>   }
> >>   void test_bad() {
> >> unsigned char **ptr1 = 0;
> >> const void **ptr2 = (const void **)ptr1; // expected-warning {{cast
> >> from 'unsigned char **' to 'const void **' must have all intermediate
> >> pointers const qualified to be safe}}
> >>   }
> >>   void test_good0() {
> >> unsigned char **ptr1 = 0;
> >> void *const *ptr2 = (void *const *)ptr1;
> >>   }
> >>   void test_good1() {
> >> unsigned char **ptr1 = 0;
> >> const void *const *ptr2 = (const void *const *)ptr1;
> >>   }
> >>   void test_good2() {
> >> unsigned char *const *ptr1 = 0;
> >> void *const *ptr2 = (void *const *)ptr1;
> >>   }
> >>   void test_good3() {
> >> unsigned char *const *ptr1 = 0;
> >> const void *const *ptr2 = (const void *const *)ptr1;
> >>   }
> >>   void test_good4() {
> >> const unsigned char **ptr1 = 0;
> >> const void **ptr2 = (const void **)ptr1;
> >>   }
> >>   void test_good5() {
> >> const unsigned char **ptr1 = 0;
> >> const void *const *ptr2 = (const void *const *)ptr1;
> >>   }
> >>   void test_good6() {
> >> const unsigned char *co

Re: r305182 - Revert r305164/5/7.

[David Blaikie via cfe-commits]

hey Saleem - might be worth sending a cfe-dev email about what the general
direction/goals are here (may not need precommit review for every patch,
but just some sanity checking)

On Mon, Jun 12, 2017 at 1:08 AM Daniel Jasper via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: djasper
> Date: Mon Jun 12 03:08:18 2017
> New Revision: 305182
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305182&view=rev
> Log:
> Revert r305164/5/7.
>
> cc1as does not currently access the "--" version of this flag. At the
> very least this needs to be fixed and proper test cases need to be
> added.
>
> Simple reproducer:
> clang -Wa,--compress-debug-sections /tmp/test.cc
>
> Result:
> error: unknown argument: '--compress-debug-sections'
>
> Removed:
> cfe/trunk/test/Driver/compress-noias.c
> Modified:
> cfe/trunk/include/clang/Driver/CC1Options.td
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/test/Driver/compress.c
> cfe/trunk/test/Driver/nozlibcompress.c
> cfe/trunk/tools/driver/cc1as_main.cpp
>
> Modified: cfe/trunk/include/clang/Driver/CC1Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=305182&r1=305181&r2=305182&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/CC1Options.td (original)
> +++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Jun 12 03:08:18 2017
> @@ -134,6 +134,7 @@ def migrator_no_finalize_removal : Flag<
>
>  
> //===--===//
>
>  let Flags = [CC1Option, CC1AsOption, NoDriverOption] in {
> +
>  def debug_info_kind_EQ : Joined<["-"], "debug-info-kind=">;
>  def debug_info_macro : Flag<["-"], "debug-info-macro">,
>HelpText<"Emit macro debug information">;
> @@ -143,16 +144,14 @@ def fdebug_compilation_dir : Separate<["
>HelpText<"The compilation directory to embed in the debug info.">;
>  def dwarf_debug_flags : Separate<["-"], "dwarf-debug-flags">,
>HelpText<"The string to embed in the Dwarf debug flags record.">;
> -def compress_debug_sections : Flag<["-"], "compress-debug-sections">,
> -HelpText<"DWARF debug sections compression">;
> -def compress_debug_sections_EQ : Flag<["-"], "compress-debug-sections=">,
> -HelpText<"DWARF debug sections compression type">;
>  def mno_exec_stack : Flag<["-"], "mnoexecstack">,
>HelpText<"Mark the file as not needing an executable stack">;
>  def massembler_fatal_warnings : Flag<["-"], "massembler-fatal-warnings">,
>HelpText<"Make assembler warnings fatal">;
>  def mrelax_relocations : Flag<["--"], "mrelax-relocations">,
>  HelpText<"Use relaxable elf relocations">;
> +def compress_debug_sections : Flag<["-"], "compress-debug-sections">,
> +HelpText<"Compress DWARF debug sections using zlib">;
>  def msave_temp_labels : Flag<["-"], "msave-temp-labels">,
>HelpText<"Save temporary labels in the symbol table. "
> "Note this may change .s semantics and shouldn't generally be
> used "
>
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=305182&r1=305181&r2=305182&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Mon Jun 12 03:08:18 2017
> @@ -1563,10 +1563,6 @@ def gdwarf_aranges : Flag<["-"], "gdwarf
>  def gmodules : Flag <["-"], "gmodules">, Group,
>HelpText<"Generate debug info with external references to clang modules"
> " or precompiled headers">;
> -def gz : Flag<["-"], "gz">, Group,
> -HelpText<"DWARF debug sections compression type">;
> -def gz_EQ : Joined<["-"], "gz=">, Group,
> -HelpText<"DWARF debug sections compression type">;
>  def headerpad__max__install__names : Joined<["-"],
> "headerpad_max_install_names">;
>  def help : Flag<["-", "--"], "help">, Flags<[CC1Option,CC1AsOption]>,
>HelpText<"Display available options">;
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=305182&r1=305181&r2=305182&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon Jun 12 03:08:18 2017
> @@ -910,37 +910,6 @@ static void RenderDebugEnablingArgs(cons
>}
>  }
>
> -static void RenderDebugInfoCompressionArgs(const ArgList &Args,
> -   ArgStringList &CmdArgs,
> -   const Driver &D) {
> -  const Arg *A = Args.getLastArg(options::OPT_gz, options::OPT

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

I've been seeing errors from this test recently:

Command Output (stderr):
--
1 error generated.
Error while processing
/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.nonexistent.cpp.
/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp:10:12:
error: expected string not found in input
// CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double' to
'int' changes value from 1.5 to 1 [clang-diagnostic-literal-conversion]
   ^
:2:1: note: scanning from here
Skipping
/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
Compile command not found.
^
:2:1: note: with expression "@LINE+2" equal to "12"
Skipping
/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
Compile command not found.
^


Specifically, the output is:
$ ./bin/clang-tidy
-checks='-*,clang-diagnostic-*,google-explicit-constructor'
/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp
-- -fan-unknown-option 2>&1error: unknown
argument: '-fan-unknown-option'
 Skipping
/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
Compile command not found.


Does this look like it might be related to any of your changes in this
area? Perhaps the error due to unknown argument is causing clang-tidy not
to continue on to run the check & report the warning?


On Wed, May 24, 2017 at 3:51 AM Serge Pavlov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sepavloff
> Date: Wed May 24 05:50:56 2017
> New Revision: 303735
>
> URL: http://llvm.org/viewvc/llvm-project?rev=303735&view=rev
> Log:
> Modify test so that it looks for patterns in stderr as well
>
> With the change https://reviews.llvm.org/D33013 driver will not build
> compilation object if command line is invalid, in particular, if
> unrecognized option is provided. In such cases it will prints diagnostics
> on stderr. The test 'clang-tidy/diagnostic.cpp' checks reaction on
> unrecognized option and will fail when D33013 is applied because it checks
> only stdout for test patterns and expects the name of diagnostic category
> prepared by clang-tidy. With this change the test makes more general check
> and must work in either case.
>
> Differential Revision: https://reviews.llvm.org/D33173
>
> Modified:
> clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp
>
> Modified: clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp?rev=303735&r1=303734&r2=303735&view=diff
>
> ==
> --- clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp (original)
> +++ clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp Wed May 24
> 05:50:56 2017
> @@ -1,11 +1,11 @@
>  // RUN: clang-tidy -checks='-*,modernize-use-override' %s.nonexistent.cpp
> -- | FileCheck -check-prefix=CHECK1
> -implicit-check-not='{{warning:|error:}}' %s
> -// RUN: clang-tidy
> -checks='-*,clang-diagnostic-*,google-explicit-constructor' %s --
> -fan-unknown-option | FileCheck -check-prefix=CHECK2
> -implicit-check-not='{{warning:|error:}}' %s
> -// RUN: clang-tidy
> -checks='-*,google-explicit-constructor,clang-diagnostic-literal-conversion'
> %s -- -fan-unknown-option | FileCheck -check-prefix=CHECK3
> -implicit-check-not='{{warning:|error:}}' %s
> +// RUN: clang-tidy
> -checks='-*,clang-diagnostic-*,google-explicit-constructor' %s --
> -fan-unknown-option 2>&1 | FileCheck -check-prefix=CHECK2
> -implicit-check-not='{{warning:|error:}}' %s
> +// RUN: clang-tidy
> -checks='-*,google-explicit-constructor,clang-diagnostic-literal-conversion'
> %s -- -fan-unknown-option 2>&1 | FileCheck -check-prefix=CHECK3
> -implicit-check-not='{{warning:|error:}}' %s
>  // RUN: clang-tidy
> -checks='-*,modernize-use-override,clang-diagnostic-macro-redefined' %s --
> -DMACRO_FROM_COMMAND_LINE | FileCheck -check-prefix=CHECK4
> -implicit-check-not='{{warning:|error:}}' %s
>
>  // CHECK1: error: error reading '{{.*}}.nonexistent.cpp'
> [clang-diagnostic-error]
> -// CHECK2: error: unknown argument: '-fan-unknown-option'
> [clang-diagnostic-error]
> -// CHECK3: error: unknown argument: '-fan-unknown-option'
> [clang-diagnostic-error]
> +// CHECK2: error: unknown argument: '-fan-unknown-option'
> +// CHECK3: error: unknown argument: '-fan-unknown-option'
>
>  // CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double' to
> 'int' changes value from 1.5 to 1 [clang-diagnostic-literal-conversion]
>  // CHECK3: :[[@LINE+1]]:9: warning: implicit conversion from 'double' to
> 'int' changes value
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http:

Re: [PATCH] D34052: [XRay][clang] Support capturing the implicit `this` argument to C++ class member functions

[David Blaikie via cfe-commits]

hard to say if it's more readable without seeing it - if you could attach a
patch, if it's easy enough/you worked it up before, might be worth
comparing/contrasting


On Tue, Jun 13, 2017 at 12:28 AM Dean Michael Berris via Phabricator <
revi...@reviews.llvm.org> wrote:

> dberris added a comment.
>
> In https://reviews.llvm.org/D34052#778670, @dblaikie wrote:
>
> > I take it there's already handling for these attributes on non-member
> functions?
>
>
> Yes, we're just extending it to also apply to the case where it doesn't
> support this one case where we actually do need the implicit this argument
>
> > There's probably a reason this code can't be wherever that code is &
> subtract one from the index? (reducing code duplication by having all the
> error handling, etc, in one place/once)
>
> I tried doing it for the `checkFunctionOrMethodNumParams` function, but it
> ended up being much more complicated. :(
>
> The choice is between adding a bool argument (e.g. AllowImplicitThis) in
> `checkFunctionOrMethodParameterIndex(...)` that's default to always true
> (to preserve existing behaviour) but the checks and implementation of that
> template has a number of assumptions as to whether the index is valid for
> member functions.
>
> I can change this so that the logic is contained in
> `checkFunctionOrMethodParameterIndex(...)` if that's more readable?
>
>
> https://reviews.llvm.org/D34052
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

Ah, I find that the test passes if I remove the compile_commands.json file
from my build directory (I have Ninja configured to generate a
compile_commands.json file).

Looks like what happens is it finds the compilation database and fails hard
when the database doesn't contain a compile command for the file in
question. If the database is not found, it falls back to some basic command
behavior, perhaps?

Is there some way this test could be fixed to cope with this, otherwise it
seems to get in the way of people actually using clang tools in their
LLVM/Clang build environment?

On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov  wrote:

> I cannot reproduce such fail, so I can only guess how changes made in
> https://reviews.llvm.org/rL303756 and https://reviews.llvm.org/rL303741
> could cause such problem. Behavior of `Driver::BuildCompilation` is changed
> so that it returns null pointer if errors occur during driver argument
> parse. It is called in `CompilationDatabase.cpp` from
> `stripPositionalArgs`. The call stack at this point is:
> stripPositionalArgs
> clang::tooling::FixedCompilationDatabase::loadFromCommandLine
> clang::tooling::CommonOptionsParser::CommonOptionsParser
> clang::tidy::clangTidyMain
> main
> `FixedCompilationDatabase::loadFromCommandLine` returns null and
> CommonOptionsParser uses another method to create compilation database. The
> output "Compile command not found" means that no input file were found in
> `ClangTool::run`. Maybe some file names are nulls?
>
>
> Thanks,
> --Serge
>
> 2017-06-13 3:42 GMT+07:00 David Blaikie :
>
>> I've been seeing errors from this test recently:
>>
>> Command Output (stderr):
>> --
>> 1 error generated.
>> Error while processing
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.nonexistent.cpp.
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp:10:12:
>> error: expected string not found in input
>> // CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double' to
>> 'int' changes value from 1.5 to 1 [clang-diagnostic-literal-conversion]
>>^
>> :2:1: note: scanning from here
>> Skipping
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
>> Compile command not found.
>> ^
>> :2:1: note: with expression "@LINE+2" equal to "12"
>> Skipping
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
>> Compile command not found.
>> ^
>>
>>
>> Specifically, the output is:
>> $ ./bin/clang-tidy
>> -checks='-*,clang-diagnostic-*,google-explicit-constructor'
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp
>> -- -fan-unknown-option 2>&1error: unknown
>> argument: '-fan-unknown-option'
>>  Skipping
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
>> Compile command not found.
>>
>>
>> Does this look like it might be related to any of your changes in this
>> area? Perhaps the error due to unknown argument is causing clang-tidy not
>> to continue on to run the check & report the warning?
>>
>>
>> On Wed, May 24, 2017 at 3:51 AM Serge Pavlov via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: sepavloff
>>> Date: Wed May 24 05:50:56 2017
>>> New Revision: 303735
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=303735&view=rev
>>> Log:
>>> Modify test so that it looks for patterns in stderr as well
>>>
>>> With the change https://reviews.llvm.org/D33013 driver will not build
>>> compilation object if command line is invalid, in particular, if
>>> unrecognized option is provided. In such cases it will prints diagnostics
>>> on stderr. The test 'clang-tidy/diagnostic.cpp' checks reaction on
>>> unrecognized option and will fail when D33013 is applied because it
>>> checks
>>> only stdout for test patterns and expects the name of diagnostic category
>>> prepared by clang-tidy. With this change the test makes more general
>>> check
>>> and must work in either case.
>>>
>>> Differential Revision: https://reviews.llvm.org/D33173
>>>
>>> Modified:
>>> clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp
>>>
>>> Modified: clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp?rev=303735&r1=303734&r2=303735&view=diff
>>>
>>> ==
>>> --- clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp (original)
>>> +++ clang-tools-extra/trunk/test/clang-tidy/diagnostic.cpp Wed May 24
>>> 05:50:56 2017
>>> @@ -1,11 +1,11 @@
>>>  // RUN: clang-tidy -checks='-*,modernize-use-override'
>>> %s.nonexistent.cpp -- | FileCheck -check-prefix=CHECK1
>>> -implicit-check-not='{{warning:|error:}}' %s

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov  wrote:

> 2017-06-14 4:24 GMT+07:00 David Blaikie :
>
>> Ah, I find that the test passes if I remove the compile_commands.json
>> file from my build directory (I have Ninja configured to generate a
>> compile_commands.json file).
>>
>> Looks like what happens is it finds the compilation database and fails
>> hard when the database doesn't contain a compile command for the file in
>> question. If the database is not found, it falls back to some basic command
>> behavior, perhaps?
>>
>>
> You are right, constructor of `CommonOptionsParser` calls
> `autoDetectFromSource` or `autoDetectFromDirectory` prior to final
> construction of `FixedCompilationDatabase.
>
> Is there some way this test could be fixed to cope with this, otherwise it
>> seems to get in the way of people actually using clang tools in their
>> LLVM/Clang build environment?
>>
>>
> IIUC, presence of stale compilation database file in test directory could
> break many tests. I don't understand why only diagnostic.cpp fails,
> probably there is something wrong with the clang-tidy application cleanup
> in this case?
>

Except it's neither stale nor in the test directory.

It's the up to date/useful/used compile_commands.json generated by ninja in
the root of the build tree.


>
>> On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov  wrote:
>>
>>> I cannot reproduce such fail, so I can only guess how changes made in
>>> https://reviews.llvm.org/rL303756 and https://reviews.llvm.org/rL303741
>>> could cause such problem. Behavior of `Driver::BuildCompilation` is changed
>>> so that it returns null pointer if errors occur during driver argument
>>> parse. It is called in `CompilationDatabase.cpp` from
>>> `stripPositionalArgs`. The call stack at this point is:
>>> stripPositionalArgs
>>> clang::tooling::FixedCompilationDatabase::loadFromCommandLine
>>> clang::tooling::CommonOptionsParser::CommonOptionsParser
>>> clang::tidy::clangTidyMain
>>> main
>>> `FixedCompilationDatabase::loadFromCommandLine` returns null and
>>> CommonOptionsParser uses another method to create compilation database. The
>>> output "Compile command not found" means that no input file were found in
>>> `ClangTool::run`. Maybe some file names are nulls?
>>>
>>>
>>> Thanks,
>>> --Serge
>>>
>>> 2017-06-13 3:42 GMT+07:00 David Blaikie :
>>>
 I've been seeing errors from this test recently:

 Command Output (stderr):
 --
 1 error generated.
 Error while processing
 /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.nonexistent.cpp.
 /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp:10:12:
 error: expected string not found in input
 // CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double'
 to 'int' changes value from 1.5 to 1 [clang-diagnostic-literal-conversion]
^
 :2:1: note: scanning from here
 Skipping
 /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
 Compile command not found.
 ^
 :2:1: note: with expression "@LINE+2" equal to "12"
 Skipping
 /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
 Compile command not found.
 ^


 Specifically, the output is:
 $ ./bin/clang-tidy
 -checks='-*,clang-diagnostic-*,google-explicit-constructor'
 /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp
 -- -fan-unknown-option 2>&1error: unknown
 argument: '-fan-unknown-option'
  Skipping
 /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
 Compile command not found.


 Does this look like it might be related to any of your changes in this
 area? Perhaps the error due to unknown argument is causing clang-tidy not
 to continue on to run the check & report the warning?


 On Wed, May 24, 2017 at 3:51 AM Serge Pavlov via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: sepavloff
> Date: Wed May 24 05:50:56 2017
> New Revision: 303735
>
> URL: http://llvm.org/viewvc/llvm-project?rev=303735&view=rev
> Log:
> Modify test so that it looks for patterns in stderr as well
>
> With the change https://reviews.llvm.org/D33013 driver will not build
> compilation object if command line is invalid, in particular, if
> unrecognized option is provided. In such cases it will prints
> diagnostics
> on stderr. The test 'clang-tidy/diagnostic.cpp' checks reaction on
> unrecognized option and will fail when D33013 is applied because it
> checks
> only stdout for test patterns and expects the name of diagnostic
> category
> prepared by clang-tid

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

https://sarcasm.github.io/notes/dev/compilation-database.html#cmake

If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (& have a
sufficiently recent cmake), then CMake will generate a
compile_commands.json in the root of the build tree. The test finds this &
fails, instead of finding no compilation database & succeeding.

(to use this, you can then symlink from the root of the source tree to
point to this in your build tree - this is how I get YCM to work for my
LLVM builds & could work for other clang tools as well)

On Thu, Jun 15, 2017 at 7:51 AM Serge Pavlov  wrote:

> 2017-06-15 2:43 GMT+07:00 David Blaikie :
>
>>
>>
>> On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov  wrote:
>>
>>> 2017-06-14 4:24 GMT+07:00 David Blaikie :
>>>
 Ah, I find that the test passes if I remove the compile_commands.json
 file from my build directory (I have Ninja configured to generate a
 compile_commands.json file).

 Looks like what happens is it finds the compilation database and fails
 hard when the database doesn't contain a compile command for the file in
 question. If the database is not found, it falls back to some basic command
 behavior, perhaps?


>>> You are right, constructor of `CommonOptionsParser` calls
>>> `autoDetectFromSource` or `autoDetectFromDirectory` prior to final
>>> construction of `FixedCompilationDatabase.
>>>
>>> Is there some way this test could be fixed to cope with this, otherwise
 it seems to get in the way of people actually using clang tools in their
 LLVM/Clang build environment?


>>> IIUC, presence of stale compilation database file in test directory
>>> could break many tests. I don't understand why only diagnostic.cpp fails,
>>> probably there is something wrong with the clang-tidy application cleanup
>>> in this case?
>>>
>>
>> Except it's neither stale nor in the test directory.
>>
>> It's the up to date/useful/used compile_commands.json generated by ninja
>> in the root of the build tree.
>>
>
> I miss something. If I could reproduce the problem, I would investigate it.
>
>
>>
>>
>>>
 On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov 
 wrote:

> I cannot reproduce such fail, so I can only guess how changes made in
> https://reviews.llvm.org/rL303756 and
> https://reviews.llvm.org/rL303741 could cause such problem. Behavior
> of `Driver::BuildCompilation` is changed so that it returns null pointer 
> if
> errors occur during driver argument parse. It is called in
> `CompilationDatabase.cpp` from `stripPositionalArgs`. The call stack at
> this point is:
> stripPositionalArgs
> clang::tooling::FixedCompilationDatabase::loadFromCommandLine
> clang::tooling::CommonOptionsParser::CommonOptionsParser
> clang::tidy::clangTidyMain
> main
> `FixedCompilationDatabase::loadFromCommandLine` returns null and
> CommonOptionsParser uses another method to create compilation database. 
> The
> output "Compile command not found" means that no input file were found in
> `ClangTool::run`. Maybe some file names are nulls?
>
>
> Thanks,
> --Serge
>
> 2017-06-13 3:42 GMT+07:00 David Blaikie :
>
>> I've been seeing errors from this test recently:
>>
>> Command Output (stderr):
>> --
>> 1 error generated.
>> Error while processing
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.nonexistent.cpp.
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp:10:12:
>> error: expected string not found in input
>> // CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double'
>> to 'int' changes value from 1.5 to 1 
>> [clang-diagnostic-literal-conversion]
>>^
>> :2:1: note: scanning from here
>> Skipping
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
>> Compile command not found.
>> ^
>> :2:1: note: with expression "@LINE+2" equal to "12"
>> Skipping
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
>> Compile command not found.
>> ^
>>
>>
>> Specifically, the output is:
>> $ ./bin/clang-tidy
>> -checks='-*,clang-diagnostic-*,google-explicit-constructor'
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp
>> -- -fan-unknown-option 2>&1error: unknown
>> argument: '-fan-unknown-option'
>>  Skipping
>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
>> Compile command not found.
>>
>>
>> Does this look like it might be related to any of your changes in
>> this area? Perhaps the error due to unknown argum

Re: [PATCH] D34052: [XRay][clang] Support capturing the implicit `this` argument to C++ class member functions

[David Blaikie via cfe-commits]

On Mon, Jun 12, 2017 at 9:15 PM Dean Michael Berris via Phabricator <
revi...@reviews.llvm.org> wrote:

> dberris added a reviewer: dblaikie.
> dberris added a subscriber: dblaikie.
> dberris added a comment.
>
> @dblaikie -- do you have time to have a look?
>

Sure sure - no need to ping a patch more than about weekly. If it's
addressed to me I'll pretty reliably see it & get to it when I have time. (:

- Dave


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

Re: r305665 - clang-format: Add capability to format the diff on save in vim.

[David Blaikie via cfe-commits]

On Mon, Jun 19, 2017 at 12:30 AM Daniel Jasper via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: djasper
> Date: Mon Jun 19 02:30:04 2017
> New Revision: 305665
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305665&view=rev
> Log:
> clang-format: Add capability to format the diff on save in vim.
>
> With this patch, one can configure a BufWrite hook that will make the
> clang-format integration compute a diff of the current buffer with the file
> that's on disk and format all changed lines. This should create a
> zero-overhead auto-format solution that doesn't require the file to
> already be clang-format clean to avoid spurious diffs.
>
> Review: https://reviews.llvm.org/D32429
>
> Modified:
> cfe/trunk/docs/ClangFormat.rst
> cfe/trunk/tools/clang-format/clang-format.py
>
> Modified: cfe/trunk/docs/ClangFormat.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangFormat.rst?rev=305665&r1=305664&r2=305665&view=diff
>
> ==
> --- cfe/trunk/docs/ClangFormat.rst (original)
> +++ cfe/trunk/docs/ClangFormat.rst Mon Jun 19 02:30:04 2017
> @@ -120,6 +120,18 @@ entity.
>  It operates on the current, potentially unsaved buffer and does not create
>  or save any files. To revert a formatting, just undo.
>
> +An alternative option is to format changes when saving a file and thus to
> +have a zero-effort integration into the coding workflow. To do this, add
> this to
> +your `.vimrc`:
> +
> +.. code-block:: vim
> +
> +  function! Formatonsave()
> +let l:formatdiff = 1
> +pyf ~/llvm/tools/clang/tools/clang-format/clang-format.py
> +  endfunction
> +  autocmd BufWritePre *.h,*.cc,*.cpp call Formatonsave()
>

A cursory experiment with this didn't seem to quite do what I was
expecting. Am I holding it wrong?

Opened a file containing this:

void f3();
__attribute__((used)) inline void f1() {
  f3();
}
__attribute__((used)) inline void f2() {
  f1();
}

I removed a space from the beginining of line 3 (the call to f3()) and then
removed a space from between "f2()" and "{" on line 5.

I edited edit-mode and ran ":w" - only the second edit location was
reformatted. The f3() call remained indented with one space.

When I move the cursor up to line 3 (or 2 or 4) and save, it reformats that
line.

Indeed even if I don't modify anything, and run ":w" on lines 2-7, it
reformats either f1 or f2, depending on which range the cursor is in when I
write the file.?


> +
>
>  Emacs Integration
>  =
>
> Modified: cfe/trunk/tools/clang-format/clang-format.py
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/clang-format.py?rev=305665&r1=305664&r2=305665&view=diff
>
> ==
> --- cfe/trunk/tools/clang-format/clang-format.py (original)
> +++ cfe/trunk/tools/clang-format/clang-format.py Mon Jun 19 02:30:04 2017
> @@ -63,8 +63,19 @@ def main():
># Determine range to format.
>if vim.eval('exists("l:lines")') == '1':
>  lines = vim.eval('l:lines')
> +  elif vim.eval('exists("l:formatdiff")') == '1':
> +with open(vim.current.buffer.name, 'r') as f:
> +  ondisk = f.read().splitlines();
> +sequence = difflib.SequenceMatcher(None, ondisk, vim.current.buffer)
> +lines = []
> +for op in reversed(sequence.get_opcodes()):
> +  if op[0] not in ['equal', 'delete']:
> +lines += ['-lines', '%s:%s' % (op[3] + 1, op[4])]
> +if lines == []:
> +  return
>else:
> -lines = '%s:%s' % (vim.current.range.start + 1, vim.current.range.end
> + 1)
> +lines = ['-lines', '%s:%s' % (vim.current.range.start + 1,
> +  vim.current.range.end + 1)]
>
># Determine the cursor position.
>cursor = int(vim.eval('line2byte(line("."))+col(".")')) - 2
> @@ -82,7 +93,7 @@ def main():
># Call formatter.
>command = [binary, '-style', style, '-cursor', str(cursor)]
>if lines != 'all':
> -command.extend(['-lines', lines])
> +command += lines
>if fallback_style:
>  command.extend(['-fallback-style', fallback_style])
>if vim.current.buffer.name:
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r305665 - clang-format: Add capability to format the diff on save in vim.

[David Blaikie via cfe-commits]

Ah, nevermind - I hadn't sync'd this change! Sorry for the noise.

Thanks for the feature!

On Mon, Jun 19, 2017 at 11:18 AM David Blaikie  wrote:

> On Mon, Jun 19, 2017 at 12:30 AM Daniel Jasper via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: djasper
>> Date: Mon Jun 19 02:30:04 2017
>> New Revision: 305665
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=305665&view=rev
>> Log:
>> clang-format: Add capability to format the diff on save in vim.
>>
>> With this patch, one can configure a BufWrite hook that will make the
>> clang-format integration compute a diff of the current buffer with the
>> file
>> that's on disk and format all changed lines. This should create a
>> zero-overhead auto-format solution that doesn't require the file to
>> already be clang-format clean to avoid spurious diffs.
>>
>> Review: https://reviews.llvm.org/D32429
>>
>> Modified:
>> cfe/trunk/docs/ClangFormat.rst
>> cfe/trunk/tools/clang-format/clang-format.py
>>
>> Modified: cfe/trunk/docs/ClangFormat.rst
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangFormat.rst?rev=305665&r1=305664&r2=305665&view=diff
>>
>> ==
>> --- cfe/trunk/docs/ClangFormat.rst (original)
>> +++ cfe/trunk/docs/ClangFormat.rst Mon Jun 19 02:30:04 2017
>> @@ -120,6 +120,18 @@ entity.
>>  It operates on the current, potentially unsaved buffer and does not
>> create
>>  or save any files. To revert a formatting, just undo.
>>
>> +An alternative option is to format changes when saving a file and thus to
>> +have a zero-effort integration into the coding workflow. To do this, add
>> this to
>> +your `.vimrc`:
>> +
>> +.. code-block:: vim
>> +
>> +  function! Formatonsave()
>> +let l:formatdiff = 1
>> +pyf ~/llvm/tools/clang/tools/clang-format/clang-format.py
>> +  endfunction
>> +  autocmd BufWritePre *.h,*.cc,*.cpp call Formatonsave()
>>
>
> A cursory experiment with this didn't seem to quite do what I was
> expecting. Am I holding it wrong?
>
> Opened a file containing this:
>
> void f3();
> __attribute__((used)) inline void f1() {
>   f3();
> }
> __attribute__((used)) inline void f2() {
>   f1();
> }
>
> I removed a space from the beginining of line 3 (the call to f3()) and
> then removed a space from between "f2()" and "{" on line 5.
>
> I edited edit-mode and ran ":w" - only the second edit location was
> reformatted. The f3() call remained indented with one space.
>
> When I move the cursor up to line 3 (or 2 or 4) and save, it reformats
> that line.
>
> Indeed even if I don't modify anything, and run ":w" on lines 2-7, it
> reformats either f1 or f2, depending on which range the cursor is in when I
> write the file.?
>
>
>> +
>>
>>  Emacs Integration
>>  =
>>
>> Modified: cfe/trunk/tools/clang-format/clang-format.py
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/clang-format.py?rev=305665&r1=305664&r2=305665&view=diff
>>
>> ==
>> --- cfe/trunk/tools/clang-format/clang-format.py (original)
>> +++ cfe/trunk/tools/clang-format/clang-format.py Mon Jun 19 02:30:04 2017
>> @@ -63,8 +63,19 @@ def main():
>># Determine range to format.
>>if vim.eval('exists("l:lines")') == '1':
>>  lines = vim.eval('l:lines')
>> +  elif vim.eval('exists("l:formatdiff")') == '1':
>> +with open(vim.current.buffer.name, 'r') as f:
>> +  ondisk = f.read().splitlines();
>> +sequence = difflib.SequenceMatcher(None, ondisk, vim.current.buffer)
>> +lines = []
>> +for op in reversed(sequence.get_opcodes()):
>> +  if op[0] not in ['equal', 'delete']:
>> +lines += ['-lines', '%s:%s' % (op[3] + 1, op[4])]
>> +if lines == []:
>> +  return
>>else:
>> -lines = '%s:%s' % (vim.current.range.start + 1,
>> vim.current.range.end + 1)
>> +lines = ['-lines', '%s:%s' % (vim.current.range.start + 1,
>> +  vim.current.range.end + 1)]
>>
>># Determine the cursor position.
>>cursor = int(vim.eval('line2byte(line("."))+col(".")')) - 2
>> @@ -82,7 +93,7 @@ def main():
>># Call formatter.
>>command = [binary, '-style', style, '-cursor', str(cursor)]
>>if lines != 'all':
>> -command.extend(['-lines', lines])
>> +command += lines
>>if fallback_style:
>>  command.extend(['-fallback-style', fallback_style])
>>if vim.current.buffer.name:
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

Ping (+Manuel, perhaps he's got some ideas about this, given background in
the tooling & compilation database work, or could point this to someone who
does?)

On Thu, Jun 15, 2017 at 10:40 AM David Blaikie  wrote:

> https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
>
> If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (& have a
> sufficiently recent cmake), then CMake will generate a
> compile_commands.json in the root of the build tree. The test finds this &
> fails, instead of finding no compilation database & succeeding.
>
> (to use this, you can then symlink from the root of the source tree to
> point to this in your build tree - this is how I get YCM to work for my
> LLVM builds & could work for other clang tools as well)
>
> On Thu, Jun 15, 2017 at 7:51 AM Serge Pavlov  wrote:
>
>> 2017-06-15 2:43 GMT+07:00 David Blaikie :
>>
>>>
>>>
>>> On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov  wrote:
>>>
 2017-06-14 4:24 GMT+07:00 David Blaikie :

> Ah, I find that the test passes if I remove the compile_commands.json
> file from my build directory (I have Ninja configured to generate a
> compile_commands.json file).
>
> Looks like what happens is it finds the compilation database and fails
> hard when the database doesn't contain a compile command for the file in
> question. If the database is not found, it falls back to some basic 
> command
> behavior, perhaps?
>
>
 You are right, constructor of `CommonOptionsParser` calls
 `autoDetectFromSource` or `autoDetectFromDirectory` prior to final
 construction of `FixedCompilationDatabase.

 Is there some way this test could be fixed to cope with this, otherwise
> it seems to get in the way of people actually using clang tools in their
> LLVM/Clang build environment?
>
>
 IIUC, presence of stale compilation database file in test directory
 could break many tests. I don't understand why only diagnostic.cpp fails,
 probably there is something wrong with the clang-tidy application cleanup
 in this case?

>>>
>>> Except it's neither stale nor in the test directory.
>>>
>>> It's the up to date/useful/used compile_commands.json generated by ninja
>>> in the root of the build tree.
>>>
>>
>> I miss something. If I could reproduce the problem, I would investigate
>> it.
>>
>>
>>>
>>>

> On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov 
> wrote:
>
>> I cannot reproduce such fail, so I can only guess how changes made in
>> https://reviews.llvm.org/rL303756 and
>> https://reviews.llvm.org/rL303741 could cause such problem. Behavior
>> of `Driver::BuildCompilation` is changed so that it returns null pointer 
>> if
>> errors occur during driver argument parse. It is called in
>> `CompilationDatabase.cpp` from `stripPositionalArgs`. The call stack at
>> this point is:
>> stripPositionalArgs
>> clang::tooling::FixedCompilationDatabase::loadFromCommandLine
>> clang::tooling::CommonOptionsParser::CommonOptionsParser
>> clang::tidy::clangTidyMain
>> main
>> `FixedCompilationDatabase::loadFromCommandLine` returns null and
>> CommonOptionsParser uses another method to create compilation database. 
>> The
>> output "Compile command not found" means that no input file were found in
>> `ClangTool::run`. Maybe some file names are nulls?
>>
>>
>> Thanks,
>> --Serge
>>
>> 2017-06-13 3:42 GMT+07:00 David Blaikie :
>>
>>> I've been seeing errors from this test recently:
>>>
>>> Command Output (stderr):
>>> --
>>> 1 error generated.
>>> Error while processing
>>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.nonexistent.cpp.
>>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp:10:12:
>>> error: expected string not found in input
>>> // CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from
>>> 'double' to 'int' changes value from 1.5 to 1
>>> [clang-diagnostic-literal-conversion]
>>>^
>>> :2:1: note: scanning from here
>>> Skipping
>>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
>>> Compile command not found.
>>> ^
>>> :2:1: note: with expression "@LINE+2" equal to "12"
>>> Skipping
>>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.
>>> Compile command not found.
>>> ^
>>>
>>>
>>> Specifically, the output is:
>>> $ ./bin/clang-tidy
>>> -checks='-*,clang-diagnostic-*,google-explicit-constructor'
>>> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp
>>> -- -fan-unknown-option 2>&1error: unknown
>>> argument: '-fan-unknown-option'

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

On Sat, Jun 24, 2017 at 10:08 AM Serge Pavlov  wrote:

> With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json is
> created in the directory
> /tools/clang/tools/extra/test/clang-tidy/Output, but the tests
> from /llvm/tools/clang/tools/extra/test/clang-tidy run in the
> directory /tools/clang/tools/extra/test/clang-tidy, which does
> not contain json files. So the test passes successfully. Ubuntu 16.04,
> cmake 3.5.1.
>

At least with what I've got, the compile_commands.json ends up in the root
of the build dir. That's using cmake 3.7.2 and Ninja 1.7.2.

Are you using Ninja or the Makefiles build, perhaps that makes a difference
(or the cmake version, perhaps)?


>
> Thanks,
> --Serge
>
> 2017-06-24 9:42 GMT+07:00 David Blaikie :
>
>> Ping (+Manuel, perhaps he's got some ideas about this, given background
>> in the tooling & compilation database work, or could point this to someone
>> who does?)
>>
>>
>> On Thu, Jun 15, 2017 at 10:40 AM David Blaikie 
>> wrote:
>>
>>> https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
>>>
>>> If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (& have
>>> a sufficiently recent cmake), then CMake will generate a
>>> compile_commands.json in the root of the build tree. The test finds this &
>>> fails, instead of finding no compilation database & succeeding.
>>>
>>> (to use this, you can then symlink from the root of the source tree to
>>> point to this in your build tree - this is how I get YCM to work for my
>>> LLVM builds & could work for other clang tools as well)
>>>
>>> On Thu, Jun 15, 2017 at 7:51 AM Serge Pavlov 
>>> wrote:
>>>
 2017-06-15 2:43 GMT+07:00 David Blaikie :

>
>
> On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov 
> wrote:
>
>> 2017-06-14 4:24 GMT+07:00 David Blaikie :
>>
>>> Ah, I find that the test passes if I remove the
>>> compile_commands.json file from my build directory (I have Ninja 
>>> configured
>>> to generate a compile_commands.json file).
>>>
>>> Looks like what happens is it finds the compilation database and
>>> fails hard when the database doesn't contain a compile command for the 
>>> file
>>> in question. If the database is not found, it falls back to some basic
>>> command behavior, perhaps?
>>>
>>>
>> You are right, constructor of `CommonOptionsParser` calls
>> `autoDetectFromSource` or `autoDetectFromDirectory` prior to final
>> construction of `FixedCompilationDatabase.
>>
>> Is there some way this test could be fixed to cope with this,
>>> otherwise it seems to get in the way of people actually using clang 
>>> tools
>>> in their LLVM/Clang build environment?
>>>
>>>
>> IIUC, presence of stale compilation database file in test directory
>> could break many tests. I don't understand why only diagnostic.cpp fails,
>> probably there is something wrong with the clang-tidy application cleanup
>> in this case?
>>
>
> Except it's neither stale nor in the test directory.
>
> It's the up to date/useful/used compile_commands.json generated by
> ninja in the root of the build tree.
>

 I miss something. If I could reproduce the problem, I would investigate
 it.


>
>
>>
>>> On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov 
>>> wrote:
>>>
 I cannot reproduce such fail, so I can only guess how changes made
 in https://reviews.llvm.org/rL303756 and
 https://reviews.llvm.org/rL303741 could cause such problem.
 Behavior of `Driver::BuildCompilation` is changed so that it returns 
 null
 pointer if errors occur during driver argument parse. It is called in
 `CompilationDatabase.cpp` from `stripPositionalArgs`. The call stack at
 this point is:
 stripPositionalArgs
 clang::tooling::FixedCompilationDatabase::loadFromCommandLine
 clang::tooling::CommonOptionsParser::CommonOptionsParser
 clang::tidy::clangTidyMain
 main
 `FixedCompilationDatabase::loadFromCommandLine` returns null and
 CommonOptionsParser uses another method to create compilation 
 database. The
 output "Compile command not found" means that no input file were found 
 in
 `ClangTool::run`. Maybe some file names are nulls?


 Thanks,
 --Serge

 2017-06-13 3:42 GMT+07:00 David Blaikie :

> I've been seeing errors from this test recently:
>
> Command Output (stderr):
> --
> 1 error generated.
> Error while processing
> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.nonexistent.cpp.
> /usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp:10:12:
> error: expected string not found i

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

On Sat, Jun 24, 2017 at 10:08 AM Serge Pavlov  wrote:

> With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json is
> created in the directory
> /tools/clang/tools/extra/test/clang-tidy/Output,
>

I'd be really surprised if this is the case - why would
cmake/ninja/makefiles put the compile commands for the whole LLVM
project/build in that somewhat random subdirectory?


> but the tests from /llvm/tools/clang/tools/extra/test/clang-tidy
> run in the directory /tools/clang/tools/extra/test/clang-tidy,
> which does not contain json files. So the test passes successfully. Ubuntu
> 16.04, cmake 3.5.1.
>

Ah, perhaps you found a compile_commands for one of the test cases, not the
one generated by CMake. CMake 3.5.1 doesn't support
CMAKE_EXPORT_COMPILE_COMMANDS.

It was added in 3.5.2, according to the documentation:
https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html


>
> Thanks,
> --Serge
>
> 2017-06-24 9:42 GMT+07:00 David Blaikie :
>
>> Ping (+Manuel, perhaps he's got some ideas about this, given background
>> in the tooling & compilation database work, or could point this to someone
>> who does?)
>>
>>
>> On Thu, Jun 15, 2017 at 10:40 AM David Blaikie 
>> wrote:
>>
>>> https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
>>>
>>> If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (& have
>>> a sufficiently recent cmake), then CMake will generate a
>>> compile_commands.json in the root of the build tree. The test finds this &
>>> fails, instead of finding no compilation database & succeeding.
>>>
>>> (to use this, you can then symlink from the root of the source tree to
>>> point to this in your build tree - this is how I get YCM to work for my
>>> LLVM builds & could work for other clang tools as well)
>>>
>>> On Thu, Jun 15, 2017 at 7:51 AM Serge Pavlov 
>>> wrote:
>>>
 2017-06-15 2:43 GMT+07:00 David Blaikie :

>
>
> On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov 
> wrote:
>
>> 2017-06-14 4:24 GMT+07:00 David Blaikie :
>>
>>> Ah, I find that the test passes if I remove the
>>> compile_commands.json file from my build directory (I have Ninja 
>>> configured
>>> to generate a compile_commands.json file).
>>>
>>> Looks like what happens is it finds the compilation database and
>>> fails hard when the database doesn't contain a compile command for the 
>>> file
>>> in question. If the database is not found, it falls back to some basic
>>> command behavior, perhaps?
>>>
>>>
>> You are right, constructor of `CommonOptionsParser` calls
>> `autoDetectFromSource` or `autoDetectFromDirectory` prior to final
>> construction of `FixedCompilationDatabase.
>>
>> Is there some way this test could be fixed to cope with this,
>>> otherwise it seems to get in the way of people actually using clang 
>>> tools
>>> in their LLVM/Clang build environment?
>>>
>>>
>> IIUC, presence of stale compilation database file in test directory
>> could break many tests. I don't understand why only diagnostic.cpp fails,
>> probably there is something wrong with the clang-tidy application cleanup
>> in this case?
>>
>
> Except it's neither stale nor in the test directory.
>
> It's the up to date/useful/used compile_commands.json generated by
> ninja in the root of the build tree.
>

 I miss something. If I could reproduce the problem, I would investigate
 it.


>
>
>>
>>> On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov 
>>> wrote:
>>>
 I cannot reproduce such fail, so I can only guess how changes made
 in https://reviews.llvm.org/rL303756 and
 https://reviews.llvm.org/rL303741 could cause such problem.
 Behavior of `Driver::BuildCompilation` is changed so that it returns 
 null
 pointer if errors occur during driver argument parse. It is called in
 `CompilationDatabase.cpp` from `stripPositionalArgs`. The call stack at
 this point is:
 stripPositionalArgs
 clang::tooling::FixedCompilationDatabase::loadFromCommandLine
 clang::tooling::CommonOptionsParser::CommonOptionsParser
 clang::tidy::clangTidyMain
 main
 `FixedCompilationDatabase::loadFromCommandLine` returns null and
 CommonOptionsParser uses another method to create compilation 
 database. The
 output "Compile command not found" means that no input file were found 
 in
 `ClangTool::run`. Maybe some file names are nulls?


 Thanks,
 --Serge

 2017-06-13 3:42 GMT+07:00 David Blaikie :

> I've been seeing errors from this test recently:
>
> Command Output (stderr):
> --
> 1 error generated.
> Error while processing
> /usr/local/google/home/blaikie/dev/llvm/src/tools

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

Ah, I see now then.

I have a symlink from the root of my source directory pointing to the
compile_commands.json in my build directory.

I have this so that the vim YouCompleteMe plugin (& any other clang tools)
can find it, as they usually should, for using tools with the llvm/clang
project...

Sounds like this test is incompatible with using the tooling infrastructure
in the llvm/clang project?

On Sun, Jun 25, 2017, 10:24 AM Serge Pavlov  wrote:

> 2017-06-25 0:52 GMT+07:00 David Blaikie :
>
>>
>>
>> On Sat, Jun 24, 2017 at 10:08 AM Serge Pavlov 
>> wrote:
>>
>>> With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json is
>>> created in the directory
>>> /tools/clang/tools/extra/test/clang-tidy/Output,
>>>
>>
>> I'd be really surprised if this is the case - why would
>> cmake/ninja/makefiles put the compile commands for the whole LLVM
>> project/build in that somewhat random subdirectory?
>>
>
> I was wrong, these json files were not created by cmake run but appear
> during test run. The file created by cmake is in the build root.
>
>
>>
>>
>>> but the tests from
>>> /llvm/tools/clang/tools/extra/test/clang-tidy run in the
>>> directory /tools/clang/tools/extra/test/clang-tidy, which does
>>> not contain json files. So the test passes successfully. Ubuntu 16.04,
>>> cmake 3.5.1.
>>>
>>
>> Ah, perhaps you found a compile_commands for one of the test cases, not
>> the one generated by CMake. CMake 3.5.1 doesn't support
>> CMAKE_EXPORT_COMPILE_COMMANDS.
>>
>> It was added in 3.5.2, according to the documentation:
>> https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html
>>
>>
>
> It was added in 2.8.5 according to documentation (
> http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems),
> at least the version 3.5.1 creates compilation databases.
>
> clang-tidy tries to create compilation database from source path, looking
> for compile_commands.json in the directory where provided source file
> resides and in all its parent directories. If source tree is in a
> subdirectory of build tree, then compile_commands.json in the build
> directory would be found and the test would fail. Is it your case?
>
>
>>> Thanks,
>>> --Serge
>>>
>>> 2017-06-24 9:42 GMT+07:00 David Blaikie :
>>>
 Ping (+Manuel, perhaps he's got some ideas about this, given background
 in the tooling & compilation database work, or could point this to someone
 who does?)


 On Thu, Jun 15, 2017 at 10:40 AM David Blaikie 
 wrote:

> https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
>
> If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (&
> have a sufficiently recent cmake), then CMake will generate a
> compile_commands.json in the root of the build tree. The test finds this &
> fails, instead of finding no compilation database & succeeding.
>
> (to use this, you can then symlink from the root of the source tree to
> point to this in your build tree - this is how I get YCM to work for my
> LLVM builds & could work for other clang tools as well)
>
> On Thu, Jun 15, 2017 at 7:51 AM Serge Pavlov 
> wrote:
>
>> 2017-06-15 2:43 GMT+07:00 David Blaikie :
>>
>>>
>>>
>>> On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov 
>>> wrote:
>>>
 2017-06-14 4:24 GMT+07:00 David Blaikie :

> Ah, I find that the test passes if I remove the
> compile_commands.json file from my build directory (I have Ninja 
> configured
> to generate a compile_commands.json file).
>
> Looks like what happens is it finds the compilation database and
> fails hard when the database doesn't contain a compile command for 
> the file
> in question. If the database is not found, it falls back to some basic
> command behavior, perhaps?
>
>
 You are right, constructor of `CommonOptionsParser` calls
 `autoDetectFromSource` or `autoDetectFromDirectory` prior to final
 construction of `FixedCompilationDatabase.

 Is there some way this test could be fixed to cope with this,
> otherwise it seems to get in the way of people actually using clang 
> tools
> in their LLVM/Clang build environment?
>
>
 IIUC, presence of stale compilation database file in test directory
 could break many tests. I don't understand why only diagnostic.cpp 
 fails,
 probably there is something wrong with the clang-tidy application 
 cleanup
 in this case?

>>>
>>> Except it's neither stale nor in the test directory.
>>>
>>> It's the up to date/useful/used compile_commands.json generated by
>>> ninja in the root of the build tree.
>>>
>>
>> I miss something. If I could reproduce the problem, I would
>> investigate it.
>>
>>
>>>
>>>
>>

Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator <
revi...@reviews.llvm.org> wrote:

> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>
> > Philosophically, mangled names and DWARF information serve different
> purposes, and I don't think you will find one true solution where both of
> them can yield the same name that everyone will be happy with.  Mangled
> names exist to provide unique and reproducible identifiers for the "same"
> entity across compilation units.  They are carefully specified (for
> example) to allow a linker to associate a reference in one object file to a
> definition in a different object file, and be guaranteed that the
> association is correct.  A demangled name is a necessarily context-free
> translation of the mangled name into something that has a closer
> relationship to how a human would think of or write the name of the thing,
> but isn't necessarily the only way to write the name of the thing.
> >
> > DWARF names are (deliberately not carefully specified) strings that
> ought to bear some relationship to how source code would name the thing,
> but you probably don't want to attach semantic significance to those
> names.  This is rather emphatically true for names containing template
> parameters.  Typedefs (and their recent offspring, 'using' aliases) are
> your sworn enemy here.  Enums, as you have found, are also a problem.
> >
> > Basically, the type of an entity does not have a unique name, and trying
> to coerce different representations of the type into having the same unique
> name is a losing battle.
>

I'm actually going back and forth on this ^. It seems to me, regardless of
mangled names, etc, it'd be good if LLVM used the same name for a type in
DWARF across different translation units. And, to a large extent, we do
(the case of typedefs in template parameters doesn't seem to present a
problem for the current implementation - the underlying type is used),
enums being one place where we don't - and we don't actually make it that
much closer to the source/based on what the user wrote.

Even if the user had: "enum X { Y = 0, Z = 0; } ... template struct
foo; ... foo" LLVM still describes that type as "foo". Also if you
have "enum X: int; ... foo<(X)0>" you get "foo<0>" whereas in another
translation unit with a definition of X you'd get "foo".

So for consistency there, I kind of think maybe a change like this isn't
bad.

But of course the specific way a template name is written may easily still
vary between compilers, so relying on it being exactly the same might not
be a great idea anyway...


> Thank you for clarification, Paul! Nevertheless, I suppose, showing actual
> type of a dynamic variable is very important for the projects, where RTTI
> is used. Moreover, it works properly in gcc+gdb pair, so I am extremely
> interested in fixing it in clang+lldb.
>
> I understand that the suggested solution possibly does not cover all the
> cases, but it improves the situation and actually covers all the cases
> found by me (I have just rechecked -- typedefs/usings seems to work fine
> when displaying the real type of variable). If more cases are found in
> future, they could be fixed similarly too. Moreover, the debuggers already
> rely on the fact that the type name looks the same in RTTI and DWARF, and I
> suppose they have no choice, because there is no other source of
> information for them (or am I missing something?).


I think they would have a choice, actually - let's walk through it...

It sounds like you're thinking of two other possibilities:

1) "I suppose, we cannot extend RTTI with the debug type name (is it
correct?)" - yeah, that's probably correct, extending the RTTI format
probably isn't desirable and we'd still need a singular/canonical DWARF
name which we don't seem to have (& the RTTI might go in another object
file that may not have debug info, or debug info generated by a different
compiler with a different type printing format, etc... )

2) Extending DWARF to include the mangled name
Sort of possible, DW_AT_linkage_name on a DW_AT_class could be used for
this just fine - no DWARF extension required.

But an alternative would be to have debuggers use a more semantically aware
matching here. The debugger does have enough information in the DWARF to
semantically match "foo<(X)0>" with "foo". enum X is in the DWARF,
and the enumerator Y is present with its value 0.

Another case of Clang's DWARF type printing differing from a common
demangling, is an unsigned parameter. template foo; foo<0> -
common demangling for this is "foo<0u>" but Clang will happily render the
type as "foo<0>" - this one seems less easy to justify changing than the
enum case (the enum case, given the declared-but-not-defined enum example,
seems more compelling to try to have clang give a consistent name to the
type (which, while not complete (differing compilers could still use
different printings), seems somewhat desirable)) because i

Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

On Fri, Dec 15, 2017 at 8:09 AM xgsa  wrote:

> David, thank you for the detailed answer and corner cases.
>
> Just to clarify: everywhere in my mail where I mentioned "debugger", I
> meant LLDB, but not GDB (except, where I mentioned GDB explicitly).
> Currently, I have no plans to work on GDB, however I would like to make the
> clang+LLDB pair working in such cases.
>

*nod* My concern is making sure, if possible, we figure out a design that
seems viable long-term/in general. (& if we figure out what that design is,
but decide it's not achievable immediately, we can make deliberate
tradeoffs, document the long term goal & what the short term solutions cost
relative to that goal, etc)


> Thus, I have described your idea in the lldb-dev mailing list [1]. Still,
> I have some concerns about the performance of such semantically aware
> matching. Currently, with acceleration tables (e.g. apple_types etc) the
> matching is as fast as lookup in hash map and hash map is loade almost
> without postprocessing. Semantically aware matching will require either
> processing during statup or almost linear lookup.
>

Yep, I agree - that seems like a reasonable concern. I wonder whether it'd
be reasonable to put accelerator table entries containing the base name of
the template to ease such lookup?


>  Still, should this topic be raised in cde-dev or are all the interested
> people already here?
>

Yeah, might be worth moving this to a thread there. Though we probably have
all the right people here, it's a better spot for the conversation even for
spectators, history (finding this later when we have similar questions,
etc), etc.


>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html
>
> 14.12.2017, 22:40, "David Blaikie" :
>
>
> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>
> > Philosophically, mangled names and DWARF information serve different
> purposes, and I don't think you will find one true solution where both of
> them can yield the same name that everyone will be happy with.  Mangled
> names exist to provide unique and reproducible identifiers for the "same"
> entity across compilation units.  They are carefully specified (for
> example) to allow a linker to associate a reference in one object file to a
> definition in a different object file, and be guaranteed that the
> association is correct.  A demangled name is a necessarily context-free
> translation of the mangled name into something that has a closer
> relationship to how a human would think of or write the name of the thing,
> but isn't necessarily the only way to write the name of the thing.
> >
> > DWARF names are (deliberately not carefully specified) strings that
> ought to bear some relationship to how source code would name the thing,
> but you probably don't want to attach semantic significance to those
> names.  This is rather emphatically true for names containing template
> parameters.  Typedefs (and their recent offspring, 'using' aliases) are
> your sworn enemy here.  Enums, as you have found, are also a problem.
> >
> > Basically, the type of an entity does not have a unique name, and trying
> to coerce different representations of the type into having the same unique
> name is a losing battle.
>
>
> I'm actually going back and forth on this ^. It seems to me, regardless of
> mangled names, etc, it'd be good if LLVM used the same name for a type in
> DWARF across different translation units. And, to a large extent, we do
> (the case of typedefs in template parameters doesn't seem to present a
> problem for the current implementation - the underlying type is used),
> enums being one place where we don't - and we don't actually make it that
> much closer to the source/based on what the user wrote.
>
> Even if the user had: "enum X { Y = 0, Z = 0; } ... template
> struct foo; ... foo" LLVM still describes that type as "foo". Also
> if you have "enum X: int; ... foo<(X)0>" you get "foo<0>" whereas in
> another translation unit with a definition of X you'd get "foo".
>
> So for consistency there, I kind of think maybe a change like this isn't
> bad.
>
> But of course the specific way a template name is written may easily still
> vary between compilers, so relying on it being exactly the same might not
> be a great idea anyway...
>
>
> Thank you for clarification, Paul! Nevertheless, I suppose, showing actual
> type of a dynamic variable is very important for the projects, where RTTI
> is used. Moreover, it works properly in gcc+gdb pair, so I am extremely
> interested in fixing it in clang+lldb.
>
> I understand that the suggested solution possibly does not cover all the
> cases, but it improves the situation and actually covers all the cases
> found by me (I have just rechecked -- typedefs/usings seems to work fine
> when displaying the real type of variable). If more cases are found

Re: [clang-tools-extra] r320591 - [clangd] Fix bool conversion operator of UniqueFunction

[David Blaikie via cfe-commits]

This operator bool should probably be explicit (as most/all of them should
be - and most of them in LLVM are) - to avoid undue implicit conversion to
other int types.

On Wed, Dec 13, 2017 at 7:43 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ibiryukov
> Date: Wed Dec 13 07:42:59 2017
> New Revision: 320591
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320591&view=rev
> Log:
> [clangd] Fix bool conversion operator of UniqueFunction
>
> Usages of it were giving compiler errors because of the missing
> explicit conversion.
>
> Modified:
> clang-tools-extra/trunk/clangd/Function.h
>
> Modified: clang-tools-extra/trunk/clangd/Function.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Function.h?rev=320591&r1=320590&r2=320591&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/Function.h (original)
> +++ clang-tools-extra/trunk/clangd/Function.h Wed Dec 13 07:42:59 2017
> @@ -49,7 +49,7 @@ public:
>  FunctionCallImpl std::decay::type>>(
>  std::forward(Func))) {}
>
> -  operator bool() { return CallablePtr; }
> +  operator bool() { return bool(CallablePtr); }
>
>Ret operator()(Args... As) {
>  assert(CallablePtr);
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

Yep, could be worth having a conversation with the GDB folks and/or at
least poke the other LLVM debug info folks (Adrian and Paul - Paul's pretty
interesting since he works with/on another (not LLDB nor GDB) debugger
which would have to think about this
functionality/feature/issue/data/limitation)

On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov  wrote:

> There was a discussion in lldb-dev mailing list on this topic and I
> suppose a reliable solution was suggested [1]. It is to generate
> DW_AT_linkage_name for vtable DIE of a class and provide an additional
> accelerator table. I am going to try to implement this approach (it will
> require some work on both clang and lldb sides), but I'd like also to
> understand if I should discard or complete the current patch. Certainly,
> I'd prefer to complete it if it could be applied (I suppose, at least
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:25, David Blaikie via cfe-commits wrote:
> >
> >
> > On Fri, Dec 15, 2017 at 8:09 AM xgsa  > <mailto:x...@yandex.ua>> wrote:
> >
> > David, thank you for the detailed answer and corner cases.
> > Just to clarify: everywhere in my mail where I mentioned
> > "debugger", I meant LLDB, but not GDB (except, where I mentioned
> > GDB explicitly). Currently, I have no plans to work on GDB,
> > however I would like to make the clang+LLDB pair working in such
> > cases.
> >
> >
> > *nod* My concern is making sure, if possible, we figure out a design
> > that seems viable long-term/in general. (& if we figure out what that
> > design is, but decide it's not achievable immediately, we can make
> > deliberate tradeoffs, document the long term goal & what the short
> > term solutions cost relative to that goal, etc)
> >
> > Thus, I have described your idea in the lldb-dev mailing list [1].
> > Still, I have some concerns about the performance of such
> > semantically aware matching. Currently, with acceleration tables
> > (e.g. apple_types etc) the matching is as fast as lookup in hash
> > map and hash map is loade almost without postprocessing.
> > Semantically aware matching will require either processing during
> > statup or almost linear lookup.
> >
> >
> > Yep, I agree - that seems like a reasonable concern. I wonder whether
> > it'd be reasonable to put accelerator table entries containing the
> > base name of the template to ease such lookup?
> >
> >  Still, should this topic be raised in cde-dev or are all the
> > interested people already here?
> >
> >
> > Yeah, might be worth moving this to a thread there. Though we probably
> > have all the right people here, it's a better spot for the
> > conversation even for spectators, history (finding this later when we
> > have similar questions, etc), etc.
> >
> > [1] -
> > http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html
> > 14.12.2017, 22:40, "David Blaikie"  > <mailto:dblai...@gmail.com>>:
> >> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
> >> mailto:revi...@reviews.llvm.org>> wrote:
> >>
> >> xgsa added a comment.
> >>
> >> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
> >>
> >> > Philosophically, mangled names and DWARF information serve
> >> different purposes, and I don't think you will find one true
> >> solution where both of them can yield the same name that
> >> everyone will be happy with.  Mangled names exist to provide
> >> unique and reproducible identifiers for the "same" entity
> >> across compilation units.  They are carefully specified (for
> >> example) to allow a linker to associate a reference in one
> >> object file to a definition in a different object file, and
> >> be guaranteed that the association is correct.  A demangled
> >> name is a necessarily context-free translation of the mangled
> >> name into something that has a closer relationship to how a
> >> human would think of or write the name of the thing, but
> >> isn't necessarily the only way to write the name of the thing.
> >> >
> 

Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

Not much - I've put them on this part of the thread specifically to raise
attention.

If it doesn't get visibility here, maybe a cfe-dev thread would be good.



On Tue, Dec 19, 2017 at 1:33 PM Anton Gorenkov  wrote:

> Sorry, I am quite new to the process. It seems, Adrian and Paul are in the
> reviewers/subscribers list to the original review (
> https://reviews.llvm.org/D39622). Should I do something else?
> 19.12.2017 23:06, David Blaikie wrote:
>
> Yep, could be worth having a conversation with the GDB folks and/or at
> least poke the other LLVM debug info folks (Adrian and Paul - Paul's pretty
> interesting since he works with/on another (not LLDB nor GDB) debugger
> which would have to think about this
> functionality/feature/issue/data/limitation)
>
> On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov  wrote:
>
>> There was a discussion in lldb-dev mailing list on this topic and I
>> suppose a reliable solution was suggested [1]. It is to generate
>> DW_AT_linkage_name for vtable DIE of a class and provide an additional
>> accelerator table. I am going to try to implement this approach (it will
>> require some work on both clang and lldb sides), but I'd like also to
>> understand if I should discard or complete the current patch. Certainly,
>> I'd prefer to complete it if it could be applied (I suppose, at least
>> tests should be added), because even with long term solution implemented
>> in clang/lldb, gdb still won't resolve dynamic types properly for the
>> described cases.
>>
>> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>>
>> 15.12.2017 21:25, David Blaikie via cfe-commits wrote:
>> >
>> >
>> > On Fri, Dec 15, 2017 at 8:09 AM xgsa > > <mailto:x...@yandex.ua>> wrote:
>> >
>> > David, thank you for the detailed answer and corner cases.
>> > Just to clarify: everywhere in my mail where I mentioned
>> > "debugger", I meant LLDB, but not GDB (except, where I mentioned
>> > GDB explicitly). Currently, I have no plans to work on GDB,
>> > however I would like to make the clang+LLDB pair working in such
>> > cases.
>> >
>> >
>> > *nod* My concern is making sure, if possible, we figure out a design
>> > that seems viable long-term/in general. (& if we figure out what that
>> > design is, but decide it's not achievable immediately, we can make
>> > deliberate tradeoffs, document the long term goal & what the short
>> > term solutions cost relative to that goal, etc)
>> >
>> > Thus, I have described your idea in the lldb-dev mailing list [1].
>> > Still, I have some concerns about the performance of such
>> > semantically aware matching. Currently, with acceleration tables
>> > (e.g. apple_types etc) the matching is as fast as lookup in hash
>> > map and hash map is loade almost without postprocessing.
>> > Semantically aware matching will require either processing during
>> > statup or almost linear lookup.
>> >
>> >
>> > Yep, I agree - that seems like a reasonable concern. I wonder whether
>> > it'd be reasonable to put accelerator table entries containing the
>> > base name of the template to ease such lookup?
>> >
>> >  Still, should this topic be raised in cde-dev or are all the
>> > interested people already here?
>> >
>> >
>> > Yeah, might be worth moving this to a thread there. Though we probably
>> > have all the right people here, it's a better spot for the
>> > conversation even for spectators, history (finding this later when we
>> > have similar questions, etc), etc.
>> >
>> > [1] -
>> > http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html
>> > 14.12.2017, 22:40, "David Blaikie" > > <mailto:dblai...@gmail.com>>:
>> >> On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator
>> >> mailto:revi...@reviews.llvm.org>>
>> wrote:
>> >>
>> >> xgsa added a comment.
>> >>
>> >> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>> >>
>> >> > Philosophically, mangled names and DWARF information serve
>> >> different purposes, and I don't think you will find one true
>> >> solution where both of them can yield the same name that
>> >> everyone will be happy with.  Mangled

Re: [PATCH] D39622: Fix type name generation in DWARF for template instantiations with enum types and template specializations

[David Blaikie via cfe-commits]

On Tue, Dec 19, 2017 at 1:50 PM Robinson, Paul 
wrote:

> On the lldb-dev thread I thought this was a reasonable idea
> (DW_AT_linkage_name on types) but given the use-case, probably best to
> confine it to classes with vtables?  If there's a broader use-case it
> wasn't clear from the other thread;
>

Yeah, that's the only one I know of from these conversations.


> there it was reported that LLDB really only uses the mangled name for
> tracking down the type description associated with a vtable (which of
> course has a mangled name giving the type).
>

GDB seems to use it for this too - no idea if it has other uses for exact
matching of demangled symbol names with type names in DWARF.


> --paulr
>
>
>
> *From:* David Blaikie [mailto:dblai...@gmail.com]
> *Sent:* Tuesday, December 19, 2017 1:36 PM
> *To:* Anton Gorenkov; Robinson, Paul; Adrian Prantl
> *Cc:* xgsa; mlek...@skidmore.edu;
> reviews+d39622+public+b0839896b45cd...@reviews.llvm.org;
> cfe-commits@lists.llvm.org; shen...@google.com
> *Subject:* Re: [PATCH] D39622: Fix type name generation in DWARF for
> template instantiations with enum types and template specializations
>
>
>
> Not much - I've put them on this part of the thread specifically to raise
> attention.
>
> If it doesn't get visibility here, maybe a cfe-dev thread would be good.
>
>
> On Tue, Dec 19, 2017 at 1:33 PM Anton Gorenkov  wrote:
>
> Sorry, I am quite new to the process. It seems, Adrian and Paul are in the
> reviewers/subscribers list to the original review (
> https://reviews.llvm.org/D39622). Should I do something else?
>
> 19.12.2017 23:06, David Blaikie wrote:
>
> Yep, could be worth having a conversation with the GDB folks and/or at
> least poke the other LLVM debug info folks (Adrian and Paul - Paul's pretty
> interesting since he works with/on another (not LLDB nor GDB) debugger
> which would have to think about this
> functionality/feature/issue/data/limitation)
>
>
>
> On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov  wrote:
>
> There was a discussion in lldb-dev mailing list on this topic and I
> suppose a reliable solution was suggested [1]. It is to generate
> DW_AT_linkage_name for vtable DIE of a class and provide an additional
> accelerator table. I am going to try to implement this approach (it will
> require some work on both clang and lldb sides), but I'd like also to
> understand if I should discard or complete the current patch. Certainly,
> I'd prefer to complete it if it could be applied (I suppose, at least
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:25, David Blaikie via cfe-commits wrote:
> >
> >
> > On Fri, Dec 15, 2017 at 8:09 AM xgsa  > <mailto:x...@yandex.ua>> wrote:
> >
> > David, thank you for the detailed answer and corner cases.
> > Just to clarify: everywhere in my mail where I mentioned
> > "debugger", I meant LLDB, but not GDB (except, where I mentioned
> > GDB explicitly). Currently, I have no plans to work on GDB,
> > however I would like to make the clang+LLDB pair working in such
> > cases.
> >
> >
> > *nod* My concern is making sure, if possible, we figure out a design
> > that seems viable long-term/in general. (& if we figure out what that
> > design is, but decide it's not achievable immediately, we can make
> > deliberate tradeoffs, document the long term goal & what the short
> > term solutions cost relative to that goal, etc)
> >
> > Thus, I have described your idea in the lldb-dev mailing list [1].
> > Still, I have some concerns about the performance of such
> > semantically aware matching. Currently, with acceleration tables
> > (e.g. apple_types etc) the matching is as fast as lookup in hash
> > map and hash map is loade almost without postprocessing.
> > Semantically aware matching will require either processing during
> > statup or almost linear lookup.
> >
> >
> > Yep, I agree - that seems like a reasonable concern. I wonder whether
> > it'd be reasonable to put accelerator table entries containing the
> > base name of the template to ease such lookup?
> >
> >  Still, should this topic be raised in cde-dev or are all the
> > interested people already here?
> >
> >
> > Yeah, might be worth moving this to a thread there. Though we probably
> > have all the right people

Re: [clang-tools-extra] r321192 - [clangd] Remove an unused lambda capture.

[David Blaikie via cfe-commits]

Generally I'd encourage you/anyone to use [&] for any lambda that doesn't
escape its scope - avoids any issues like this & doesn't really hinder
readability imho.

On Wed, Dec 20, 2017 at 9:23 AM Eric Liu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ioeric
> Date: Wed Dec 20 09:22:56 2017
> New Revision: 321192
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321192&view=rev
> Log:
> [clangd] Remove an unused lambda capture.
>
> Modified:
> clang-tools-extra/trunk/unittests/clangd/Annotations.cpp
>
> Modified: clang-tools-extra/trunk/unittests/clangd/Annotations.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/Annotations.cpp?rev=321192&r1=321191&r2=321192&view=diff
>
> ==
> --- clang-tools-extra/trunk/unittests/clangd/Annotations.cpp (original)
> +++ clang-tools-extra/trunk/unittests/clangd/Annotations.cpp Wed Dec 20
> 09:22:56 2017
> @@ -24,7 +24,7 @@ static void require(bool Assertion, cons
>
>  Annotations::Annotations(StringRef Text) {
>auto Here = [this] { return offsetToPosition(Code, Code.size()); };
> -  auto Require = [this, Text](bool Assertion, const char *Msg) {
> +  auto Require = [Text](bool Assertion, const char *Msg) {
>  require(Assertion, Msg, Text);
>};
>Optional Name;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r321319 - [ODRHash] Canonicalize Decl's before processing.

[David Blaikie via cfe-commits]

Test case?

On Thu, Dec 21, 2017 at 2:39 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rtrieu
> Date: Thu Dec 21 14:38:29 2017
> New Revision: 321319
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321319&view=rev
> Log:
> [ODRHash] Canonicalize Decl's before processing.
>
> Canonicalizing the Decl before processing it as part of the hash should
> reduce
> issues with non-canonical types showing up as mismatches.
>
> Modified:
> cfe/trunk/lib/AST/ODRHash.cpp
>
> Modified: cfe/trunk/lib/AST/ODRHash.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ODRHash.cpp?rev=321319&r1=321318&r2=321319&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ODRHash.cpp (original)
> +++ cfe/trunk/lib/AST/ODRHash.cpp Thu Dec 21 14:38:29 2017
> @@ -468,6 +468,7 @@ void ODRHash::AddCXXRecordDecl(const CXX
>
>  void ODRHash::AddDecl(const Decl *D) {
>assert(D && "Expecting non-null pointer.");
> +  D = D->getCanonicalDecl();
>auto Result = DeclMap.insert(std::make_pair(D, DeclMap.size()));
>ID.AddInteger(Result.first->second);
>// On first encounter of a Decl pointer, process it.  Every time
> afterwards,
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D41414: [analyzer] Add keyboard j/k navigation to HTML reports

[David Blaikie via cfe-commits]

any chance this can be implemented based on keyboard layout, so it's good
for dvorak users as well? (maybe it already is, I don't know - just
mentioning it in case)

On Thu, Dec 21, 2017 at 2:58 PM George Karpenkov via Phabricator via
cfe-commits  wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rC321320: [analyzer] Add Javascript to analyzer HTML
> output to allow keyboard navigation. (authored by george.karpenkov,
> committed by ).
> Herald added a subscriber: cfe-commits.
>
> Changed prior to commit:
>   https://reviews.llvm.org/D41414?vs=127919&id=127954#toc
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D41414
>
> Files:
>   lib/Rewrite/HTMLRewrite.cpp
>   lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D41039: Add support for attribute "trivial_abi"

[David Blaikie via cfe-commits]

On Tue, Dec 19, 2017 at 9:43 PM Akira Hatanaka  wrote:

> On Tue, Dec 12, 2017 at 12:12 PM, John McCall  wrote:
>
>> On Tue, Dec 12, 2017 at 1:45 PM, David Blaikie 
>> wrote:
>>
>>> On Mon, Dec 11, 2017 at 5:38 PM John McCall  wrote:
>>>
 On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie 
 wrote:

> On Mon, Dec 11, 2017 at 3:16 PM John McCall via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> rjmccall added a comment.
>>
>> In https://reviews.llvm.org/D41039#951648, @ahatanak wrote:
>>
>> > I had a discussion with Duncan today and he pointed out that
>> perhaps we shouldn't allow users to annotate a struct with "trivial_abi" 
>> if
>> one of its subobjects is non-trivial and is not annotated with
>> "trivial_abi" since that gives users too much power.
>> >
>> > Should we error out or drop "trivial_abi" from struct Outer when
>> the following code is compiled?
>> >
>> >   struct Inner1 {
>> > ~Inner1(); // non-trivial
>> > int x;
>> >   };
>> >
>> >   struct __attribute__((trivial_abi)) Outer {
>> > ~Outer();
>> > Inner1 x;
>> >   };
>> >
>> >
>> > The current patch doesn't error out or drop the attribute, but the
>> patch would probably be much simpler if we didn't allow it.
>>
>>
>> I think it makes sense to emit an error if there is provably a
>> non-trivial-ABI component.  However, for class temploids I think that
>> diagnostic should only fire on the definition, not on instantiations; for
>> example:
>>
>>   template  struct __attribute__((trivial_abi)) holder {
>>  T value;
>>  ~holder() {}
>>   };
>>   holder hs; // this instantiation should be legal
>> despite the fact that holder cannot be trivial-ABI.
>>
>> But we should still be able to emit the diagnostic in template
>> definitions, e.g.:
>>
>>   template  struct __attribute__((trivial_abi)) named_holder
>> {
>>  std::string name; // there are no instantiations of this
>> template that could ever be trivial-ABI
>>  T value;
>>  ~named_holder() {}
>>   };
>>
>> The wording should be something akin to the standard template rule
>> that a template is ill-formed if it has no valid instantiations, no
>> diagnostic required.
>>
>> I would definitely like to open the conversation about the name of
>> the attribute.  I don't think we've used "abi" in an existing attribute
>> name; usually it's more descriptive.  And "trivial" is a weighty word in
>> the standard.  I'm not sure I have a great counter-proposal off the top 
>> of
>> my head, though.
>>
>
> Agreed on both counts (would love a better name, don't have any
> stand-out candidates off the top of my head).
>
> I feel like a more descriptive term about the property of the object
> would make me happier - something like "address_independent_identity"
> (s/identity/value/?) though, yeah, that's not spectacular by any stretch.
>

 Incidentally, your comments are not showing up on Phabricator for some
 reason.

>>>
>>> Yeah, Phab doesn't do a great job looking on the mailing list for
>>> interesting replies - I forget, maybe it only catches bottom post or top
>>> post but not infix replies or something...
>>>
>>
>> Well, fortunately the mailing list is also archived. :)
>>
>>
>>> The term "trivially movable" suggests itself, with two caveats:
   - What we're talking about is trivial *destructive* movability, i.e.
 that the combination of moving the value to a new object and not destroying
 the old object can be done trivially, which is not quite the same as
 trivial movability in the normal C++ sense, which I guess could be a
 property that someone theoretically might care about (if the type is
 trivially destructed, but it isn't copyable for semantic reasons?).
   - Trivial destructive movability is a really common property, and
 it's something that a compiler would really like to optimize based on even
 in cases where trivial_abi can't be adopted for binary-compatibility
 reasons.  Stealing the term for the stronger property that the type is
 trivially destructively movable *and its ABI should reflect that in a
 specific way* would be unfortunate.

>>>
>>> Fair point.
>>>
>>>
 "trivially_movable" is a long attribute anyway, and
 "trivially_destructively_movable" is even worse.

 Maybe that second point is telling us that this isn't purely
 descriptive — it's inherently talking about the ABI, not just the semantics
 of the type.  I might be talking myself into accepting trivial_abi if we
 don't end up with a better suggestion.

>>>
>>> *nod* I think if you want to slice this that way (ensuring there's space
>>> to support describing a similar property for use only 

Re: [PATCH] D41414: [analyzer] Add keyboard j/k navigation to HTML reports

[David Blaikie via cfe-commits]

Sure, this is post-commit review feedback.

vim with dvorak works in the sense that it's not unusable, but it's pretty
awkward (see, for example, discussions like this:
http://vim.wikia.com/wiki/Using_Vim_with_the_Dvorak_keyboard_layout )

On Tue, Jan 2, 2018 at 10:03 AM George Karpenkov 
wrote:

> This patch has already landed — also IIRC e.g. vim on dvorak also uses
> hjkl navigation with no issues.
>
>
> On Dec 25, 2017, at 11:21 AM, David Blaikie  wrote:
>
> any chance this can be implemented based on keyboard layout, so it's good
> for dvorak users as well? (maybe it already is, I don't know - just
> mentioning it in case)
>
> On Thu, Dec 21, 2017 at 2:58 PM George Karpenkov via Phabricator via
> cfe-commits  wrote:
>
>> This revision was automatically updated to reflect the committed changes.
>> Closed by commit rC321320: [analyzer] Add Javascript to analyzer HTML
>> output to allow keyboard navigation. (authored by george.karpenkov,
>> committed by ).
>> Herald added a subscriber: cfe-commits.
>>
>> Changed prior to commit:
>>   https://reviews.llvm.org/D41414?vs=127919&id=127954#toc
>>
>> Repository:
>>   rC Clang
>>
>> https://reviews.llvm.org/D41414
>>
>> Files:
>>   lib/Rewrite/HTMLRewrite.cpp
>>   lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: trivial_abi

[David Blaikie via cfe-commits]

(just a side note: perhaps this conversation would've been more suited to
cfe-dev? I sort of missed it because I only check commits once a week,
unless I'm specifically cc'd on something. All good though :))

On Wed, Jan 3, 2018 at 4:06 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 3 January 2018 at 15:24, John McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Jan 3, 2018, at 5:53 PM, Richard Smith  wrote:
>> On 3 January 2018 at 14:29, John McCall via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> On Jan 3, 2018, at 5:12 PM, Richard Smith  wrote:
>>>
>>> On 2 January 2018 at 20:55, John McCall via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Jan 2, 2018, at 10:43 PM, Richard Smith 
 wrote:

 On 2 January 2018 at 19:02, John McCall via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

>
> On Jan 2, 2018, at 9:15 PM, Akira Hatanaka 
> wrote:
>
>
>
> On Jan 2, 2018, at 4:56 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On 2 January 2018 at 15:33, John McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hey, Richard et al.  Akira and I were talking about the right ABI
>> rule for deciding can-pass-in-registers-ness for structs in the presence 
>> of
>> trivial_abi, and I think I like Akira's approach but wanted to get your
>> input.
>>
>> The current definition in Itanium is:
>>
>>   *non-trivial for the purposes of calls*
>>
>> A type is considered non-trivial for the purposes of calls if:
>>
>>- it has a non-trivial copy constructor, move constructor, or
>>destructor, or
>>
>> I'm assuming we're implicitly excluding deleted functions here. (I'd
> prefer to make that explicit; this has been the source of a number of ABI
> mismatches.)
>
>>
>>- all of its copy and move constructors are deleted.
>>
>>
>> I'd suggest modifying this to:
>>
>> A type is considered non-trivial for the purposes of calls if:
>> - if has a copy constructor, move constructor, or destructor which is
>> non-trivial for the purposes of calls, or
>> - all of its copy and move constructors are deleted and it does not
>> have the trivial_abi attribute.
>>
>> A copy/move constructor is considered trivial for the purposes of
>> calls if:
>> - it is user-provided and
>> - the class has the trivial_abi attribute and
>> - a defaulted definition of the constructor would be trivial for the
>> purposes of calls; or
>>
>
> We'd need to say what happens if the function in question cannot
> validly be defaulted for any of the reasons in [dcl.fct.def.default]. Do 
> we
> try to infer whether it's a copy or move constructor, and use the rules 
> for
> a defaulted copy or move constructor? Or do we just say that's never
> trivial for the purposes of calls? Or something else? Eg:
>
> struct [[clang::trivial_abi]] A {
>   A(A && = make());
> };
>
> Here, A::A(A&&) cannot validly be defaulted. Is A trivial for the
> purpose of calls? Likewise:
>
> struct [[clang::trivial_abi]] B {
>   B(...);
> };
> struct C {
>   volatile B b;
> };
>
> Here, C's copy constructor calls B::B(...). Is C trivial for the
> purpose of calls? (OK, Clang crashes on that example today. But still...)
>
> I'd be uncomfortable making the rules in [dcl.fct.def.default] part of
> the ABI; they seem to be changing relatively frequently. Perhaps we could
> say "if the function is a copy constructor ([class.copy.ctor]/1), then
> consider what an implicitly-declared defaulted copy constructor would do;
> if it's a move constructor ([class.copy.ctor]/2), then consider what an
> implicitly-declared defaulted move constructor would do; otherwise, it's
> not trivial for the purpose of calls". That'd mean A is trivial for the
> purpose of calls and C is not, which I think is probably the right answer.
>
> - it is not user-provided and
>> - the class has no virtual functions and no virtual base classes, and
>> - the constructor used to copy/move each direct base class subobject
>> is trivial for the purposes of calls, and
>> - for each non-static data member that is of class type (or array
>> thereof), the constructor selected to copy/move that member is trivial 
>> for
>> the purposes of calls.
>>
>> A destructor is considered trivial for the purposes of calls if:
>> - it is not user-provided or the class has the trivial_abi attribute,
>> and
>> - the destructor is not virtual, and
>> - all of the direct base classes of its class have destructors that
>> are trivial for the purposes of calls, and
>> - for all of the non-static data membe

Re: r321997 - Avoid assumption that lit tests are writable. NFC

[David Blaikie via cfe-commits]

I'm sure it's something obvious I don't understand here, but maybe someone
else doesn't either & could benefit from it:

What exactly does this change do? In what important way is "cp X Y"
different from "cat X > Y"?

On Mon, Jan 8, 2018 at 7:06 AM Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sammccall
> Date: Mon Jan  8 07:05:01 2018
> New Revision: 321997
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321997&view=rev
> Log:
> Avoid assumption that lit tests are writable. NFC
>
> Modified:
> cfe/trunk/test/ARCMT/releases-driver.m
> cfe/trunk/test/ARCMT/releases-driver.m.result
> cfe/trunk/test/ARCMT/with-arc-mode-modify.m
> cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result
> cfe/trunk/test/PCH/verify_pch.m
> cfe/trunk/test/VFS/real-path-found-first.m
>
> Modified: cfe/trunk/test/ARCMT/releases-driver.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ARCMT/releases-driver.m?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/ARCMT/releases-driver.m (original)
> +++ cfe/trunk/test/ARCMT/releases-driver.m Mon Jan  8 07:05:01 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 -fblocks -fsyntax-only -fobjc-arc -x objective-c
> %s.result
> -// RUN: cp %s %t
> +// RUN: cat %s > %t
>  // RUN: %clang_cc1 -arcmt-modify -triple x86_64-apple-macosx10.6 -x
> objective-c %t
>  // RUN: diff %t %s.result
>  // RUN: rm %t
>
> Modified: cfe/trunk/test/ARCMT/releases-driver.m.result
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ARCMT/releases-driver.m.result?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/ARCMT/releases-driver.m.result (original)
> +++ cfe/trunk/test/ARCMT/releases-driver.m.result Mon Jan  8 07:05:01 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 -fblocks -fsyntax-only -fobjc-arc -x objective-c
> %s.result
> -// RUN: cp %s %t
> +// RUN: cat %s > %t
>  // RUN: %clang_cc1 -arcmt-modify -triple x86_64-apple-macosx10.6 -x
> objective-c %t
>  // RUN: diff %t %s.result
>  // RUN: rm %t
>
> Modified: cfe/trunk/test/ARCMT/with-arc-mode-modify.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ARCMT/with-arc-mode-modify.m?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/ARCMT/with-arc-mode-modify.m (original)
> +++ cfe/trunk/test/ARCMT/with-arc-mode-modify.m Mon Jan  8 07:05:01 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 -fsyntax-only -fobjc-arc -x objective-c %s.result
> -// RUN: cp %s %t
> +// RUN: cat %s > %t
>  // RUN: %clang_cc1 -arcmt-modify -fsyntax-only -fobjc-arc -x objective-c
> %t
>  // RUN: diff %t %s.result
>  // RUN: rm %t
>
> Modified: cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result (original)
> +++ cfe/trunk/test/ARCMT/with-arc-mode-modify.m.result Mon Jan  8 07:05:01
> 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 -fsyntax-only -fobjc-arc -x objective-c %s.result
> -// RUN: cp %s %t
> +// RUN: cat %s > %t
>  // RUN: %clang_cc1 -arcmt-modify -fsyntax-only -fobjc-arc -x objective-c
> %t
>  // RUN: diff %t %s.result
>  // RUN: rm %t
>
> Modified: cfe/trunk/test/PCH/verify_pch.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/verify_pch.m?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/PCH/verify_pch.m (original)
> +++ cfe/trunk/test/PCH/verify_pch.m Mon Jan  8 07:05:01 2018
> @@ -2,7 +2,7 @@
>  // RUN: rm -rf %t
>  // RUN: mkdir -p %t/usr/include
>  // RUN: echo '// empty' > %t/usr/include/sys_header.h
> -// RUN: cp %s %t.h
> +// RUN: cat %s > %t.h
>  //
>  // Precompile
>  // RUN: %clang_cc1 -isystem %t/usr/include -x objective-c-header
> -emit-pch -o %t.pch %t.h
>
> Modified: cfe/trunk/test/VFS/real-path-found-first.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/VFS/real-path-found-first.m?rev=321997&r1=321996&r2=321997&view=diff
>
> ==
> --- cfe/trunk/test/VFS/real-path-found-first.m (original)
> +++ cfe/trunk/test/VFS/real-path-found-first.m Mon Jan  8 07:05:01 2018
> @@ -7,7 +7,7 @@
>  // REQUIRES: shell
>  // RUN: rm -rf %t %t-cache %t.pch
>  // RUN: mkdir -p %t/SomeFramework.framework/Modules
> -// RUN: cp %S/Inputs/some_frame_module.map
> %t/SomeFramework.framework/Modules/module.modulemap
> +// RUN: cat %S/Inputs/some_frame_module.map >
> %t/SomeFramework.framework/Modules/module.modulemap
>  // RUN: sed -e "s:INPUT_DIR:%S/Inputs:g" -e "s:OUT_DIR:%t:g"
>

Re: r321854 - NFC.

[David Blaikie via cfe-commits]

It helps to have the first line of the commit message be roughly
descriptive, since it forms the brief commit summary in version tools and
the subject line in commit email - just "NFC" is a bit unclear. Usually
these sort of commits are described as, say "Suppress -Asserts
unused-variable warning for variable only used in an assert".

On Fri, Jan 5, 2018 at 4:52 AM Evgeny Stupachenko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: evstupac
> Date: Thu Jan  4 18:22:52 2018
> New Revision: 321854
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321854&view=rev
> Log:
> NFC.
> The patch fixes r321395, that cuased
>  -Werror=unused-but-set-variable issue for
>  Diagnosed var on prod build.
>
> From: Evgeny Stupachenko 
>
> Modified:
> cfe/trunk/lib/Serialization/ASTReader.cpp
>
> Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=321854&r1=321853&r2=321854&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTReader.cpp Thu Jan  4 18:22:52 2018
> @@ -10660,6 +10660,7 @@ void ASTReader::diagnoseOdrViolations()
>Diagnosed = true;
>break;
>  }
> +(void)Diagnosed;
>  assert(Diagnosed && "Unable to emit ODR diagnostic.");
>}
>  }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r321816 - [OPENMP] Add debug info for generated functions.

[David Blaikie via cfe-commits]

Rough guess: That seems like a lot of code changes for relatively little
test changes - are all parts of this change tested? (Might well be - just
lots of layers to plumb things through - but if there's lots of places that
get locations and only a few of those are tested, maybe this could use more
coverage?)

On Thu, Jan 4, 2018 at 11:46 AM Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: abataev
> Date: Thu Jan  4 11:45:16 2018
> New Revision: 321816
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321816&view=rev
> Log:
> [OPENMP] Add debug info for generated functions.
>
> Most of the generated functions for the OpenMP were generated with
> disabled debug info. Patch fixes this for better user experience.
>
> Modified:
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
> cfe/trunk/test/OpenMP/target_parallel_debug_codegen.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=321816&r1=321815&r2=321816&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Thu Jan  4 11:45:16 2018
> @@ -1216,7 +1216,8 @@ emitCombinerOrInitializer(CodeGenModule
>CodeGenFunction CGF(CGM);
>// Map "T omp_in;" variable to "*omp_in_parm" value in all expressions.
>// Map "T omp_out;" variable to "*omp_out_parm" value in all
> expressions.
> -  CGF.StartFunction(GlobalDecl(), C.VoidTy, Fn, FnInfo, Args);
> +  CGF.StartFunction(GlobalDecl(), C.VoidTy, Fn, FnInfo, Args,
> In->getLocation(),
> +Out->getLocation());
>CodeGenFunction::OMPPrivateScope Scope(CGF);
>Address AddrIn = CGF.GetAddrOfLocalVar(&OmpInParm);
>Scope.addPrivate(In, [&CGF, AddrIn, PtrTy]() -> Address {
> @@ -2383,7 +2384,8 @@ llvm::Function *CGOpenMPRuntime::emitThr
>// threadprivate copy of the variable VD
>CodeGenFunction CtorCGF(CGM);
>FunctionArgList Args;
> -  ImplicitParamDecl Dst(CGM.getContext(), CGM.getContext().VoidPtrTy,
> +  ImplicitParamDecl Dst(CGM.getContext(), /*DC=*/nullptr, Loc,
> +/*Id=*/nullptr, CGM.getContext().VoidPtrTy,
>  ImplicitParamDecl::Other);
>Args.push_back(&Dst);
>
> @@ -2393,13 +2395,13 @@ llvm::Function *CGOpenMPRuntime::emitThr
>auto Fn = CGM.CreateGlobalInitOrDestructFunction(
>FTy, ".__kmpc_global_ctor_.", FI, Loc);
>CtorCGF.StartFunction(GlobalDecl(), CGM.getContext().VoidPtrTy, Fn,
> FI,
> -Args, SourceLocation());
> +Args, Loc, Loc);
>auto ArgVal = CtorCGF.EmitLoadOfScalar(
>CtorCGF.GetAddrOfLocalVar(&Dst), /*Volatile=*/false,
>CGM.getContext().VoidPtrTy, Dst.getLocation());
>Address Arg = Address(ArgVal, VDAddr.getAlignment());
> -  Arg = CtorCGF.Builder.CreateElementBitCast(Arg,
> -
>  CtorCGF.ConvertTypeForMem(ASTTy));
> +  Arg = CtorCGF.Builder.CreateElementBitCast(
> +  Arg, CtorCGF.ConvertTypeForMem(ASTTy));
>CtorCGF.EmitAnyExprToMem(Init, Arg, Init->getType().getQualifiers(),
> /*IsInitializer=*/true);
>ArgVal = CtorCGF.EmitLoadOfScalar(
> @@ -2414,7 +2416,8 @@ llvm::Function *CGOpenMPRuntime::emitThr
>// of the variable VD
>CodeGenFunction DtorCGF(CGM);
>FunctionArgList Args;
> -  ImplicitParamDecl Dst(CGM.getContext(), CGM.getContext().VoidPtrTy,
> +  ImplicitParamDecl Dst(CGM.getContext(), /*DC=*/nullptr, Loc,
> +/*Id=*/nullptr, CGM.getContext().VoidPtrTy,
>  ImplicitParamDecl::Other);
>Args.push_back(&Dst);
>
> @@ -2425,7 +2428,7 @@ llvm::Function *CGOpenMPRuntime::emitThr
>FTy, ".__kmpc_global_dtor_.", FI, Loc);
>auto NL = ApplyDebugLocation::CreateEmpty(DtorCGF);
>DtorCGF.StartFunction(GlobalDecl(), CGM.getContext().VoidTy, Fn,
> FI, Args,
> -SourceLocation());
> +Loc, Loc);
>// Create a scope with an artificial location for the body of this
> function.
>auto AL = ApplyDebugLocation::CreateArtificial(DtorCGF);
>auto ArgVal = DtorCGF.EmitLoadOfScalar(
> @@ -2469,7 +2472,7 @@ llvm::Function *CGOpenMPRuntime::emitThr
>FunctionArgList ArgList;
>InitCGF.StartFunction(GlobalDecl(), CGM.getContext().VoidTy,
> InitFunction,
>  CGM.getTypes().arrangeNullaryFunction(),
> ArgList,
> -Loc);
> +Loc, Loc);
>emitThreadPrivateVarInit(InitCGF, VDAddr, Ctor, CopyCtor, Dtor,
> Loc);
>   

Re: r321845 - Debug Info: Support DW_AT_calling_convention on composite types.

[David Blaikie via cfe-commits]

Great - are you tracking/planning to implement this for trivial_abi once
it's in? (was mentioned in the code review, but not sure if it's on your
plate/plan or not (no worries if it isn't, just keeping these things in
mind))

On Thu, Jan 4, 2018 at 5:14 PM Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: adrian
> Date: Thu Jan  4 17:13:52 2018
> New Revision: 321845
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321845&view=rev
> Log:
> Debug Info: Support DW_AT_calling_convention on composite types.
> This implements the DWARF 5 feature described at
> http://www.dwarfstd.org/ShowIssue.php?issue=141215.1
>
> This allows a consumer to understand whether a composite data type is
> trivially copyable and thus should be passed by value instead of by
> reference. The canonical example is being able to distinguish the
> following two types:
>
>   // S is not trivially copyable because of the explicit destructor.
>   struct S {
>  ~S() {}
>   };
>
>   // T is a POD type.
>   struct T {
> ~T() = default;
>   };
>
> 
> Differential Revision: https://reviews.llvm.org/D41039
>
> Added:
> cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=321845&r1=321844&r2=321845&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jan  4 17:13:52 2018
> @@ -2803,9 +2803,18 @@ llvm::DICompositeType *CGDebugInfo::Crea
>
>SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
>
> +  // Explicitly record the calling convention for C++ records.
> +  auto Flags = llvm::DINode::FlagZero;
> +  if (auto CXXRD = dyn_cast(RD)) {
> +if (CGM.getCXXABI().getRecordArgABI(CXXRD) == CGCXXABI::RAA_Indirect)
> +  Flags |= llvm::DINode::FlagTypePassByReference;
> +else
> +  Flags |= llvm::DINode::FlagTypePassByValue;
> +  }
> +
>llvm::DICompositeType *RealDecl =
> DBuilder.createReplaceableCompositeType(
>getTagForRecord(RD), RDName, RDContext, DefUnit, Line, 0, Size,
> Align,
> -  llvm::DINode::FlagZero, FullName);
> +  Flags, FullName);
>
>// Elements of composite types usually have back to the type, creating
>// uniquing cycles.  Distinct nodes are more efficient.
>
> Added: cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp?rev=321845&view=auto
>
> ==
> --- cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp (added)
> +++ cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp Thu Jan  4
> 17:13:52 2018
> @@ -0,0 +1,48 @@
> +// RUN: %clang_cc1 -emit-llvm -debug-info-kind=standalone -triple
> %itanium_abi_triple %s -o - | FileCheck %s
> +
> +// Not trivially copyable because of the explicit destructor.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefDtor",{{.*}}flags:
> DIFlagTypePassByReference
> +struct RefDtor {
> +  int i;
> +  ~RefDtor() {}
> +} refDtor;
> +
> +// Not trivially copyable because of the explicit copy constructor.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefCopy",{{.*}}flags:
> DIFlagTypePassByReference
> +struct RefCopy {
> +  int i;
> +  RefCopy() = default;
> +  RefCopy(RefCopy &Copy) {}
> +} refCopy;
> +
> +// Not trivially copyable because of the explicit move constructor.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefMove",{{.*}}flags:
> DIFlagTypePassByReference
> +struct RefMove {
> +  int i;
> +  RefMove() = default;
> +  RefMove(RefMove &&Move) {}
> +} refMove;
> +
> +// POD-like type even though it defines a destructor.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Podlike", {{.*}}flags:
> DIFlagTypePassByValue
> +struct Podlike {
> +  int i;
> +  Podlike() = default;
> +  Podlike(Podlike &&Move) = default;
> +  ~Podlike() = default;
> +} podlike;
> +
> +
> +// This is a POD type.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Pod",{{.*}}flags:
> DIFlagTypePassByValue
> +struct Pod {
> +  int i;
> +} pod;
> +
> +// This is definitely not a POD type.
> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Complex",{{.*}}flags:
> DIFlagTypePassByReference
> +struct Complex {
> +  Complex() {}
> +  Complex(Complex &Copy) : i(Copy.i) {};
> +  int i;
> +} complex;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r321845 - Debug Info: Support DW_AT_calling_convention on composite types.

[David Blaikie via cfe-commits]

Excellent :)

On Mon, Jan 8, 2018 at 8:39 AM Adrian Prantl  wrote:

>
> On Jan 8, 2018, at 8:14 AM, David Blaikie  wrote:
>
> Great - are you tracking/planning to implement this for trivial_abi once
> it's in? (was mentioned in the code review, but not sure if it's on your
> plate/plan or not (no worries if it isn't, just keeping these things in
> mind))
>
>
> Yes, this was in fact my primary motivation for the feature. Since the
> code is asking the ABI object, it looks like this might work out of the box
> with the trivial_abi attribute, but I will definitely at least add a
> testcase once it's in.
>
> -- adrian
>
>
> On Thu, Jan 4, 2018 at 5:14 PM Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: adrian
>> Date: Thu Jan  4 17:13:52 2018
>> New Revision: 321845
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=321845&view=rev
>> Log:
>> Debug Info: Support DW_AT_calling_convention on composite types.
>> This implements the DWARF 5 feature described at
>> http://www.dwarfstd.org/ShowIssue.php?issue=141215.1
>>
>> This allows a consumer to understand whether a composite data type is
>> trivially copyable and thus should be passed by value instead of by
>> reference. The canonical example is being able to distinguish the
>> following two types:
>>
>>   // S is not trivially copyable because of the explicit destructor.
>>   struct S {
>>  ~S() {}
>>   };
>>
>>   // T is a POD type.
>>   struct T {
>> ~T() = default;
>>   };
>>
>> 
>> Differential Revision: https://reviews.llvm.org/D41039
>>
>> Added:
>> cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp
>> Modified:
>> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=321845&r1=321844&r2=321845&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Jan  4 17:13:52 2018
>> @@ -2803,9 +2803,18 @@ llvm::DICompositeType *CGDebugInfo::Crea
>>
>>SmallString<256> FullName = getUniqueTagTypeName(Ty, CGM, TheCU);
>>
>> +  // Explicitly record the calling convention for C++ records.
>> +  auto Flags = llvm::DINode::FlagZero;
>> +  if (auto CXXRD = dyn_cast(RD)) {
>> +if (CGM.getCXXABI().getRecordArgABI(CXXRD) == CGCXXABI::RAA_Indirect)
>> +  Flags |= llvm::DINode::FlagTypePassByReference;
>> +else
>> +  Flags |= llvm::DINode::FlagTypePassByValue;
>> +  }
>> +
>>llvm::DICompositeType *RealDecl =
>> DBuilder.createReplaceableCompositeType(
>>getTagForRecord(RD), RDName, RDContext, DefUnit, Line, 0, Size,
>> Align,
>> -  llvm::DINode::FlagZero, FullName);
>> +  Flags, FullName);
>>
>>// Elements of composite types usually have back to the type, creating
>>// uniquing cycles.  Distinct nodes are more efficient.
>>
>> Added: cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp?rev=321845&view=auto
>>
>> ==
>> --- cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp (added)
>> +++ cfe/trunk/test/CodeGenCXX/debug-info-composite-cc.cpp Thu Jan  4
>> 17:13:52 2018
>> @@ -0,0 +1,48 @@
>> +// RUN: %clang_cc1 -emit-llvm -debug-info-kind=standalone -triple
>> %itanium_abi_triple %s -o - | FileCheck %s
>> +
>> +// Not trivially copyable because of the explicit destructor.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefDtor",{{.*}}flags:
>> DIFlagTypePassByReference
>> +struct RefDtor {
>> +  int i;
>> +  ~RefDtor() {}
>> +} refDtor;
>> +
>> +// Not trivially copyable because of the explicit copy constructor.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefCopy",{{.*}}flags:
>> DIFlagTypePassByReference
>> +struct RefCopy {
>> +  int i;
>> +  RefCopy() = default;
>> +  RefCopy(RefCopy &Copy) {}
>> +} refCopy;
>> +
>> +// Not trivially copyable because of the explicit move constructor.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "RefMove",{{.*}}flags:
>> DIFlagTypePassByReference
>> +struct RefMove {
>> +  int i;
>> +  RefMove() = default;
>> +  RefMove(RefMove &&Move) {}
>> +} refMove;
>> +
>> +// POD-like type even though it defines a destructor.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Podlike", {{.*}}flags:
>> DIFlagTypePassByValue
>> +struct Podlike {
>> +  int i;
>> +  Podlike() = default;
>> +  Podlike(Podlike &&Move) = default;
>> +  ~Podlike() = default;
>> +} podlike;
>> +
>> +
>> +// This is a POD type.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Pod",{{.*}}flags:
>> DIFlagTypePassByValue
>> +struct Pod {
>> +  int i;
>> +} pod;
>> +
>> +// This is definitely not a POD type.
>> +// CHECK-DAG: !DICompositeType({{.*}}, name: "Complex",{{.*}}flags:
>> DIFlagTypePassByReference
>> +struct Complex {
>> 

r322126 - Wire up GCOV to the new pass manager

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Tue Jan  9 14:03:47 2018
New Revision: 322126

URL: http://llvm.org/viewvc/llvm-project?rev=322126&view=rev
Log:
Wire up GCOV to the new pass manager

GCOV in the old pass manager also strips debug info (if debug info is
disabled/only produced for profiling anyway) after the GCOV pass runs.

I think the strip pass hasn't been ported to the new pass manager, so it
might take me a little while to wire that up.

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/CodeGen/code-coverage.c

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=322126&r1=322125&r2=322126&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Tue Jan  9 14:03:47 2018
@@ -26,6 +26,7 @@
 #include "llvm/Bitcode/BitcodeWriterPass.h"
 #include "llvm/CodeGen/RegAllocRegistry.h"
 #include "llvm/CodeGen/SchedulerRegistry.h"
+#include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/IRPrintingPasses.h"
 #include "llvm/IR/LegacyPassManager.h"
@@ -44,8 +45,8 @@
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Target/TargetMachine.h"
 #include "llvm/Target/TargetOptions.h"
-#include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/Transforms/Coroutines.h"
+#include "llvm/Transforms/GCOVProfiler.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/IPO/AlwaysInliner.h"
 #include "llvm/Transforms/IPO/PassManagerBuilder.h"
@@ -471,6 +472,23 @@ static void initTargetOptions(llvm::Targ
   Options.MCOptions.IASSearchPaths.push_back(
   Entry.IgnoreSysRoot ? Entry.Path : HSOpts.Sysroot + Entry.Path);
 }
+static Optional getGCOVOptions(const CodeGenOptions &CodeGenOpts) 
{
+  if (CodeGenOpts.DisableGCov)
+return None;
+  if (!CodeGenOpts.EmitGcovArcs && !CodeGenOpts.EmitGcovNotes)
+return None;
+  // Not using 'GCOVOptions::getDefault' allows us to avoid exiting if
+  // LLVM's -default-gcov-version flag is set to something invalid.
+  GCOVOptions Options;
+  Options.EmitNotes = CodeGenOpts.EmitGcovNotes;
+  Options.EmitData = CodeGenOpts.EmitGcovArcs;
+  llvm::copy(CodeGenOpts.CoverageVersion, std::begin(Options.Version));
+  Options.UseCfgChecksum = CodeGenOpts.CoverageExtraChecksum;
+  Options.NoRedZone = CodeGenOpts.DisableRedZone;
+  Options.FunctionNamesInData = !CodeGenOpts.CoverageNoFunctionNamesInData;
+  Options.ExitBlockBeforeBody = CodeGenOpts.CoverageExitBlockBeforeBody;
+  return Options;
+}
 
 void EmitAssemblyHelper::CreatePasses(legacy::PassManager &MPM,
   legacy::FunctionPassManager &FPM) {
@@ -613,20 +631,8 @@ void EmitAssemblyHelper::CreatePasses(le
   if (!CodeGenOpts.RewriteMapFiles.empty())
 addSymbolRewriterPass(CodeGenOpts, &MPM);
 
-  if (!CodeGenOpts.DisableGCov &&
-  (CodeGenOpts.EmitGcovArcs || CodeGenOpts.EmitGcovNotes)) {
-// Not using 'GCOVOptions::getDefault' allows us to avoid exiting if
-// LLVM's -default-gcov-version flag is set to something invalid.
-GCOVOptions Options;
-Options.EmitNotes = CodeGenOpts.EmitGcovNotes;
-Options.EmitData = CodeGenOpts.EmitGcovArcs;
-memcpy(Options.Version, CodeGenOpts.CoverageVersion, 4);
-Options.UseCfgChecksum = CodeGenOpts.CoverageExtraChecksum;
-Options.NoRedZone = CodeGenOpts.DisableRedZone;
-Options.FunctionNamesInData =
-!CodeGenOpts.CoverageNoFunctionNamesInData;
-Options.ExitBlockBeforeBody = CodeGenOpts.CoverageExitBlockBeforeBody;
-MPM.add(createGCOVProfilerPass(Options));
+  if (Optional Options = getGCOVOptions(CodeGenOpts)) {
+MPM.add(createGCOVProfilerPass(*Options));
 if (CodeGenOpts.getDebugInfo() == codegenoptions::NoDebugInfo)
   MPM.add(createStripSymbolsPass(true));
   }
@@ -954,6 +960,9 @@ void EmitAssemblyHelper::EmitAssemblyWit
CodeGenOpts.DebugPassManager);
   }
 }
+if (Optional Options = getGCOVOptions(CodeGenOpts)) {
+  MPM.addPass(GCOVProfilerPass(*Options));
+}
   }
 
   // FIXME: We still use the legacy pass manager to do code generation. We

Modified: cfe/trunk/test/CodeGen/code-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/code-coverage.c?rev=322126&r1=322125&r2=322126&view=diff
==
--- cfe/trunk/test/CodeGen/code-coverage.c (original)
+++ cfe/trunk/test/CodeGen/code-coverage.c Tue Jan  9 14:03:47 2018
@@ -2,7 +2,10 @@
 // RUN: %clang_cc1 -emit-llvm -disable-red-zone -femit-coverage-data 
-coverage-no-function-names-in-data %s -o - | FileCheck %s --check-prefix 
WITHOUTNAMES
 // RUN: %clang_cc1 -emit-llvm -disable-red-zone -femit-coverage-data 
-coverage-notes-file=aaa.gcno -coverage-data-file=bbb.gcda -dwarf-column-info 
-debug-info-kind=limited -dwa

Re: [PATCH] D41455: [ASTMatchers] Add isNoReturn() match narrower for FunctionDeclarations

[David Blaikie via cfe-commits]

I haven't as yet, no. Sorry - happy if someone else wants to have a go, or
I'll take a closer look soon.

- Dave

On Thu, Jan 11, 2018 at 11:38 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D41455#963752, @aaron.ballman wrote:
>
> > Aside from a documentation nit, this LGTM. However, you should wait to
> commit until after you can safely regenerate the AST matcher documentation.
> The issue there is that dump_ast_matchers.py was not updated after r318304.
> I believe @dblaikie was looking into the Python script, but I'm not certain
> how far he got with it.
>
>
> @dblaikie Hi! Did you get anywhere with the script update?
> As far i'm concerned, all new ASTMatchers are stalled because of this...
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D41455
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r326324 - [analyzer] Fix a compiler warning

[David Blaikie via cfe-commits]

Might be useful in the future to use a more specific commit message such as
"add missing override" (or "add missing override to address
-Wmissing-override warning"), etc.

On Wed, Feb 28, 2018 at 6:03 AM Gabor Horvath via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: xazax
> Date: Wed Feb 28 06:01:48 2018
> New Revision: 326324
>
> URL: http://llvm.org/viewvc/llvm-project?rev=326324&view=rev
> Log:
> [analyzer] Fix a compiler warning
>
> Modified:
> cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
>
> Modified:
> cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h?rev=326324&r1=326323&r2=326324&view=diff
>
> ==
> --- cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
> (original)
> +++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
> Wed Feb 28 06:01:48 2018
> @@ -155,7 +155,8 @@ public:
>
>BugReporter& getBugReporter() { return BR; }
>
> -  cross_tu::CrossTranslationUnitContext *getCrossTranslationUnitContext()
> {
> +  cross_tu::CrossTranslationUnitContext *
> +  getCrossTranslationUnitContext() override {
>  return &CTU;
>}
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D47597: IRGen: Write .dwo files when -split-dwarf-file is used together with -fthinlto-index.

[David Blaikie via cfe-commits]

On Thu, May 31, 2018 at 11:20 AM Peter Collingbourne via Phabricator <
revi...@reviews.llvm.org> wrote:

> pcc created this revision.
> pcc added reviewers: tejohnson, dblaikie.
> Herald added subscribers: JDevlieghere, hiraditya, eraman, inglorion,
> mehdi_amini.
>
> https://reviews.llvm.org/D47597
>
> Files:
>   clang/lib/CodeGen/BackendUtil.cpp
>   clang/test/CodeGen/thinlto-split-dwarf.c
>   llvm/include/llvm/LTO/Config.h
>   llvm/lib/LTO/LTOBackend.cpp
>
>
> Index: llvm/lib/LTO/LTOBackend.cpp
> ===
> --- llvm/lib/LTO/LTOBackend.cpp
> +++ llvm/lib/LTO/LTOBackend.cpp
> @@ -291,14 +291,19 @@
>  return;
>
>std::unique_ptr DwoOut;
> +  SmallString<1024> DwoFile(Conf.DwoPath);
>if (!Conf.DwoDir.empty()) {
>  std::error_code EC;
>  if (auto EC = llvm::sys::fs::create_directories(Conf.DwoDir))
>report_fatal_error("Failed to create directory " + Conf.DwoDir + ":
> " +
>   EC.message());
>
> -SmallString<1024> DwoFile(Conf.DwoDir);
> +DwoFile = Conf.DwoDir;
>  sys::path::append(DwoFile, std::to_string(Task) + ".dwo");
> +  }
> +
> +  if (!DwoFile.empty()) {
> +std::error_code EC;
>  TM->Options.MCOptions.SplitDwarfFile = DwoFile.str().str();
>  DwoOut = llvm::make_unique(DwoFile, EC,
> sys::fs::F_None);
>  if (EC)
> Index: llvm/include/llvm/LTO/Config.h
> ===
> --- llvm/include/llvm/LTO/Config.h
> +++ llvm/include/llvm/LTO/Config.h
> @@ -76,6 +76,11 @@
>/// The directory to store .dwo files.
>std::string DwoDir;
>
> +  /// The path to write a .dwo file to. This should generally only be
> used when
> +  /// running an individual backend directly via thinBackend(), as
> otherwise
> +  /// all .dwo files will be written to the same path.
> +  std::string DwoPath;
> +
>/// Optimization remarks file path.
>std::string RemarksFilename = "";
>
> Index: clang/test/CodeGen/thinlto-split-dwarf.c
> ===
> --- /dev/null
> +++ clang/test/CodeGen/thinlto-split-dwarf.c
> @@ -0,0 +1,21 @@
> +// REQUIRES: x86-registered-target
> +
> +// RUN: %clang_cc1 -debug-info-kind=limited -triple
> x86_64-unknown-linux-gnu \
> +// RUN:   -flto=thin -emit-llvm-bc \
> +// RUN:   -o %t.o %s
> +
> +// RUN: llvm-lto2 run -thinlto-distributed-indexes %t.o \
> +// RUN:   -o %t2.index \
> +// RUN:   -r=%t.o,main,px
> +
> +// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu \
> +// RUN:   -emit-obj -fthinlto-index=%t.o.thinlto.bc \
> +// RUN:   -o %t.native.o -split-dwarf-file %t.native.dwo -x ir %t.o
>

Can this be written in a single IR file yet (rather than frontend
compiling, indexing, then backend compiling), now that Teresa's implemented
some of the summary IR syntax?


> +
> +// RUN: llvm-readobj -sections %t.native.o | FileCheck --check-prefix=O %s
> +// RUN: llvm-readobj -sections %t.native.dwo | FileCheck
> --check-prefix=DWO %s
> +
> +// O-NOT: .dwo
> +// DWO: .dwo
> +
> +int main() {}
> Index: clang/lib/CodeGen/BackendUtil.cpp
> ===
> --- clang/lib/CodeGen/BackendUtil.cpp
> +++ clang/lib/CodeGen/BackendUtil.cpp
> @@ -1161,6 +1161,7 @@
>Conf.DebugPassManager = CGOpts.DebugPassManager;
>Conf.RemarksWithHotness = CGOpts.DiagnosticsWithHotness;
>Conf.RemarksFilename = CGOpts.OptRecordFile;
> +  Conf.DwoPath = CGOpts.SplitDwarfFile;
>switch (Action) {
>case Backend_EmitNothing:
>  Conf.PreCodeGenModuleHook = [](size_t Task, const Module &Mod) {
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D47687: fix: [Bug 18971] - Missing -Wparentheses warning

[David Blaikie via cfe-commits]

Probably CC someone from apple here & ask about rdar://8678458 - they can
look it up & provide the missing context.

On Mon, Jun 4, 2018 at 8:17 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:

> lebedev.ri added reviewers: rjmccall, akyrtzi.
> lebedev.ri added a comment.
>
> It seems it was https://reviews.llvm.org/rL119537 that regressed it.
> Nice, such a change, no review, no test :)
>
>
> https://reviews.llvm.org/D47687
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r333955 - Update for an LLVM header file move

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Mon Jun  4 14:23:29 2018
New Revision: 333955

URL: http://llvm.org/viewvc/llvm-project?rev=333955&view=rev
Log:
Update for an LLVM header file move

Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=333955&r1=333954&r2=333955&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Jun  4 14:23:29 2018
@@ -29,7 +29,7 @@
 #include "clang/CodeGen/SwiftCallingConv.h"
 #include "clang/Frontend/CodeGenOptions.h"
 #include "llvm/ADT/StringExtras.h"
-#include "llvm/Analysis/Utils/Local.h"
+#include "llvm/Transforms/Utils/Local.h"
 #include "llvm/Analysis/ValueTracking.h"
 #include "llvm/IR/Attributes.h"
 #include "llvm/IR/CallSite.h"


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

r334778 - Modules: Fix implicit output file for .cppm to .pcm instead of stdout

[David Blaikie via cfe-commits]

Author: dblaikie
Date: Thu Jun 14 16:09:06 2018
New Revision: 334778

URL: http://llvm.org/viewvc/llvm-project?rev=334778&view=rev
Log:
Modules: Fix implicit output file for .cppm to .pcm instead of stdout

This code was introduced back in r178148, a change to introduce
-module-file-info - which still exists & seems like it's still tested (&
this change didn't cause any of those tests to fail).

It doesn't look like this change was necessary there - since it's about
pcm output, whereas -module-file-info looks like it's for pcm /input/.
So I'm not really sure what the original motivation was.

I'm open to ideas though, if it turns out the original change was
necessary/useful.

Added:
cfe/trunk/test/Driver/clang-translation.cppm
Modified:
cfe/trunk/lib/Driver/Driver.cpp

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=334778&r1=334777&r2=334778&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Thu Jun 14 16:09:06 2018
@@ -4013,8 +4013,7 @@ const char *Driver::GetNamedOutputPath(C
   }
 
   // Default to writing to stdout?
-  if (AtTopLevel && !CCGenDiagnostics &&
-  (isa(JA) || JA.getType() == types::TY_ModuleFile))
+  if (AtTopLevel && !CCGenDiagnostics && isa(JA))
 return "-";
 
   // Is this the assembly listing for /FA?

Added: cfe/trunk/test/Driver/clang-translation.cppm
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/clang-translation.cppm?rev=334778&view=auto
==
--- cfe/trunk/test/Driver/clang-translation.cppm (added)
+++ cfe/trunk/test/Driver/clang-translation.cppm Thu Jun 14 16:09:06 2018
@@ -0,0 +1,2 @@
+// RUN: %clang %s --precompile -### 2>&1 | FileCheck %s
+// CHECK: "-o" "{{[^"]*}}clang-translation.pcm"


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

Re: [PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

[David Blaikie via cfe-commits]

On Fri, Oct 19, 2018 at 3:56 PM Adrian Prantl via Phabricator via
llvm-commits  wrote:

> aprantl added a comment.
>
> I have a vague recollection that this column info hack was added to
> disambiguate two types defined on the same line (which is something that
> happened more often than one would think because of macro expansion). Did
> you do the git archeology to ensure that the original reason for doing it
> this way has been resolved? FWIW, I'm fine with doing this change for the
> Darwin platforms because column info is turned on by default, so this
> shouldn't affect us.
>

It was (I think) duplicate calls (rather than types) - so that inlining
(which previously didn't produce a unique'd inlinedAt location (because we
didn't have the "unique" metadata feature)) didn't collapse the
instructions from the two inlined calls into one.


>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D38061
>
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r342827 - Fix modules build with shared library.

[David Blaikie via cfe-commits]

Richard - any further thoughts here (re: layering/dependencies, etc)? Would
love to get the layering oddity fixed rather than having it get more
embedded over time.

On Tue, Oct 2, 2018 at 2:44 PM Shuai Wang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Mon, Oct 1, 2018 at 4:58 PM Richard Smith 
> wrote:
>
>> On Mon, 1 Oct 2018 at 16:10, George Karpenkov via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> On Oct 1, 2018, at 2:50 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>> This looks like the wrong fix to me, but I don't really know enough
>>> about what's being done with ExprMutationAnalyzer to have an opinion on
>>> what the right fix is.
>>>
>>> Shuai, what is the goal here? Why is this code being moved to Analysis/?
>>>
>>>
>>> I’ve asked for this possibility, as I wanted to use it from the Clang
>>> static analyzer.
>>>
>>> Do you intend to call it from the compiler frontend at some point? I can
>>> see a code review for the move itself, but no discussion of a plan or
>>> overall direction being followed here. Did I miss it?
>>>
>>> We have historically decided to not use the tooling interfaces
>>> (ASTMatcher, ParentMap, etc) from the frontend,
>>>
>>>
>>> Clang analyzer uses ASTMatcher all over the place.
>>>
>>> because they're generally a poor fit for our goals (we aim for a
>>> largely-single-pass compilation with good locality, and the AST matchers
>>> make different design choices)
>>>
>>>
>>> That’s totally good for the analyzer though, right?
>>>
>>
>> Yes, that all seems fine for the static analyzer.
>>
>>
>>> In any case, in future it might make sense to move the analyzer out of
>>> Clang proper.
>>> But for know the only way to use clang-tidy utilities from the analyzer
>>> is to move them into Clang.
>>>
>>
>> Right. I think we should try to maintain the idea that all the Clang
>> Static Analyzer-specific things are in lib/StaticAnalyzer, and lib/Analysis
>> only contains things depended on by the frontend. (That is: the things a
>> clang binary would use if we didn't link in the static analyzer)
>>
>> Given the above, I think the best approach would be to move this code out
>> of lib/Analysis and into somewhere in lib/StaticAnalyzer. There shouldn't
>> be any problem with clang-tidy using it from there, since it already
>> depends on the static analyzer.
>>
> I'm happy to do the move.
> Could you (or someone) help point out where exactly I should move it to
> though?
>
>> . If you want to change that, we'll need to discuss that decision.
>>>
>>> If the idea is to move this code into clang proper so that it can be
>>> used by various different tooling clients, we'd need to discuss the right
>>> place for it. Perhaps lib/Tooling/Analysis would make sense?
>>>
>>>
>>> On Mon, 1 Oct 2018 at 13:13, David Blaikie via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>> I can't really reproduce this - when I try to build clang/llvm with
>>>> LLVM_ENABLE_MODULES in CMake I'm still seeing an error I reported March on
>>>> a cfe-dev thread - something to do with unique_ptr instantiations for
>>>> MappedBlockStream in the PDB parsing code.
>>>>
>>>> So, I'm wondering what error you hit, Eric/where/how, etc...
>>>>
>>>> On Sun, Sep 30, 2018 at 10:23 AM Eric Fiselier  wrote:
>>>>
>>>>> +rsmith (actually this time)
>>>>>
>>>>> On Sun, Sep 30, 2018 at 12:09 PM Eric Fiselier  wrote:
>>>>>
>>>>>> +rsmith
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Sorry, I'm not actually sure why this fix is correct.I stole both the
>>>>>> fix and the comment from a similar one on L150 of the module map left by
>>>>>> Richard Smith.
>>>>>>
>>>>>> /Eric
>>>>>>
>>>>>> On Tue, Sep 25, 2018 at 8:36 PM Shuai Wang 
>>>>>> wrote:
>>>>>>
>>>>>>> I'd like to understand this better as well, in particular what would
>>>>>>> be a proper fix?
>>>>>>>
>>>&g

Re: r344957 - Give Multiversion-inline functions linkonce linkage

[David Blaikie via cfe-commits]

Does this match GCC's approach here?

(I ask this sort of as throwaway/conversation starter - because the
linkage/behavior around multiversion functions and their inlining is full
of sharp corners/risks of code moving out of the areas appropriately
restricted based on the cpu features)

On Mon, Oct 22, 2018 at 2:22 PM Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: erichkeane
> Date: Mon Oct 22 14:20:45 2018
> New Revision: 344957
>
> URL: http://llvm.org/viewvc/llvm-project?rev=344957&view=rev
> Log:
> Give Multiversion-inline functions linkonce linkage
>
> Since multiversion variant functions can be inline, in C they become
> available-externally linkage.  This ends up causing the variants to not
> be emitted, and not available to the linker.
>
> The solution is to make sure that multiversion functions are always
> emitted by marking them linkonce.
>
> Change-Id: I897aa37c7cbba0c1eb2c57ee881d5000a2113b75
>
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/test/CodeGen/attr-target-mv.c
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=344957&r1=344956&r2=344957&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Oct 22 14:20:45 2018
> @@ -3669,6 +3669,10 @@ llvm::GlobalValue::LinkageTypes CodeGenM
>return llvm::GlobalVariable::WeakAnyLinkage;
>}
>
> +  if (const auto *FD = D->getAsFunction())
> +if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
> +  return llvm::GlobalVariable::LinkOnceAnyLinkage;
> +
>// We are guaranteed to have a strong definition somewhere else,
>// so we can use available_externally linkage.
>if (Linkage == GVA_AvailableExternally)
>
> Modified: cfe/trunk/test/CodeGen/attr-target-mv.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target-mv.c?rev=344957&r1=344956&r2=344957&view=diff
>
> ==
> --- cfe/trunk/test/CodeGen/attr-target-mv.c (original)
> +++ cfe/trunk/test/CodeGen/attr-target-mv.c Mon Oct 22 14:20:45 2018
> @@ -88,19 +88,19 @@ void bar4() {
>
>  // CHECK: declare i32 @foo.arch_sandybridge()
>
> -// CHECK: define available_externally i32 @foo_inline.sse4.2()
> +// CHECK: define linkonce i32 @foo_inline.sse4.2()
>  // CHECK: ret i32 0
>
>  // CHECK: declare i32 @foo_inline.arch_sandybridge()
>  //
> -// CHECK: define available_externally i32 @foo_inline.arch_ivybridge()
> +// CHECK: define linkonce i32 @foo_inline.arch_ivybridge()
>  // CHECK: ret i32 1
> -// CHECK: define available_externally i32 @foo_inline()
> +// CHECK: define linkonce i32 @foo_inline()
>  // CHECK: ret i32 2
>
> -// CHECK: define available_externally void @foo_decls()
> -// CHECK: define available_externally void @foo_decls.sse4.2()
> +// CHECK: define linkonce void @foo_decls()
> +// CHECK: define linkonce void @foo_decls.sse4.2()
>
> -// CHECK: define available_externally void @foo_multi.avx_sse4.2()
> -// CHECK: define available_externally void @foo_multi.fma4_sse4.2()
> -// CHECK: define available_externally void
> @foo_multi.arch_ivybridge_fma4_sse4.2()
> +// CHECK: define linkonce void @foo_multi.avx_sse4.2()
> +// CHECK: define linkonce void @foo_multi.fma4_sse4.2()
> +// CHECK: define linkonce void @foo_multi.arch_ivybridge_fma4_sse4.2()
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits