Re: [PATCH] D50154: [clangd] capitalize diagnostic messages
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. 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 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: [PATCH] D50154: [clangd] capitalize diagnostic messages
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. And if the consensus about this particular text transformation changes I'm willing to revert this change for sure. > > >> 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. > > >> >> >> >> >> >>> >>> 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: [PATCH] D50154: [clangd] capitalize diagnostic messages
On 7 August 2018 at 17:40, Fangrui Song wrote: > > On 2018-08-07, David Blaikie wrote: > >> >> 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. >> > > Not bijection :) classical German example 'ß'.upper().lower() => 'ss' > Though for the context (diagnostic messages where i18n is not > concerned), this works well enough. > > >> >>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. >> > > Alex, would you mind sharing the discussion thread of the editor you use? I'm not working with any particular editor right now, just working on supporting Clangd for an internal client that used libclang before. > > > >>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,
Re: r309386 - Recommit r308327 3rd time: Add a warning for missing
Are the pshpack1.h/poppack.h headers included from other headers in the SDK or are they intended for end-users? If they're only used in the SDK then the SDK headers should probably be system headers, so the warning should be silenced. Apart from that there's no real good solution for this issue unfortunately apart from turning off the warning with a command-line flag or a pragma. I don't think this particular pattern warrants some sort of special treatment in Clang. On 26 September 2017 at 17:02, Nico Weber wrote: > Another bit of feedback: The Microsoft SDK has pragma adjustment headers > that are used like so: > > #include > // Define structs with alignment 1 here > #include > > This warning fires on that. I haven't seen these headers in active use > recently, but I remember seeing them quite a bit maybe 10 years ago. (It > took me until today to remember their names.) Any ideas on how to deal with > that? > > On Fri, Jul 28, 2017 at 2:41 PM, Alex Lorenz via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: arphaman >> Date: Fri Jul 28 07:41:21 2017 >> New Revision: 309386 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=309386&view=rev >> Log: >> Recommit r308327 3rd time: Add a warning for missing >> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included >> files >> >> The second recommit (r309106) was reverted because the "non-default >> #pragma >> pack value chages the alignment of struct or union members in the >> included file" >> warning proved to be too aggressive for external projects like Chromium >> (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This >> recommit >> makes the problematic warning a non-default one, and gives it the >> -Wpragma-pack-suspicious-include warning option. >> >> The first recommit (r308441) caused a "non-default #pragma pack value >> might >> change the alignment of struct or union members in the included file" >> warning >> in LLVM itself. This recommit tweaks the added warning to avoid warnings >> for >> #includes that don't have any records that are affected by the non-default >> alignment. This tweak avoids the previously emitted warning in LLVM. >> >> Original message: >> >> This commit adds a new -Wpragma-pack warning. It warns in the following >> cases: >> >> - When a translation unit is missing terminating #pragma pack (pop) >> directives. >> - When entering an included file if the current alignment value as >> determined >> by '#pragma pack' directives is different from the default alignment >> value. >> - When leaving an included file that changed the state of the current >> alignment >> value. >> >> rdar://10184173 >> >> Differential Revision: https://reviews.llvm.org/D35484 >> >> Added: >> cfe/trunk/test/PCH/suspicious-pragma-pack.c >> cfe/trunk/test/Sema/Inputs/pragma-pack1.h >> cfe/trunk/test/Sema/Inputs/pragma-pack2.h >> cfe/trunk/test/Sema/suspicious-pragma-pack.c >> cfe/trunk/test/SemaObjC/Inputs/empty.h >> cfe/trunk/test/SemaObjC/suspicious-pragma-pack.m >> Modified: >> cfe/trunk/include/clang/Basic/DiagnosticGroups.td >> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td >> cfe/trunk/include/clang/Lex/PPCallbacks.h >> cfe/trunk/include/clang/Sema/Sema.h >> cfe/trunk/include/clang/Serialization/ASTReader.h >> cfe/trunk/lib/Parse/ParsePragma.cpp >> cfe/trunk/lib/Sema/Sema.cpp >> cfe/trunk/lib/Sema/SemaAttr.cpp >> cfe/trunk/lib/Serialization/ASTReader.cpp >> cfe/trunk/lib/Serialization/ASTWriter.cpp >> cfe/trunk/test/OpenMP/declare_simd_messages.cpp >> cfe/trunk/test/PCH/pragma-pack.c >> cfe/trunk/test/Parser/pragma-options.c >> cfe/trunk/test/Parser/pragma-options.cpp >> cfe/trunk/test/Parser/pragma-pack.c >> cfe/trunk/test/Sema/pragma-pack.c >> >> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td >> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ >> Basic/DiagnosticGroups.td?rev=309386&r1=309385&r2=309386&view=diff >> >> == >> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original) >> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Fri Jul 28 >> 07:41:21 2017 >> @@ -471,8 +471,10 @@ def IgnoredPragmaIntrinsic : DiagGroup<" >> def UnknownPragmas : DiagGroup<"unknown-pragmas">; >> def IgnoredPragmas : DiagGroup<"ignored-pragmas", >> [IgnoredPragmaIntrinsic]>; >> def PragmaClangAttribute : DiagGroup<"pragma-clang-attribute">; >> +def PragmaPackSuspiciousInclude : DiagGroup<"pragma-pack-suspici >> ous-include">; >> +def PragmaPack : DiagGroup<"pragma-pack", [PragmaPackSuspiciousInclude]> >> ; >> def Pragmas : DiagGroup<"pragmas", [UnknownPragmas, IgnoredPragmas, >> -PragmaClangAttribute]>; >> +PragmaClangAttribute, PragmaPack]>; >> def UnknownWarningOption : DiagGroup<"unknown-warning-option">; >> def NSobjectAttri
Re: r315755 - Fix -Woverloaded-virtual warning in clang-refactor
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: r315755 - Fix -Woverloaded-virtual warning in clang-refactor
That's a good idea! I'll commit an llvm_unreachable fix for this override
then.
On 16 October 2017 at 10:32, David Blaikie wrote:
> 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: r316152 - Fix a few nits in RenamingAction.
Thanks!
On 19 October 2017 at 01:20, Haojian Wu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: hokein
> Date: Thu Oct 19 01:20:55 2017
> New Revision: 316152
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316152&view=rev
> Log:
> Fix a few nits in RenamingAction.
>
> * Add missing override keyword.
> * avoid unnecessary copy of std::string.
>
> Modified:
> cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
>
> Modified: cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/
> Refactoring/Rename/RenamingAction.cpp?rev=316152&
> r1=316151&r2=316152&view=diff
>
> ==
> --- cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp (original)
> +++ cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp Thu Oct
> 19 01:20:55 2017
> @@ -77,10 +77,10 @@ private:
> class RenameOccurrences final : public SourceChangeRefactoringRule {
> public:
>RenameOccurrences(const NamedDecl *ND, std::string NewName)
> - : Finder(ND), NewName(NewName) {}
> + : Finder(ND), NewName(std::move(NewName)) {}
>
>Expected
> - createSourceReplacements(RefactoringRuleContext &Context) {
> + createSourceReplacements(RefactoringRuleContext &Context) override {
> Expected Occurrences =
> Finder.findSymbolOccurrences(Context);
> if (!Occurrences)
>
>
> ___
> 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: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++
Sorry for the late response,
On Sat, 18 Aug 2018 at 20:10, Nico Weber wrote:
> Also, the diag text should probably say "pass '-stdlib=libc++' " not "pass
> '-std=libc++' "?
>
Good catch, thanks! I'll commit a fixup for it.
>
> On Sat, Aug 18, 2018 at 11:06 PM Nico Weber wrote:
>
>> Should this maybe not be emitted when compiling e.g. .ii files
>> (preprocessed output)? I just got this when I built a standalone .ii file
>> with some bug repro after I deleted all -I and -isysroot flags and whatnot,
>> since they aren't needed for preprocessed files.
>>
>
That would make sense, but I'm not sure how easy it is to determine if a
file is already preprocessed. I'll try to create a patch for this fixup.
>
>> On Tue, Jun 19, 2018 at 6:52 PM Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Tue Jun 19 15:47:53 2018
>>> New Revision: 335081
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=335081&view=rev
>>> Log:
>>> Recommit r335063: [Darwin] Add a warning for missing include path for
>>> libstdc++
>>>
>>> The recommit ensures that the tests that failed on bots don't trigger
>>> the warning.
>>>
>>> Xcode 10 removes support for libstdc++, but the users just get a
>>> confusing
>>> include not file warning when including an STL header (when building for
>>> iOS6
>>> which uses libstdc++ by default for example).
>>> This patch adds a new warning that lets the user know that the libstdc++
>>> include
>>> path was not found to ensure that the user is more aware of why the
>>> error occurs.
>>>
>>> rdar://40830462
>>>
>>> Differential Revision: https://reviews.llvm.org/D48297
>>>
>>> Added:
>>> cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp
>>> Modified:
>>> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> cfe/trunk/include/clang/Lex/HeaderSearch.h
>>> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>>> cfe/trunk/test/CodeGenCXX/apple-kext-guard-variable.cpp
>>> cfe/trunk/test/Misc/backend-stack-frame-diagnostics.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=335081&r1=335080&r2=335081&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
>>> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Jun 19
>>> 15:47:53 2018
>>> @@ -236,4 +236,9 @@ def err_invalid_vfs_overlay : Error<
>>>
>>> def warn_option_invalid_ocl_version : Warning<
>>>"OpenCL version %0 does not support the option '%1'">,
>>> InGroup;
>>> +
>>> +def warn_stdlibcxx_not_found : Warning<
>>> + "include path for stdlibc++ headers not found; pass '-std=libc++' on
>>> the "
>>> + "command line to use the libc++ standard library instead">,
>>> + InGroup>;
>>> }
>>>
>>> Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=335081&r1=335080&r2=335081&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
>>> +++ cfe/trunk/include/clang/Lex/HeaderSearch.h Tue Jun 19 15:47:53 2018
>>> @@ -272,6 +272,8 @@ public:
>>>
>>>FileManager &getFileMgr() const { return FileMgr; }
>>>
>>> + DiagnosticsEngine &getDiags() const { return Diags; }
>>> +
>>>/// Interface for setting the file search paths.
>>>void SetSearchPaths(const std::vector &dirs,
>>>unsigned angledDirIdx, unsigned systemDirIdx,
>>>
>>> Modified: cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitHeaderSearch.cpp?rev=335081&r1=335080&r2=335081&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Frontend/InitHeaderSearch.cpp (original)
>>> +++ cfe/trunk/lib/Frontend/InitHeaderSearch.cpp Tue Jun 19 15:47:53 2018
>>> @@ -14,6 +14,7 @@
>>> #include "clang/Basic/FileManager.h"
>>> #include "clang/Basic/LangOptions.h"
>>> #include "clang/Config/config.h" // C_INCLUDE_DIRS
>>> +#include "clang/Frontend/FrontendDiagnostic.h"
>>> #include "clang/Frontend/Utils.h"
>>> #include "clang/Lex/HeaderMap.h"
>>> #include "clang/Lex/HeaderSearch.h"
>>> @@ -55,11 +56,13 @@ public:
>>>
>>>/// AddPath - Add the specified path to the specified group list,
>>> prefixing
>>>/// the sysroot if used.
>>> - void AddPath(const Twine &Path, IncludeDirGroup Group, bool
>>> isFramework);
>>> + /// Returns true if the path exists, false if it was ignored.
>>> + bool AddPath(const Twine &Path, IncludeDirGroup Group, bool
>>> isFramework);
>>>
>>>/// AddUnmappedPath - Add the specified path to the specified group
>>> list,
>>>/// without performing any sysroot remapping.
>>>
Re: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++
On Fri, 7 Sep 2018 at 05:41, Nico Weber wrote:
> On Wed, Sep 5, 2018 at 9:25 PM Alex L wrote:
>
>> Sorry for the late response,
>>
>> On Sat, 18 Aug 2018 at 20:10, Nico Weber wrote:
>>
>>> Also, the diag text should probably say "pass '-stdlib=libc++' " not
>>> "pass '-std=libc++' "?
>>>
>>
>> Good catch, thanks! I'll commit a fixup for it.
>>
>
Fixed in r341697.
>
>>
>>>
>>> On Sat, Aug 18, 2018 at 11:06 PM Nico Weber wrote:
>>>
Should this maybe not be emitted when compiling e.g. .ii files
(preprocessed output)? I just got this when I built a standalone .ii file
with some bug repro after I deleted all -I and -isysroot flags and whatnot,
since they aren't needed for preprocessed files.
>>>
>> That would make sense, but I'm not sure how easy it is to determine if a
>> file is already preprocessed. I'll try to create a patch for this fixup.
>>
>
> Probably you'd want something like
> http://llvm-cs.pcc.me.uk/tools/clang/lib/Driver/Types.cpp#123 that
> returns true for all (or most) of the TY_PP_ types, and then just rely
> on lookupTypeForExtension.
>
Good idea, I'll try it out.
>
>
>>
>>
>>
>>>
On Tue, Jun 19, 2018 at 6:52 PM Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Tue Jun 19 15:47:53 2018
> New Revision: 335081
>
> URL: http://llvm.org/viewvc/llvm-project?rev=335081&view=rev
> Log:
> Recommit r335063: [Darwin] Add a warning for missing include path for
> libstdc++
>
> The recommit ensures that the tests that failed on bots don't trigger
> the warning.
>
> Xcode 10 removes support for libstdc++, but the users just get a
> confusing
> include not file warning when including an STL header (when building
> for iOS6
> which uses libstdc++ by default for example).
> This patch adds a new warning that lets the user know that the
> libstdc++ include
> path was not found to ensure that the user is more aware of why the
> error occurs.
>
> rdar://40830462
>
> Differential Revision: https://reviews.llvm.org/D48297
>
> Added:
> cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> cfe/trunk/include/clang/Lex/HeaderSearch.h
> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
> cfe/trunk/test/CodeGenCXX/apple-kext-guard-variable.cpp
> cfe/trunk/test/Misc/backend-stack-frame-diagnostics.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=335081&r1=335080&r2=335081&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Jun
> 19 15:47:53 2018
> @@ -236,4 +236,9 @@ def err_invalid_vfs_overlay : Error<
>
> def warn_option_invalid_ocl_version : Warning<
>"OpenCL version %0 does not support the option '%1'">,
> InGroup;
> +
> +def warn_stdlibcxx_not_found : Warning<
> + "include path for stdlibc++ headers not found; pass '-std=libc++'
> on the "
> + "command line to use the libc++ standard library instead">,
> + InGroup>;
> }
>
> Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=335081&r1=335080&r2=335081&view=diff
>
> ==
> --- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
> +++ cfe/trunk/include/clang/Lex/HeaderSearch.h Tue Jun 19 15:47:53 2018
> @@ -272,6 +272,8 @@ public:
>
>FileManager &getFileMgr() const { return FileMgr; }
>
> + DiagnosticsEngine &getDiags() const { return Diags; }
> +
>/// Interface for setting the file search paths.
>void SetSearchPaths(const std::vector &dirs,
>unsigned angledDirIdx, unsigned systemDirIdx,
>
> Modified: cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitHeaderSearch.cpp?rev=335081&r1=335080&r2=335081&view=diff
>
> ==
> --- cfe/trunk/lib/Frontend/InitHeaderSearch.cpp (original)
> +++ cfe/trunk/lib/Frontend/InitHeaderSearch.cpp Tue Jun 19 15:47:53
> 2018
> @@ -14,6 +14,7 @@
> #include "clang/Basic/FileManager.h"
> #include "clang/Basic/LangOptions.h"
> #include "clang/Config/config.h" // C_INCLUDE_DIRS
> +#include "clang/Frontend/FrontendDiagnostic.h"
> #include "clang/Frontend/Utils.h"
Re: [libcxx] r337727 - [CMake] Fix the setting of LIBCXX_HEADER_DIR
The revert commit is r337782.
On 23 July 2018 at 17:32, Alex L wrote:
> Hi,
>
> I had to revert your commit as it caused a number of failures in our
> public and internal CI.
> When building compiler-rt on Darwin (stage1), after this commit the build
> failed to build X-ray and libfuzzer because the libc++ headers were no
> longer found. The compiler-rt libraries were built using freshly built
> stage1, so it makes sense why this happened (clang expected to find the
> libc++ headers in ../include, but they got moved to
> ../projects/libcxx/include).
> Here are a couple of examples of the failures that we've observed:
>
> http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA/47583/console
> /Users/buildslave/jenkins/workspace/clang-stage1-
> configure-RA/llvm/projects/compiler-rt/lib/xray/xray_utils.h:18:10: fatal
> error: 'cstddef' file not found
> #include
> ^
> 1 error generated.
>
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-
> RA-expensive/12202/consoleFull
> /Users/buildslave/jenkins/workspace/clang-stage1-cmake-
> RA-expensive/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDefs.h:15:10:
> fatal error: 'cassert' file not found
> #include
> ^
> 1 error generated.
>
> Let me know if you need help looking at or testing out a potential fix for
> Darwin.
> Thanks,
> Alex
>
>
> On 23 July 2018 at 11:58, Heejin Ahn via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: aheejin
>> Date: Mon Jul 23 11:58:12 2018
>> New Revision: 337727
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=337727&view=rev
>> Log:
>> [CMake] Fix the setting of LIBCXX_HEADER_DIR
>>
>> Reviewers: phosek
>>
>> Subscribers: mgorny, christof, ldionne, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D49629
>>
>> Modified:
>> libcxx/trunk/CMakeLists.txt
>>
>> Modified: libcxx/trunk/CMakeLists.txt
>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.
>> txt?rev=337727&r1=337726&r2=337727&view=diff
>>
>> ==
>> --- libcxx/trunk/CMakeLists.txt (original)
>> +++ libcxx/trunk/CMakeLists.txt Mon Jul 23 11:58:12 2018
>> @@ -378,7 +378,7 @@ endif ()
>> set(LIBCXX_COMPILER${CMAKE_CXX_COMPILER})
>> set(LIBCXX_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
>> set(LIBCXX_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
>> -set(LIBCXX_HEADER_DIR ${LLVM_BINARY_DIR})
>> +set(LIBCXX_HEADER_DIR ${LIBCXX_BINARY_DIR})
>> set(LIBCXX_BINARY_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++build")
>>
>> string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" CLANG_VERSION
>>
>>
>> ___
>> 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: [libcxx] r337727 - [CMake] Fix the setting of LIBCXX_HEADER_DIR
Hi,
I had to revert your commit as it caused a number of failures in our public
and internal CI.
When building compiler-rt on Darwin (stage1), after this commit the build
failed to build X-ray and libfuzzer because the libc++ headers were no
longer found. The compiler-rt libraries were built using freshly built
stage1, so it makes sense why this happened (clang expected to find the
libc++ headers in ../include, but they got moved to
../projects/libcxx/include).
Here are a couple of examples of the failures that we've observed:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA/47583/console
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/compiler-rt/lib/xray/xray_utils.h:18:10:
fatal error: 'cstddef' file not found
#include
^
1 error generated.
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/12202/consoleFull
/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-expensive/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDefs.h:15:10:
fatal error: 'cassert' file not found
#include
^
1 error generated.
Let me know if you need help looking at or testing out a potential fix for
Darwin.
Thanks,
Alex
On 23 July 2018 at 11:58, Heejin Ahn via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: aheejin
> Date: Mon Jul 23 11:58:12 2018
> New Revision: 337727
>
> URL: http://llvm.org/viewvc/llvm-project?rev=337727&view=rev
> Log:
> [CMake] Fix the setting of LIBCXX_HEADER_DIR
>
> Reviewers: phosek
>
> Subscribers: mgorny, christof, ldionne, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D49629
>
> Modified:
> libcxx/trunk/CMakeLists.txt
>
> Modified: libcxx/trunk/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/
> CMakeLists.txt?rev=337727&r1=337726&r2=337727&view=diff
>
> ==
> --- libcxx/trunk/CMakeLists.txt (original)
> +++ libcxx/trunk/CMakeLists.txt Mon Jul 23 11:58:12 2018
> @@ -378,7 +378,7 @@ endif ()
> set(LIBCXX_COMPILER${CMAKE_CXX_COMPILER})
> set(LIBCXX_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
> set(LIBCXX_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
> -set(LIBCXX_HEADER_DIR ${LLVM_BINARY_DIR})
> +set(LIBCXX_HEADER_DIR ${LIBCXX_BINARY_DIR})
> set(LIBCXX_BINARY_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++build")
>
> string(REGEX MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?" CLANG_VERSION
>
>
> ___
> 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] r338518 - [clangd] Receive compilationDatabasePath in 'initialize' request
Is there a particular reason why this commit didn't have a corresponding
test included?
Cheers,
Alex
On 1 August 2018 at 04:28, Simon Marchi via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: simark
> Date: Wed Aug 1 04:28:49 2018
> New Revision: 338518
>
> URL: http://llvm.org/viewvc/llvm-project?rev=338518&view=rev
> Log:
> [clangd] Receive compilationDatabasePath in 'initialize' request
>
> Summary:
> That way, as soon as the "initialize" is received by the server, it can
> start
> parsing/indexing with a valid compilation database and not have to wait
> for a
> an initial 'didChangeConfiguration' that might or might not happen.
> Then, when the user changes configuration, a didChangeConfiguration can be
> sent.
>
> Signed-off-by: Marc-Andre Laperle
>
> Reviewers: malaperle
>
> Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D49833
>
> Modified:
> clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> clang-tools-extra/trunk/clangd/ClangdLSPServer.h
> clang-tools-extra/trunk/clangd/Protocol.cpp
> clang-tools-extra/trunk/clangd/Protocol.h
>
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/ClangdLSPServer.cpp?rev=338518&r1=338517&r2=338518&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Wed Aug 1
> 04:28:49 2018
> @@ -72,6 +72,9 @@ SymbolKindBitset defaultSymbolKinds() {
> } // namespace
>
> void ClangdLSPServer::onInitialize(InitializeParams &Params) {
> + if (Params.initializationOptions)
> +applyConfiguration(*Params.initializationOptions);
> +
>if (Params.rootUri && *Params.rootUri)
> Server.setRootPath(Params.rootUri->file());
>else if (Params.rootPath && !Params.rootPath->empty())
> @@ -398,11 +401,8 @@ void ClangdLSPServer::onHover(TextDocume
> });
> }
>
> -// FIXME: This function needs to be properly tested.
> -void ClangdLSPServer::onChangeConfiguration(
> -DidChangeConfigurationParams &Params) {
> - ClangdConfigurationParamsChange &Settings = Params.settings;
> -
> +void ClangdLSPServer::applyConfiguration(
> +const ClangdConfigurationParamsChange &Settings) {
>// Compilation database change.
>if (Settings.compilationDatabasePath.hasValue()) {
> NonCachedCDB.setCompileCommandsDir(
> @@ -413,6 +413,12 @@ void ClangdLSPServer::onChangeConfigurat
>}
> }
>
> +// FIXME: This function needs to be properly tested.
> +void ClangdLSPServer::onChangeConfiguration(
> +DidChangeConfigurationParams &Params) {
> + applyConfiguration(Params.settings);
> +}
> +
> ClangdLSPServer::ClangdLSPServer(JSONOutput &Out,
> const clangd::CodeCompleteOptions
> &CCOpts,
> llvm::Optional CompileCommandsDir,
>
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/ClangdLSPServer.h?rev=338518&r1=338517&r2=338518&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Wed Aug 1 04:28:49
> 2018
> @@ -82,6 +82,7 @@ private:
>/// may be very expensive. This method is normally called when the
>/// compilation database is changed.
>void reparseOpenedFiles();
> + void applyConfiguration(const ClangdConfigurationParamsChange
> &Settings);
>
>JSONOutput &Out;
>/// Used to indicate that the 'shutdown' request was received from the
>
> Modified: clang-tools-extra/trunk/clangd/Protocol.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/Protocol.cpp?rev=338518&r1=338517&r2=338518&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/Protocol.cpp (original)
> +++ clang-tools-extra/trunk/clangd/Protocol.cpp Wed Aug 1 04:28:49 2018
> @@ -263,7 +263,7 @@ bool fromJSON(const json::Value &Params,
>O.map("rootPath", R.rootPath);
>O.map("capabilities", R.capabilities);
>O.map("trace", R.trace);
> - // initializationOptions, capabilities unused
> + O.map("initializationOptions", R.initializationOptions);
>return true;
> }
>
>
> Modified: clang-tools-extra/trunk/clangd/Protocol.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/Protocol.h?rev=338518&r1=338517&r2=338518&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/Protocol.h (original)
> +++ clang-tools-extra/trunk/clangd/Protocol.h Wed Aug 1 04:28:49 2018
> @@ -322,6 +322,16 @@ struct ClientCapa
Re: [clang-tools-extra] r338518 - [clangd] Receive compilationDatabasePath in 'initialize' request
On 1 August 2018 at 11:21, Simon Marchi wrote: > On 2018-08-01 01:30 PM, Alex L wrote: > > Is there a particular reason why this commit didn't have a corresponding > test included? > > Cheers, > > Alex > > Back when we made the corresponding change in "onChangeConfiguration", > there was no > straightforward way to make a lit test for it: > > https://reviews.llvm.org/D39571?id=124024#inline-359345 > > I am not sure, but I think the issue was that we had to hard-code the > length of the > messages we sent. Since we had to use temp directory names, the length > was not > known in advance. I don't think we have that limitation anymore. > Yes, I believe this limitation doesn't exist anymore. > > We would need to create a temporary directory hierarchy, and then refer to > it in > the messages we send to switch between build configurations. Is it > something that > sounds possible with lit? Do you know about other tests doing something > similar? > I think it's be possible, albeit in a more complicated way than the regular Clangd test. We just need to generate a new test file that we can give to the Clangd from the included test file. I think this kind of solution should work (*) : First, you would create a temporary directory in lit: RUN: rm -rf %t.dir RUN: mkdir %t.dir RUN: ... populate the temporary directory ... Then, you would generate the input file (i.e. replace INPUT_DIR in the original test with the temporary directory): RUN: rm -rf %t.test RUN: sed -e "s:INPUT_DIR:%t.dir:g" %s > %t.test And then you can invoke the test: RUN: clang -lit-test < %t.test | FileCheck -strict-whitespace %s * The only problem might be JSON string encoding of the INPUT_DIR (i.e. you'll generate a test file that contains "C:\\temp\foo" on Windows, which would be invalid JSON string). You should be able to use 'sed' here as well to fix this up. Thanks, Alex > > Thanks, > > Simon > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r305719 - [Parser][ObjC] Use an artificial EOF token while parsing lexed ObjC methods
On 20 June 2017 at 16:53, Duncan P. N. Exon Smith
wrote:
>
> On Jun 19, 2017, at 10:53, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: arphaman
> Date: Mon Jun 19 12:53:21 2017
> New Revision: 305719
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305719&view=rev
> Log:
> [Parser][ObjC] Use an artificial EOF token while parsing lexed ObjC methods
>
> This change avoid a crash that occurred when skipping to EOF while parsing
> an
> ObjC interface/implementation.
>
> rdar://31963299
>
> Differential Revision: https://reviews.llvm.org/D34185
>
> Added:
>cfe/trunk/test/Parser/objc-at-implementation-eof-crash.m
>cfe/trunk/test/Parser/objc-at-interface-eof-crash.m
> Modified:
>cfe/trunk/lib/Parse/ParseObjc.cpp
>
> Modified: cfe/trunk/lib/Parse/ParseObjc.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/
> ParseObjc.cpp?rev=305719&r1=305718&r2=305719&view=diff
>
> ==
> --- cfe/trunk/lib/Parse/ParseObjc.cpp (original)
> +++ cfe/trunk/lib/Parse/ParseObjc.cpp Mon Jun 19 12:53:21 2017
> @@ -3627,6 +3627,14 @@ void Parser::ParseLexedObjCMethodDefs(Le
> SourceLocation OrigLoc = Tok.getLocation();
>
> assert(!LM.Toks.empty() && "ParseLexedObjCMethodDef - Empty body!");
> + // Store an artificial EOF token to ensure that we don't run off the
> end of
> + // the method's body when we come to parse it.
> + Token Eof;
> + Eof.startToken();
> + Eof.setKind(tok::eof);
> + Eof.setEofData(MCDecl);
> + Eof.setLocation(OrigLoc);
> + LM.Toks.push_back(Eof);
> // Append the current token at the end of the new token stream so that it
> // doesn't get lost.
> LM.Toks.push_back(Tok);
> @@ -3658,7 +3666,7 @@ void Parser::ParseLexedObjCMethodDefs(Le
> Actions.ActOnDefaultCtorInitializers(MCDecl);
> ParseFunctionStatementBody(MCDecl, BodyScope);
> }
> -
> +
> if (Tok.getLocation() != OrigLoc) {
> // Due to parsing error, we either went over the cached tokens or
> // there are still cached tokens left. If it's the latter case skip the
> @@ -3670,4 +3678,6 @@ void Parser::ParseLexedObjCMethodDefs(Le
> while (Tok.getLocation() != OrigLoc && Tok.isNot(tok::eof))
> ConsumeAnyToken();
> }
> + // Clean up the remaining EOF token.
> + ConsumeAnyToken();
> }
>
> Added: cfe/trunk/test/Parser/objc-at-implementation-eof-crash.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/
> objc-at-implementation-eof-crash.m?rev=305719&view=auto
>
> ==
> --- cfe/trunk/test/Parser/objc-at-implementation-eof-crash.m (added)
> +++ cfe/trunk/test/Parser/objc-at-implementation-eof-crash.m Mon Jun 19
> 12:53:21 2017
> @@ -0,0 +1,21 @@
> +// RUN: %clang_cc1 -verify -Wno-objc-root-class %s
> +
> +@interface ClassA
> +
> +- (void)fileExistsAtPath:(int)x;
> +
> +@end
> +
> +@interface ClassB
> +
> +@end
> +
> +@implementation ClassB // expected-note {{implementation started here}}
> +
> +- (void) method:(ClassA *)mgr { // expected-note {{to match this '{'}}
> + mgr fileExistsAtPath:0
> +} // expected-error {{expected ']'}}
> +
> +@implementation ClassC // expected-error {{missing '@end'}} //
> expected-error {{expected '}'}} // expected-warning {{cannot find interface
> declaration for 'ClassC'}}
>
>
> I believe you can split these expectations over multiple lines. Something
> like this seems more readable:
>
> @implementation ClassC \
> // expected-error {{missing '@end'}} \
> // expected-error {{expected '}'}} \
> // expected-warning {{cannot find interface declaration for 'ClassC'}}
>
>
Thanks, addressed in r305803!
>
> +
> +@end
>
> Added: cfe/trunk/test/Parser/objc-at-interface-eof-crash.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/
> objc-at-interface-eof-crash.m?rev=305719&view=auto
>
> ==
> --- cfe/trunk/test/Parser/objc-at-interface-eof-crash.m (added)
> +++ cfe/trunk/test/Parser/objc-at-interface-eof-crash.m Mon Jun 19
> 12:53:21 2017
> @@ -0,0 +1,21 @@
> +// RUN: %clang_cc1 -verify -Wno-objc-root-class %s
> +
> +@interface ClassA
> +
> +- (void)fileExistsAtPath:(int)x;
> +
> +@end
> +
> +@interface ClassB
> +
> +@end
> +
> +@implementation ClassB // expected-note {{implementation started here}}
> +
> +- (void) method:(ClassA *)mgr { // expected-note {{to match this '{'}}
> + mgr fileExistsAtPath:0
> +} // expected-error {{expected ']'}}
> +
> +@interface ClassC // expected-error {{missing '@end'}} // expected-error
> {{expected '}'}}
>
>
> Same recommendation as above.
>
> +
> +@end
>
>
> ___
> 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.ll
Re: r320734 - [Preprocessor] Implement __is_target_{arch|vendor|os|environment} function-like
Sorry, I forgot to add the tests in SVN. I committed them in 320735
On 14 December 2017 at 11:22, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Thu Dec 14 11:22:02 2017
> New Revision: 320734
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320734&view=rev
> Log:
> [Preprocessor] Implement __is_target_{arch|vendor|os|environment}
> function-like
> builtin macros
>
> This patch implements the __is_target_arch, __is_target_vendor,
> __is_target_os,
> and __is_target_environment Clang preprocessor extensions that were
> proposed by
> @compnerd in Bob's cfe-dev post:
> http://lists.llvm.org/pipermail/cfe-dev/2017-November/056166.html.
>
> These macros can be used to examine the components of the target triple at
> compile time. A has_builtin(is_target_???) preprocessor check can be used
> to
> check for their availability.
>
> __is_target_arch allows you to check if an arch is specified without
> worring
> about a specific subarch, e.g.
>
> __is_target_arch(arm) returns 1 for the target arch "armv7"
> __is_target_arch(armv7) returns 1 for the target arch "armv7"
> __is_target_arch(armv6) returns 0 for the target arch "armv7"
>
> __is_target_vendor and __is_target_environment match the specific vendor
> or environment. __is_target_os matches the specific OS, but
> __is_target_os(darwin) will match any Darwin-based OS. "Unknown" can be
> used
> to test if the triple's component is specified.
>
> rdar://35753116
>
> Differential Revision: https://reviews.llvm.org/D41087
>
> Modified:
> cfe/trunk/docs/ReleaseNotes.rst
> cfe/trunk/include/clang/Lex/Preprocessor.h
> cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>
> Modified: cfe/trunk/docs/ReleaseNotes.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> ReleaseNotes.rst?rev=320734&r1=320733&r2=320734&view=diff
>
> ==
> --- cfe/trunk/docs/ReleaseNotes.rst (original)
> +++ cfe/trunk/docs/ReleaseNotes.rst Thu Dec 14 11:22:02 2017
> @@ -110,6 +110,10 @@ Non-comprehensive list of changes in thi
>If a gcc installation is found, it still prefers ``.ctors`` if the found
>gcc is older than 4.7.0.
>
> +- The new builtin preprocessor macros ``__is_target_arch``,
> + ``__is_target_vendor``, ``__is_target_os``, and
> ``__is_target_environment``
> + can be used to to examine the individual components of the target
> triple.
> +
> New Compiler Flags
> --
>
>
> Modified: cfe/trunk/include/clang/Lex/Preprocessor.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Lex/Preprocessor.h?rev=320734&r1=320733&r2=320734&view=diff
>
> ==
> --- cfe/trunk/include/clang/Lex/Preprocessor.h (original)
> +++ cfe/trunk/include/clang/Lex/Preprocessor.h Thu Dec 14 11:22:02 2017
> @@ -175,6 +175,10 @@ class Preprocessor {
>IdentifierInfo *Ident__has_cpp_attribute;// __has_cpp_attribute
>IdentifierInfo *Ident__has_c_attribute; // __has_c_attribute
>IdentifierInfo *Ident__has_declspec; //
> __has_declspec_attribute
> + IdentifierInfo *Ident__is_target_arch; // __is_target_arch
> + IdentifierInfo *Ident__is_target_vendor; // __is_target_vendor
> + IdentifierInfo *Ident__is_target_os; // __is_target_os
> + IdentifierInfo *Ident__is_target_environment;//
> __is_target_environment
>
>SourceLocation DATELoc, TIMELoc;
>
>
> Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/
> PPMacroExpansion.cpp?rev=320734&r1=320733&r2=320734&view=diff
>
> ==
> --- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
> +++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Thu Dec 14 11:22:02 2017
> @@ -375,6 +375,11 @@ void Preprocessor::RegisterBuiltinMacros
>Ident__has_include_next = RegisterBuiltinMacro(*this,
> "__has_include_next");
>Ident__has_warning = RegisterBuiltinMacro(*this, "__has_warning");
>Ident__is_identifier= RegisterBuiltinMacro(*this,
> "__is_identifier");
> + Ident__is_target_arch = RegisterBuiltinMacro(*this,
> "__is_target_arch");
> + Ident__is_target_vendor = RegisterBuiltinMacro(*this,
> "__is_target_vendor");
> + Ident__is_target_os = RegisterBuiltinMacro(*this, "__is_target_os");
> + Ident__is_target_environment =
> + RegisterBuiltinMacro(*this, "__is_target_environment");
>
>// Modules.
>Ident__building_module = RegisterBuiltinMacro(*this,
> "__building_module");
> @@ -1593,6 +1598,57 @@ static IdentifierInfo *ExpectFeatureIden
>return nullptr;
> }
>
> +/// Implements the __is_target_arch builtin macro.
> +static bool isTargetArch(const TargetInfo &TI, const IdentifierInfo *II) {
> + std::string ArchName = II->getName().lower() + "--";
> + llvm::Triple Arch(ArchName);
> + const ll
Re: r313729 - Implement C++ [basic.link]p8.
Hi Richard,
This commit has caused a new regression in Clang which causes an assertion
failure for extern "C" function definitions whose return type is a pointer
to a record. I filed https://bugs.llvm.org/show_bug.cgi?id=35697 which
contains the minimized test case for this issue. Do you mind taking a look
at it?
Cheers,
Alex
On 20 September 2017 at 00:22, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Wed Sep 20 00:22:00 2017
> New Revision: 313729
>
> URL: http://llvm.org/viewvc/llvm-project?rev=313729&view=rev
> Log:
> Implement C++ [basic.link]p8.
>
> If a function or variable has a type with no linkage (and is not extern
> "C"),
> any use of it requires a definition within the same translation unit; the
> idea
> is that it is not possible to define the entity elsewhere, so any such use
> is
> necessarily an error.
>
> There is an exception, though: some types formally have no linkage but
> nonetheless can be referenced from other translation units (for example,
> this
> happens to anonymous structures defined within inline functions). For
> entities
> with those types, we suppress the diagnostic except under -pedantic.
>
> Added:
> cfe/trunk/test/CXX/basic/basic.link/p8.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/include/clang/Sema/SemaInternal.h
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/Sema/Sema.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/test/Analysis/malloc.mm
> cfe/trunk/test/Analysis/reference.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-method.cpp
> cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
> cfe/trunk/test/CodeGenCXX/mangle.cpp
> cfe/trunk/test/PCH/cxx11-lambdas.mm
> cfe/trunk/test/SemaCXX/warn-unreachable.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=313729&r1=313728&r2=313729&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Sep 20
> 00:22:00 2017
> @@ -4707,6 +4707,14 @@ def note_deleted_assign_field : Note<
> def warn_undefined_internal : Warning<
>"%select{function|variable}0 %q1 has internal linkage but is not
> defined">,
>InGroup>;
> +def err_undefined_internal_type : Error<
> + "%select{function|variable}0 %q1 is used but not defined in this "
> + "translation unit, and cannot be defined in any other translation unit "
> + "because its type does not have linkage">;
> +def ext_undefined_internal_type : Extension<
> + "ISO C++ requires a definition in this translation unit for "
> + "%select{function|variable}0 %q1 because its type does not have
> linkage">,
> + InGroup>;
> def warn_undefined_inline : Warning<"inline function %q0 is not defined">,
>InGroup>;
> def err_undefined_inline_var : Error<"inline variable %q0 is not
> defined">;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/Sema.h?rev=313729&r1=313728&r2=313729&view=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Wed Sep 20 00:22:00 2017
> @@ -1086,6 +1086,11 @@ public:
>/// definition in this translation unit.
>llvm::MapVector UndefinedButUsed;
>
> + /// Determine if VD, which must be a variable or function, is an
> external
> + /// symbol that nonetheless can't be referenced from outside this
> translation
> + /// unit because its type has no linkage and it's not extern "C".
> + bool isExternalWithNoLinkageType(ValueDecl *VD);
> +
>/// Obtain a sorted list of functions that are undefined but ODR-used.
>void getUndefinedButUsed(
>SmallVectorImpl >
> &Undefined);
>
> Modified: cfe/trunk/include/clang/Sema/SemaInternal.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/SemaInternal.h?rev=313729&r1=313728&r2=313729&view=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/SemaInternal.h (original)
> +++ cfe/trunk/include/clang/Sema/SemaInternal.h Wed Sep 20 00:22:00 2017
> @@ -73,7 +73,8 @@ inline void MarkVarDeclODRUsed(VarDecl *
>// Keep track of used but undefined variables.
>// FIXME: We shouldn't suppress this warning for static data members.
>if (Var->hasDefinition(SemaRef.Context) == VarDecl::DeclarationOnly &&
> - (!Var->isExternallyVisible() || Var->isInline()) &&
> + (!Var->isExternallyVisible() || Var->isInline() ||
> + SemaRef.isExternalWithNoLinkageType(Var)) &&
>!(Var->isStaticDataMember() && Var->hasI
Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target
Thanks for raising your concerns.
We decided to avoid -m-version-min flag in favor of -target to simplify
the driver logic and to encourage the adoption of -target. Now after r321145
we only warn about -m-version-min flag when the OS version specified in
it is different to the OS version specified in target, or when target has
no OS version.
There are two possible solutions here:
1) You can still use -target with -mios-simulator-version-min as before but
you'd have to use '-target=x86_64-apple-darwin' to ensure that the iOS
version specified by '-mios-simulator-version-min' is used.
2) I also do have a patch that implements the logic that you propose (use
the OS version in -m-version-min flag if target has none). If you
believe that the first solution is not suitable for your code then I can
commit it. At the same time I believe that we would rather not use this
patch, but if it's urgent for your projects then maybe I can land it now
and then we can establish some sort of timeline for when it can be reverted?
Thanks,
Alex
On 21 December 2017 at 08:00, James Y Knight wrote:
> I think if a version number isn't explicitly specified in the -target
> value, the value from -m-version-min ought to still be used, as
> it was before.
>
> Currently, clang will ignore the -m-version-min version number
> if the target has a particular OS specified, even if it has no version
> number as part of it.
>
> (We should be able to workaround this change backwards-compatibly by
> specifying in both the -target argument and in the -m-version-min
> arguments, but I do think the behavior should be fixed.)
>
> On Thu, Dec 21, 2017 at 10:45 AM, Martin Böhme wrote:
>
>> This is causing problems in some internal builds that specify both
>> -mios-simulator-version-min=9.0 and --target=x86_64-apple-ios
>>
>> My expectation would be for the code to take the minimum OS version
>> number from the -mios-simulator-version-min flag. In fact, however, the
>> code seems to be completely ignoring this flag.
>>
>> Is my expectation wrong or does the code need to be modified to take this
>> situation into account?
>>
>>
>> On 19 December 2017 at 20:05, Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Tue Dec 19 11:05:04 2017
>>> New Revision: 321099
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=321099&view=rev
>>> Log:
>>> [driver][darwin] Take the OS version specified in "-target" as the target
>>> OS instead of inferring it from SDK / environment
>>>
>>> The OS version is specified in -target should be used instead of the one
>>> in an
>>> environment variable / SDK name.
>>>
>>> rdar://35813850
>>>
>>> Differential Revision: https://reviews.llvm.org/D40998
>>>
>>> Modified:
>>> cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>>> cfe/trunk/test/Driver/darwin-version.c
>>> cfe/trunk/test/Driver/objc-weak.m
>>> cfe/trunk/test/Driver/pic.c
>>> cfe/trunk/test/Driver/unavailable_aligned_allocation.cpp
>>>
>>> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Too
>>> lChains/Darwin.cpp?rev=321099&r1=321098&r2=321099&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
>>> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Tue Dec 19 11:05:04 2017
>>> @@ -1233,6 +1233,10 @@ struct DarwinPlatform {
>>> llvm_unreachable("Unsupported Darwin Source Kind");
>>>}
>>>
>>> + static DarwinPlatform createFromTarget(llvm::Triple::OSType OS,
>>> + StringRef OSVersion, Arg *A) {
>>> +return DarwinPlatform(TargetArg, getPlatformFromOS(OS), OSVersion,
>>> A);
>>> + }
>>>static DarwinPlatform createOSVersionArg(DarwinPlatformKind Platform,
>>> Arg *A) {
>>> return DarwinPlatform(OSVersionArg, Platform, A);
>>> @@ -1250,33 +1254,32 @@ struct DarwinPlatform {
>>>}
>>>static DarwinPlatform createFromArch(llvm::Triple::OSType OS,
>>> StringRef Value) {
>>> -DarwinPlatformKind Platform;
>>> +return DarwinPlatform(InferredFromArch, getPlatformFromOS(OS),
>>> Value);
>>> + }
>>> +
>>> +private:
>>> + DarwinPlatform(SourceKind Kind, DarwinPlatformKind Platform, Arg
>>> *Argument)
>>> + : Kind(Kind), Platform(Platform), Argument(Argument) {}
>>> + DarwinPlatform(SourceKind Kind, DarwinPlatformKind Platform,
>>> StringRef Value,
>>> + Arg *Argument = nullptr)
>>> + : Kind(Kind), Platform(Platform), OSVersion(Value),
>>> Argument(Argument) {}
>>> +
>>> + static DarwinPlatformKind getPlatformFromOS(llvm::Triple::OSType OS)
>>> {
>>> switch (OS) {
>>> case llvm::Triple::Darwin:
>>> case llvm::Triple::MacOSX:
>>> - Platform = DarwinPlatformKind::MacOS;
>>> - break;
>>> + return DarwinPlatformKind::MacOS;
>>>
Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target
On 21 December 2017 at 12:34, James Y Knight wrote:
> I totally agree with moving towards eliminating the -m-version-min
> flags, it's much better to put it in the target, and will clean up a lot of
> cruft in the driver, eventually.
>
> Now -- we (or anyone else who runs into this) can simply start specifying
> the version in both locations ("-target x86_64-apple-ios10
> -mios-simulator-version-min=10"), so as to work with both new and old
> clang, and be closer to the ultimate goal of having only -target. That's an
> overall nicer workaround to suggest than switching to -darwin. But, yea,
> there's no need for *temporary* patch to fix things just for us.
>
> However, I do not understand why you're against committing the patch you
> mention as option #2 -- that seems like it'd be best for all users, by
> preserving compatibility with existing command-lines. So, I'd still like
> that change to be committed, permanently, not temporarily. I'm sure we
> can't be the only ones running clang like "-target x86_64-apple-ios
> -mios-simulator-version-min=10", and it seems unfortunate and unnecessary
> to break that, even if it can be worked around.
>
> In the future, I'd hope the -m-version-min arguments can be deprecated
> more and more -- warning whenever you use them to modify the platform or
> version at all, rather just on specification conflict; then, warn anytime
> you use them at all; then, remove them. But in the meantime, it seems
> strictly better to preserve compatibility, don't you think?
>
+ Duncan
Thanks, I think your argument is convincing. I think I will commit the
change that you're proposing in the near future if there are no further
objections.
>
>
>
> On Dec 21, 2017 2:11 PM, "Alex L" wrote:
>
> Thanks for raising your concerns.
>
> We decided to avoid -m-version-min flag in favor of -target to
> simplify the driver logic and to encourage the adoption of -target. Now
> after r321145 we only warn about -m-version-min flag when the OS
> version specified in it is different to the OS version specified in target,
> or when target has no OS version.
>
> There are two possible solutions here:
> 1) You can still use -target with -mios-simulator-version-min as before
> but you'd have to use '-target=x86_64-apple-darwin' to ensure that the iOS
> version specified by '-mios-simulator-version-min' is used.
> 2) I also do have a patch that implements the logic that you propose (use
> the OS version in -m-version-min flag if target has none). If you
> believe that the first solution is not suitable for your code then I can
> commit it. At the same time I believe that we would rather not use this
> patch, but if it's urgent for your projects then maybe I can land it now
> and then we can establish some sort of timeline for when it can be reverted?
>
> Thanks,
> Alex
>
>
> On 21 December 2017 at 08:00, James Y Knight wrote:
>
>> I think if a version number isn't explicitly specified in the -target
>> value, the value from -m-version-min ought to still be used, as
>> it was before.
>>
>> Currently, clang will ignore the -m-version-min version number
>> if the target has a particular OS specified, even if it has no version
>> number as part of it.
>>
>> (We should be able to workaround this change backwards-compatibly by
>> specifying in both the -target argument and in the -m-version-min
>> arguments, but I do think the behavior should be fixed.)
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r315984 - [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info
Hi,
This commit has caused a new regression in LLVM 6. I filed the following
PR: https://bugs.llvm.org/show_bug.cgi?id=35724 .
Could you please take a look?
Thanks,
Alex
On 17 October 2017 at 02:12, Ivan A. Kosarev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: kosarev
> Date: Tue Oct 17 02:12:13 2017
> New Revision: 315984
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315984&view=rev
> Log:
> [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with
> LValue base info
>
> Differential Revision: https://reviews.llvm.org/D38796
>
> Added:
> cfe/trunk/test/CodeGen/tbaa-cast.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGExpr.cpp
> cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
> cfe/trunk/lib/CodeGen/CodeGenFunction.h
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.h
> cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
> cfe/trunk/lib/CodeGen/CodeGenTBAA.h
>
> Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CGExpr.cpp?rev=315984&r1=315983&r2=315984&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExpr.cpp Tue Oct 17 02:12:13 2017
> @@ -916,7 +916,8 @@ void CodeGenModule::EmitExplicitCastExpr
> /// EmitPointerWithAlignment - Given an expression of pointer type, try to
> /// derive a more accurate bound on the alignment of the pointer.
> Address CodeGenFunction::EmitPointerWithAlignment(const Expr *E,
> - LValueBaseInfo
> *BaseInfo) {
> + LValueBaseInfo
> *BaseInfo,
> + TBAAAccessInfo
> *TBAAInfo) {
>// We allow this with ObjC object pointers because of fragile ABIs.
>assert(E->getType()->isPointerType() ||
> E->getType()->isObjCObjectPointerType());
> @@ -936,20 +937,30 @@ Address CodeGenFunction::EmitPointerWith
> if (PtrTy->getPointeeType()->isVoidType())
>break;
>
> -LValueBaseInfo InnerInfo;
> -Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
> &InnerInfo);
> -if (BaseInfo) *BaseInfo = InnerInfo;
> -
> -// If this is an explicit bitcast, and the source l-value is
> -// opaque, honor the alignment of the casted-to type.
> -if (isa(CE) &&
> -InnerInfo.getAlignmentSource() != AlignmentSource::Decl) {
> - LValueBaseInfo ExpInfo;
> +LValueBaseInfo InnerBaseInfo;
> +TBAAAccessInfo InnerTBAAInfo;
> +Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
> +&InnerBaseInfo,
> +&InnerTBAAInfo);
> +if (BaseInfo) *BaseInfo = InnerBaseInfo;
> +if (TBAAInfo) *TBAAInfo = InnerTBAAInfo;
> +
> +if (isa(CE)) {
> + LValueBaseInfo TargetTypeBaseInfo;
> + TBAAAccessInfo TargetTypeTBAAInfo;
>CharUnits Align = getNaturalPointeeTypeAlignment(E->getType(),
> - &ExpInfo);
> - if (BaseInfo)
> -BaseInfo->mergeForCast(ExpInfo);
> - Addr = Address(Addr.getPointer(), Align);
> +
> &TargetTypeBaseInfo,
> +
> &TargetTypeTBAAInfo);
> + if (TBAAInfo)
> +*TBAAInfo = CGM.mergeTBAAInfoForCast(*TBAAInfo,
> + TargetTypeTBAAInfo);
> + // If the source l-value is opaque, honor the alignment of the
> + // casted-to type.
> + if (InnerBaseInfo.getAlignmentSource() !=
> AlignmentSource::Decl) {
> +if (BaseInfo)
> + BaseInfo->mergeForCast(TargetTypeBaseInfo);
> +Addr = Address(Addr.getPointer(), Align);
> + }
> }
>
> if (SanOpts.has(SanitizerKind::CFIUnrelatedCast) &&
> @@ -969,12 +980,13 @@ Address CodeGenFunction::EmitPointerWith
>
> // Array-to-pointer decay.
> case CK_ArrayToPointerDecay:
> - return EmitArrayToPointerDecay(CE->getSubExpr(), BaseInfo);
> + return EmitArrayToPointerDecay(CE->getSubExpr(), BaseInfo,
> TBAAInfo);
>
> // Derived-to-base conversions.
> case CK_UncheckedDerivedToBase:
> case CK_DerivedToBase: {
> - Address Addr = EmitPointerWithAlignment(CE->getSubExpr(),
> BaseInfo);
> + Address Addr = EmitPointerWithAlignment(CE->getSubExpr(), BaseInfo,
> + TBAAInfo);
>auto Derived = CE->getSubExpr()->getType()->
> getPointeeCXXRecordDecl();
>return GetAddressOfBaseClass(Addr, Derived,
> CE->path_begin(), CE->path_end(),
> @@ -994,6 +1006,7 @@ Address CodeGenFunction::EmitPointerWith
> if (UO->getOpcode() == UO_AddrOf) {
>LValue LV = EmitLValu
Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target
I committed the patch that allows -m-version-min to specify the OS
version when -target doesn't specify in r321559. Let me know if it works
for you!
Thanks,
Alex
On 21 December 2017 at 12:34, James Y Knight wrote:
> I totally agree with moving towards eliminating the -m-version-min
> flags, it's much better to put it in the target, and will clean up a lot of
> cruft in the driver, eventually.
>
> Now -- we (or anyone else who runs into this) can simply start specifying
> the version in both locations ("-target x86_64-apple-ios10
> -mios-simulator-version-min=10"), so as to work with both new and old
> clang, and be closer to the ultimate goal of having only -target. That's an
> overall nicer workaround to suggest than switching to -darwin. But, yea,
> there's no need for *temporary* patch to fix things just for us.
>
> However, I do not understand why you're against committing the patch you
> mention as option #2 -- that seems like it'd be best for all users, by
> preserving compatibility with existing command-lines. So, I'd still like
> that change to be committed, permanently, not temporarily. I'm sure we
> can't be the only ones running clang like "-target x86_64-apple-ios
> -mios-simulator-version-min=10", and it seems unfortunate and unnecessary
> to break that, even if it can be worked around.
>
> In the future, I'd hope the -m-version-min arguments can be deprecated
> more and more -- warning whenever you use them to modify the platform or
> version at all, rather just on specification conflict; then, warn anytime
> you use them at all; then, remove them. But in the meantime, it seems
> strictly better to preserve compatibility, don't you think?
>
>
>
> On Dec 21, 2017 2:11 PM, "Alex L" wrote:
>
> Thanks for raising your concerns.
>
> We decided to avoid -m-version-min flag in favor of -target to
> simplify the driver logic and to encourage the adoption of -target. Now
> after r321145 we only warn about -m-version-min flag when the OS
> version specified in it is different to the OS version specified in target,
> or when target has no OS version.
>
> There are two possible solutions here:
> 1) You can still use -target with -mios-simulator-version-min as before
> but you'd have to use '-target=x86_64-apple-darwin' to ensure that the iOS
> version specified by '-mios-simulator-version-min' is used.
> 2) I also do have a patch that implements the logic that you propose (use
> the OS version in -m-version-min flag if target has none). If you
> believe that the first solution is not suitable for your code then I can
> commit it. At the same time I believe that we would rather not use this
> patch, but if it's urgent for your projects then maybe I can land it now
> and then we can establish some sort of timeline for when it can be reverted?
>
> Thanks,
> Alex
>
>
> On 21 December 2017 at 08:00, James Y Knight wrote:
>
>> I think if a version number isn't explicitly specified in the -target
>> value, the value from -m-version-min ought to still be used, as
>> it was before.
>>
>> Currently, clang will ignore the -m-version-min version number
>> if the target has a particular OS specified, even if it has no version
>> number as part of it.
>>
>> (We should be able to workaround this change backwards-compatibly by
>> specifying in both the -target argument and in the -m-version-min
>> arguments, but I do think the behavior should be fixed.)
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r313729 - Implement C++ [basic.link]p8.
Hi Richard,
This commit has caused a second regression in Clang which triggers a new
invalid -Wunused-function warning. I filed
https://bugs.llvm.org/show_bug.cgi?id=36584 which contains the minimized
test case for this issue. Do you mind taking a look at it?
Thanks,
Alex
On 19 December 2017 at 11:14, Alex L wrote:
> Hi Richard,
>
> This commit has caused a new regression in Clang which causes an assertion
> failure for extern "C" function definitions whose return type is a pointer
> to a record. I filed https://bugs.llvm.org/show_bug.cgi?id=35697 which
> contains the minimized test case for this issue. Do you mind taking a look
> at it?
>
> Cheers,
> Alex
>
> On 20 September 2017 at 00:22, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Wed Sep 20 00:22:00 2017
>> New Revision: 313729
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=313729&view=rev
>> Log:
>> Implement C++ [basic.link]p8.
>>
>> If a function or variable has a type with no linkage (and is not extern
>> "C"),
>> any use of it requires a definition within the same translation unit; the
>> idea
>> is that it is not possible to define the entity elsewhere, so any such
>> use is
>> necessarily an error.
>>
>> There is an exception, though: some types formally have no linkage but
>> nonetheless can be referenced from other translation units (for example,
>> this
>> happens to anonymous structures defined within inline functions). For
>> entities
>> with those types, we suppress the diagnostic except under -pedantic.
>>
>> Added:
>> cfe/trunk/test/CXX/basic/basic.link/p8.cpp
>> Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/include/clang/Sema/SemaInternal.h
>> cfe/trunk/lib/AST/Decl.cpp
>> cfe/trunk/lib/Sema/Sema.cpp
>> cfe/trunk/lib/Sema/SemaDecl.cpp
>> cfe/trunk/lib/Sema/SemaExpr.cpp
>> cfe/trunk/test/Analysis/malloc.mm
>> cfe/trunk/test/Analysis/reference.cpp
>> cfe/trunk/test/CodeGenCXX/debug-info-method.cpp
>> cfe/trunk/test/CodeGenCXX/mangle-ms-cxx11.cpp
>> cfe/trunk/test/CodeGenCXX/mangle.cpp
>> cfe/trunk/test/PCH/cxx11-lambdas.mm
>> cfe/trunk/test/SemaCXX/warn-unreachable.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/DiagnosticSemaKinds.td?rev=313729&r1=313728&r2=313729&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Sep 20
>> 00:22:00 2017
>> @@ -4707,6 +4707,14 @@ def note_deleted_assign_field : Note<
>> def warn_undefined_internal : Warning<
>>"%select{function|variable}0 %q1 has internal linkage but is not
>> defined">,
>>InGroup>;
>> +def err_undefined_internal_type : Error<
>> + "%select{function|variable}0 %q1 is used but not defined in this "
>> + "translation unit, and cannot be defined in any other translation unit
>> "
>> + "because its type does not have linkage">;
>> +def ext_undefined_internal_type : Extension<
>> + "ISO C++ requires a definition in this translation unit for "
>> + "%select{function|variable}0 %q1 because its type does not have
>> linkage">,
>> + InGroup>;
>> def warn_undefined_inline : Warning<"inline function %q0 is not
>> defined">,
>>InGroup>;
>> def err_undefined_inline_var : Error<"inline variable %q0 is not
>> defined">;
>>
>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Sema/Sema.h?rev=313729&r1=313728&r2=313729&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>> +++ cfe/trunk/include/clang/Sema/Sema.h Wed Sep 20 00:22:00 2017
>> @@ -1086,6 +1086,11 @@ public:
>>/// definition in this translation unit.
>>llvm::MapVector UndefinedButUsed;
>>
>> + /// Determine if VD, which must be a variable or function, is an
>> external
>> + /// symbol that nonetheless can't be referenced from outside this
>> translation
>> + /// unit because its type has no linkage and it's not extern "C".
>> + bool isExternalWithNoLinkageType(ValueDecl *VD);
>> +
>>/// Obtain a sorted list of functions that are undefined but ODR-used.
>>void getUndefinedButUsed(
>>SmallVectorImpl >
>> &Undefined);
>>
>> Modified: cfe/trunk/include/clang/Sema/SemaInternal.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Sema/SemaInternal.h?rev=313729&r1=313728&r2=313729&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Sema/SemaInternal.h (original)
>> +++ cfe/trunk/include/clang/Sema/SemaInternal.h Wed Sep 20 00:22:00 2017
>> @@ -73,7 +73,8 @@ inline void MarkVa
Re: r350768 - [ObjC] Allow the use of implemented unavailable methods from within
Thanks, we might have similar cases in our code base as well. We'll see if
we can fix that too.
On Fri, 11 Jan 2019 at 06:13, Nico Weber wrote:
> Here's some user feedback on this new feature.
>
> It looks like the warning is only suppressed if `init` has a definition in
> the @interface block. In the 4 cases where we saw this warning fire after
> r349841, it still fires after this change because in all 4 cases a class
> marked init as unavailable in the @interface but didn't add a definition of
> it in the classes @implementation (instead relying on calling the
> superclass's (NSObject) init).
>
> It's pretty easy to just add
>
> - (instancetype)init { return [super init]; }
>
> to these 4 classes, but:
> a) it doesn't Just Work
> b) the diagnostic doesn't make it clear that adding a definition of init
> will suppress the warning.
>
> Up to you to decide what (if anything) to do with this feedback :-)
>
> (https://bugs.chromium.org/p/chromium/issues/detail?id=917351#c17 has a
> full reduced code snippet.)
>
> On Wed, Jan 9, 2019 at 5:35 PM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Wed Jan 9 14:31:37 2019
>> New Revision: 350768
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=350768&view=rev
>> Log:
>> [ObjC] Allow the use of implemented unavailable methods from within
>> the @implementation context
>>
>> In Objective-C, it's common for some frameworks to mark some methods like
>> init
>> as unavailable in the @interface to prohibit their usage. However, these
>> frameworks then often implemented said method and refer to it in another
>> method
>> that acts as a factory for that object. The recent change to how messages
>> to
>> self are type checked in clang (r349841) introduced a regression which
>> started
>> to prohibit this pattern with an X is unavailable error. This commit
>> addresses
>> the aforementioned regression.
>>
>> rdar://47134898
>>
>> Differential Revision: https://reviews.llvm.org/D56469
>>
>> Added:
>> cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m
>> Modified:
>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>>
>> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=350768&r1=350767&r2=350768&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Jan 9 14:31:37 2019
>> @@ -7269,9 +7269,10 @@ ShouldDiagnoseAvailabilityOfDecl(Sema &S
>> /// whether we should emit a diagnostic for \c K and \c DeclVersion in
>> /// the context of \c Ctx. For example, we should emit an unavailable
>> diagnostic
>> /// in a deprecated context, but not the other way around.
>> -static bool ShouldDiagnoseAvailabilityInContext(Sema &S,
>> AvailabilityResult K,
>> -VersionTuple DeclVersion,
>> -Decl *Ctx) {
>> +static bool
>> +ShouldDiagnoseAvailabilityInContext(Sema &S, AvailabilityResult K,
>> +VersionTuple DeclVersion, Decl *Ctx,
>> +const NamedDecl *OffendingDecl) {
>>assert(K != AR_Available && "Expected an unavailable declaration
>> here!");
>>
>>// Checks if we should emit the availability diagnostic in the context
>> of C.
>> @@ -7280,9 +7281,22 @@ static bool ShouldDiagnoseAvailabilityIn
>>if (const AvailabilityAttr *AA = getAttrForPlatform(S.Context, C))
>> if (AA->getIntroduced() >= DeclVersion)
>>return true;
>> -} else if (K == AR_Deprecated)
>> +} else if (K == AR_Deprecated) {
>>if (C->isDeprecated())
>> return true;
>> +} else if (K == AR_Unavailable) {
>> + // It is perfectly fine to refer to an 'unavailable' Objective-C
>> method
>> + // when it's actually defined and is referenced from within the
>> + // @implementation itself. In this context, we interpret
>> unavailable as a
>> + // form of access control.
>> + if (const auto *MD = dyn_cast(OffendingDecl)) {
>> +if (const auto *Impl = dyn_cast(C)) {
>> + if (MD->getClassInterface() == Impl->getClassInterface() &&
>> + MD->isDefined())
>> +return true;
>> +}
>> + }
>> +}
>>
>> if (C->isUnavailable())
>>return true;
>> @@ -7471,7 +7485,8 @@ static void DoEmitAvailabilityWarning(Se
>>if (const AvailabilityAttr *AA = getAttrForPlatform(S.Context,
>> OffendingDecl))
>> DeclVersion = AA->getIntroduced();
>>
>> - if (!ShouldDiagnoseAvailabilityInContext(S, K, DeclVersion, Ctx))
>> + if (!ShouldDiagnoseAvailabilityInContext(S, K, DeclVersion, Ctx,
>> + OffendingDecl))
>> return;
>>
>>SourceLocation Loc = Locs.front();
>> @@ -7955,7 +7970,8 @@ void DiagnoseUnguardedAvailabil
Re: r350768 - [ObjC] Allow the use of implemented unavailable methods from within
Hi,
We are planning to fix this issue by not checking if the method is defined.
I will post a patch this week.
Cheers,
Alex
On Fri, 11 Jan 2019 at 10:26, Alex L wrote:
> Thanks, we might have similar cases in our code base as well. We'll see if
> we can fix that too.
>
> On Fri, 11 Jan 2019 at 06:13, Nico Weber wrote:
>
>> Here's some user feedback on this new feature.
>>
>> It looks like the warning is only suppressed if `init` has a definition
>> in the @interface block. In the 4 cases where we saw this warning fire
>> after r349841, it still fires after this change because in all 4 cases a
>> class marked init as unavailable in the @interface but didn't add a
>> definition of it in the classes @implementation (instead relying on calling
>> the superclass's (NSObject) init).
>>
>> It's pretty easy to just add
>>
>> - (instancetype)init { return [super init]; }
>>
>> to these 4 classes, but:
>> a) it doesn't Just Work
>> b) the diagnostic doesn't make it clear that adding a definition of init
>> will suppress the warning.
>>
>> Up to you to decide what (if anything) to do with this feedback :-)
>>
>> (https://bugs.chromium.org/p/chromium/issues/detail?id=917351#c17 has a
>> full reduced code snippet.)
>>
>> On Wed, Jan 9, 2019 at 5:35 PM Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Wed Jan 9 14:31:37 2019
>>> New Revision: 350768
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=350768&view=rev
>>> Log:
>>> [ObjC] Allow the use of implemented unavailable methods from within
>>> the @implementation context
>>>
>>> In Objective-C, it's common for some frameworks to mark some methods
>>> like init
>>> as unavailable in the @interface to prohibit their usage. However, these
>>> frameworks then often implemented said method and refer to it in another
>>> method
>>> that acts as a factory for that object. The recent change to how
>>> messages to
>>> self are type checked in clang (r349841) introduced a regression which
>>> started
>>> to prohibit this pattern with an X is unavailable error. This commit
>>> addresses
>>> the aforementioned regression.
>>>
>>> rdar://47134898
>>>
>>> Differential Revision: https://reviews.llvm.org/D56469
>>>
>>> Added:
>>> cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m
>>> Modified:
>>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>>>
>>> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=350768&r1=350767&r2=350768&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
>>> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Wed Jan 9 14:31:37 2019
>>> @@ -7269,9 +7269,10 @@ ShouldDiagnoseAvailabilityOfDecl(Sema &S
>>> /// whether we should emit a diagnostic for \c K and \c DeclVersion in
>>> /// the context of \c Ctx. For example, we should emit an unavailable
>>> diagnostic
>>> /// in a deprecated context, but not the other way around.
>>> -static bool ShouldDiagnoseAvailabilityInContext(Sema &S,
>>> AvailabilityResult K,
>>> -VersionTuple
>>> DeclVersion,
>>> -Decl *Ctx) {
>>> +static bool
>>> +ShouldDiagnoseAvailabilityInContext(Sema &S, AvailabilityResult K,
>>> +VersionTuple DeclVersion, Decl *Ctx,
>>> +const NamedDecl *OffendingDecl) {
>>>assert(K != AR_Available && "Expected an unavailable declaration
>>> here!");
>>>
>>>// Checks if we should emit the availability diagnostic in the
>>> context of C.
>>> @@ -7280,9 +7281,22 @@ static bool ShouldDiagnoseAvailabilityIn
>>>if (const AvailabilityAttr *AA = getAttrForPlatform(S.Context, C))
>>> if (AA->getIntroduced() >= DeclVersion)
>>>return true;
>>> -} else if (K == AR_Deprecated)
>>> +} else if (K == AR_Deprecated) {
>>>if (C->isDeprecated())
>>> return true;
>>> +} else if (K == AR_Unavailable) {
>>> + // It is perfectly fine to refer to an 'unavailable' Objective-C
>>> method
>>> + // when it's actually defined and is referenced from within the
>>> + // @implementation itself. In this context, we interpret
>>> unavailable as a
>>> + // form of access control.
>>> + if (const auto *MD = dyn_cast(OffendingDecl)) {
>>> +if (const auto *Impl = dyn_cast(C)) {
>>> + if (MD->getClassInterface() == Impl->getClassInterface() &&
>>> + MD->isDefined())
>>> +return true;
>>> +}
>>> + }
>>> +}
>>>
>>> if (C->isUnavailable())
>>>return true;
>>> @@ -7471,7 +7485,8 @@ static void DoEmitAvailabilityWarning(Se
>>>if (const AvailabilityAttr *AA = getAttrForPlatform(S.Context,
>>> OffendingDecl))
>>> DeclVersion = AA->getIntroduced();
>>>
>>> - if (!ShouldDiagno
Re: r351459 - [ObjC] Follow-up r350768 and allow the use of unavailable methods that are
Hi Hans,
Could you please cherry-pick this change into the release branch?
Cheers,
Alex
On Thu, 17 Jan 2019 at 10:16, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Thu Jan 17 10:12:45 2019
> New Revision: 351459
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351459&view=rev
> Log:
> [ObjC] Follow-up r350768 and allow the use of unavailable methods that are
> declared in a parent class from within the @implementation context
>
> This commit extends r350768 and allows the use of methods marked as
> unavailable
> that are declared in a parent class/category from within the
> @implementation of
> the class where the method is marked as unavailable.
> This allows users to call init that's marked as unavailable even if they
> don't
> define it.
>
> rdar://47134898
>
> Differential Revision: https://reviews.llvm.org/D56816
>
> Modified:
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m
> cfe/trunk/test/SemaObjC/infer-availability-from-init.m
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=351459&r1=351458&r2=351459&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu Jan 17 10:12:45 2019
> @@ -7365,13 +7365,11 @@ ShouldDiagnoseAvailabilityInContext(Sema
> return true;
> } else if (K == AR_Unavailable) {
>// It is perfectly fine to refer to an 'unavailable' Objective-C
> method
> - // when it's actually defined and is referenced from within the
> - // @implementation itself. In this context, we interpret
> unavailable as a
> - // form of access control.
> + // when it is referenced from within the @implementation itself. In
> this
> + // context, we interpret unavailable as a form of access control.
>if (const auto *MD = dyn_cast(OffendingDecl)) {
> if (const auto *Impl = dyn_cast(C)) {
> - if (MD->getClassInterface() == Impl->getClassInterface() &&
> - MD->isDefined())
> + if (MD->getClassInterface() == Impl->getClassInterface())
> return true;
> }
>}
>
> Modified: cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m?rev=351459&r1=351458&r2=351459&view=diff
>
> ==
> --- cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m (original)
> +++ cfe/trunk/test/SemaObjC/call-unavailable-init-in-self.m Thu Jan 17
> 10:12:45 2019
> @@ -5,13 +5,24 @@
> + (instancetype)new;
> + (instancetype)alloc;
>
> +- (void)declaredInSuper;
> +
> +@end
> +
> +@interface NSObject (Category)
> +
> +- (void)declaredInSuperCategory;
> +
> @end
>
> @interface Sub: NSObject
>
> - (instancetype)init __attribute__((unavailable)); // expected-note 4
> {{'init' has been explicitly marked unavailable here}}
>
> -- (void)notImplemented __attribute__((unavailable)); // expected-note
> {{'notImplemented' has been explicitly marked unavailable here}}
> +- (void)notImplemented __attribute__((unavailable));
> +
> +- (void)declaredInSuper __attribute__((unavailable));
> +- (void)declaredInSuperCategory __attribute__((unavailable));
>
> @end
>
> @@ -34,7 +45,14 @@
> }
>
> - (void)reportUseOfUnimplemented {
> - [self notImplemented]; // expected-error {{'notImplemented' is
> unavailable}}
> + [self notImplemented];
> +}
> +
> +- (void)allowSuperCallUsingSelf {
> + [self declaredInSuper];
> + [[Sub alloc] declaredInSuper];
> + [self declaredInSuperCategory];
> + [[Sub alloc] declaredInSuperCategory];
> }
>
> @end
>
> Modified: cfe/trunk/test/SemaObjC/infer-availability-from-init.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/infer-availability-from-init.m?rev=351459&r1=351458&r2=351459&view=diff
>
> ==
> --- cfe/trunk/test/SemaObjC/infer-availability-from-init.m (original)
> +++ cfe/trunk/test/SemaObjC/infer-availability-from-init.m Thu Jan 17
> 10:12:45 2019
> @@ -47,12 +47,12 @@ void usenotmyobject() {
> }
>
> @interface FromSelf : NSObject
> --(instancetype)init __attribute__((unavailable)); // expected-note
> {{'init' has been explicitly marked unavailable here}}
> +-(instancetype)init __attribute__((unavailable));
> +(FromSelf*)another_one;
> @end
>
> @implementation FromSelf
> +(FromSelf*)another_one {
> - [self new]; // expected-error{{'new' is unavailable}}
> + [self new];
> }
> @end
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
__
Re: [cfe-dev] r347339 - [clang][Parse] Diagnose useless null statements / empty init-statements
We have about 100k unique occurrences of this warning across a slice of our
software stack. It's simply not feasible to us to adopt it, so we would
prefer for it to be reverted to avoid downstream divergence in Apple's
clang. Granted, these occur in projects that use -Weverything but those
projects are typically understanding of warnings that they can turn off
when they see that they provide useful value in terms of warnings about
unintended behavior that's sometimes caught. This warning doesn't seem to
catch unintended bugs and it would be a heroic battle to adopt it for us in
a way where projects are somewhat satisfied. It seems to be a better fit
for a clang-tidy check that could suggest automatic fixits and that the
users could run on their codebase to "modernize" if they want to.
Cheers,
Alex
On Wed, 5 Dec 2018 at 10:43, Richard Smith via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On Wed, 5 Dec 2018, 10:01 George Karpenkov via cfe-commits <
> cfe-commits@lists.llvm.org wrote:
>
>> These are the cases I get:
>>
>> #define unexpected(a) { kprintf("unexpected %s:%d\n", __FILE__,
>> __LINE__); a; }
>>
>> and
>>
>> #if 0
>> #define DEBG(fmt, args...) { IOLog(fmt, ## args); kprintf(fmt, ##
>> args); }
>> #else
>> #define DEBG(fmt, args...) {}
>> #endif
>>
>> Now calls
>>
>> `DEBG(‘x’);` and `unexpected(‘msg’);`
>>
>> cause the warning to be fired.
>> Of course, semicolon could be omitted, but the fact that the macro has
>> braces is sort of an implementation detail.
>>
>> Greg Parker has pointed out it’s possible to rewrite the macros using the
>> “do { … } while (0)”,
>> but that is a lot of macros to change, and the resulting code would be
>> arguably less readable.
>>
>
> That suggestion is the (or at least an) idiomatic way to write a
> "statement-like" macro that expects a semicolon. The approach taken by the
> above macros is often considered to be a macro antipattern (try putting it
> in an unbraced if and adding an else clause, for example).
>
>> On Dec 5, 2018, at 5:10 AM, Aaron Ballman wrote:
>>
>> On Wed, Dec 5, 2018 at 1:40 AM Roman Lebedev
>> wrote:
>>
>>
>> It is a problem in practice for us since we have projects which enable
>> all available warnings and also enable “-Werror”.
>>
>> Hm, they have asked for -Weverything and they got it. Seems to be
>> working as intended.
>> When in previous discussions elsewhere i have talked about
>> -Weverything, i was always
>> been told that it isn't supposed to be used like that (admittedly, i
>> *do* use it like that :)).
>>
>> Could you explain how is this different from any other warning that is
>> considered pointless by the project?
>> Why not simply disable it?
>>
>>
>> You are right, it could be disabled. It’s just for this warning the noise
>> vs. usefulness ratio seemed pretty low.
>>
>>
>> Would you be okay with the warning if it was only diagnosed when the
>> source location of the semi-colon is not immediately preceded by a
>> macro expansion location? e.g.,
>>
>> EMPTY_EXPANSION(12); // Not diagnosed
>> EMPTY_EXPANSION; // Not diagnosed
>> ; // Diagnosed
>>
>> This could work provided that all empty space preceding the semicolon is
>> ignored (as the macro could be separated by space(s) or newline(s).
>> I’m not sure the complexity would be worth it, as I haven’t seen bugs
>> arising from extra semicolons and empty statements,
>> but it would take care of my use case.
>>
>>
>> Or rather when the *previous* semicolon is coming from a macro.
>>
>> I don't like this. clang is already wa-a-ay too forgiving about
>> macros, it almost ignores almost every warning in macros.
>> It was an *intentional* decision to still warn on useless ';' after
>> non-empty macros.
>>
>>
>> I think I'm confused now. This is a test case:
>>
>> NULLMACRO(v7); // OK. This could be either GOODMACRO() or
>> BETTERMACRO() situation, so we can't know we can drop it.
>>
>> So empty macro expansions should be ignored as I expected... so what
>> is being diagnosed? George, can you provide a more clear example that
>> demonstrates the issue?
>>
>> To be clear, I do *not* think this is a situation we should spend
>> effort supporting (assuming "all available warnings" really means
>> -Weverything and not something else):
>>
>> It is a problem in practice for us since we have projects which enable
>> all available warnings and also enable “-Werror”.
>>
>>
>> However, if we are diagnosing *empty* macro expansions followed by a
>> semi-colon, I think that would be unacceptably chatty and is worth
>> fixing on its own merits.
>>
>> ~Aaron
>>
>>
>> ~Aaron
>>
>> Regards,
>> George
>>
>> Roman.
>>
>> On Nov 20, 2018, at 10:59 AM, Roman Lebedev via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> Author: lebedevri
>> Date: Tue Nov 20 10:59:05 2018
>> New Revision: 347339
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=347339&view=rev
>> Log:
>> [clang][Parse] Diagnose useless null statements / empty init-statements
>>
>> Summary:
>> clang has `-Wextra-semi`
Re: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++
On Fri, 7 Sep 2018 at 12:02, Alex L wrote:
>
> On Fri, 7 Sep 2018 at 05:41, Nico Weber wrote:
>
>> On Wed, Sep 5, 2018 at 9:25 PM Alex L wrote:
>>
>>> Sorry for the late response,
>>>
>>> On Sat, 18 Aug 2018 at 20:10, Nico Weber wrote:
>>>
Also, the diag text should probably say "pass '-stdlib=libc++' " not
"pass '-std=libc++' "?
>>>
>>> Good catch, thanks! I'll commit a fixup for it.
>>>
>>
> Fixed in r341697.
>
>
>>
>>>
On Sat, Aug 18, 2018 at 11:06 PM Nico Weber
wrote:
> Should this maybe not be emitted when compiling e.g. .ii files
> (preprocessed output)? I just got this when I built a standalone .ii file
> with some bug repro after I deleted all -I and -isysroot flags and
> whatnot,
> since they aren't needed for preprocessed files.
>
>>> That would make sense, but I'm not sure how easy it is to determine if a
>>> file is already preprocessed. I'll try to create a patch for this fixup.
>>>
>>
>> Probably you'd want something like
>> http://llvm-cs.pcc.me.uk/tools/clang/lib/Driver/Types.cpp#123 that
>> returns true for all (or most) of the TY_PP_ types, and then just rely
>> on lookupTypeForExtension.
>>
>
> Good idea, I'll try it out.
>
Apologies for the delay, I fixed the issue with preprocessed inputs in
r348540.
Cheers,
Alex
>
>
>>
>>
>>>
>>>
>>>
> On Tue, Jun 19, 2018 at 6:52 PM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Tue Jun 19 15:47:53 2018
>> New Revision: 335081
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=335081&view=rev
>> Log:
>> Recommit r335063: [Darwin] Add a warning for missing include path for
>> libstdc++
>>
>> The recommit ensures that the tests that failed on bots don't trigger
>> the warning.
>>
>> Xcode 10 removes support for libstdc++, but the users just get a
>> confusing
>> include not file warning when including an STL header (when building
>> for iOS6
>> which uses libstdc++ by default for example).
>> This patch adds a new warning that lets the user know that the
>> libstdc++ include
>> path was not found to ensure that the user is more aware of why the
>> error occurs.
>>
>> rdar://40830462
>>
>> Differential Revision: https://reviews.llvm.org/D48297
>>
>> Added:
>> cfe/trunk/test/Frontend/warning-stdlibcxx-darwin.cpp
>> Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>> cfe/trunk/include/clang/Lex/HeaderSearch.h
>> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>> cfe/trunk/test/CodeGenCXX/apple-kext-guard-variable.cpp
>> cfe/trunk/test/Misc/backend-stack-frame-diagnostics.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=335081&r1=335080&r2=335081&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
>> (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Jun
>> 19 15:47:53 2018
>> @@ -236,4 +236,9 @@ def err_invalid_vfs_overlay : Error<
>>
>> def warn_option_invalid_ocl_version : Warning<
>>"OpenCL version %0 does not support the option '%1'">,
>> InGroup;
>> +
>> +def warn_stdlibcxx_not_found : Warning<
>> + "include path for stdlibc++ headers not found; pass '-std=libc++'
>> on the "
>> + "command line to use the libc++ standard library instead">,
>> + InGroup>;
>> }
>>
>> Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=335081&r1=335080&r2=335081&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
>> +++ cfe/trunk/include/clang/Lex/HeaderSearch.h Tue Jun 19 15:47:53
>> 2018
>> @@ -272,6 +272,8 @@ public:
>>
>>FileManager &getFileMgr() const { return FileMgr; }
>>
>> + DiagnosticsEngine &getDiags() const { return Diags; }
>> +
>>/// Interface for setting the file search paths.
>>void SetSearchPaths(const std::vector &dirs,
>>unsigned angledDirIdx, unsigned systemDirIdx,
>>
>> Modified: cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitHeaderSearch.cpp?rev=335081&r1=335080&r2=335081&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Frontend/InitHeaderSearch.cpp (original)
>> +++ cfe/trunk/lib/Frontend/InitHeaderSearc
Re: r357713 - Verify that Android targets generate DWARF 4 by default.
Hi Stephen, It looks like your change has caused the 'debug-options.c' test to start failing on Darwin. It looks like we emit "-dwarf-version=4" by default, and not 2. Could you please take a look. Here's a link to a latest build on the public LLVM CI that contains the failure: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/59772/console Here's the failure itself: Command Output (stderr): -- /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c:280:14: error: G_DWARF2: expected string not found in input // G_DWARF2: "-dwarf-version=2" ^ :5:515: note: scanning from here "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/bin/clang-9" "-cc1" "-triple" "x86_64-apple-macosx10.13.0" "-Wdeprecated-objc-isa-usage" "-Werror=deprecated-objc-isa-usage" "-emit-obj" "-mrelax-all" "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" "-munwind-tables" "-faligned-alloc-unavailable" "-target-cpu" "penryn" "-dwarf-column-info" "-debug-info-kind=standalone" "-dwarf-version=4" "-debugger-tuning=lldb" "-ggnu-pubnames" "-target-linker-version" "351.8" "-coverage-notes-file" "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver/debug-options.gcno" "-resource-dir" "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/9.0.0" "-fdebug-compilation-dir" "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver" "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "1" "-fblocks" "-fencode-extended-block-signature" "-fregister-global-dtors-with-atexit" "-fobjc-runtime=macosx-10.13.0" "-fmax-type-align=16" "-fdiagnostics-show-option" "-o" "debug-options.o" "-x" "c" "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c" ^ Adrian, I've looped you in since you reviewed the commit it looks like. Do you know if that's expected behavior on Darwin? Cheers, Alex On Thu, 4 Apr 2019 at 11:16, Stephen Hines via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: srhines > Date: Thu Apr 4 11:17:46 2019 > New Revision: 357713 > > URL: http://llvm.org/viewvc/llvm-project?rev=357713&view=rev > Log: > Verify that Android targets generate DWARF 4 by default. > > Summary: > In the future, Android releases will support DWARF 5, but we need to > ensure that older targets only have DWARF 4 generated for them. This > patch inserts that verification for all Android releases now. The patch > also fixes 2 minor mistakes (a mistakenly moved RUN line, and the > missing G_DWARF2 check label). > > Reviewers: aprantl > > Reviewed By: aprantl > > Subscribers: chh, pirama, cfe-commits > > Tags: #clang > > Differential Revision: https://reviews.llvm.org/D60238 > > Modified: > cfe/trunk/test/Driver/debug-options.c > > Modified: cfe/trunk/test/Driver/debug-options.c > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=357713&r1=357712&r2=357713&view=diff > > == > --- cfe/trunk/test/Driver/debug-options.c (original) > +++ cfe/trunk/test/Driver/debug-options.c Thu Apr 4 11:17:46 2019 > @@ -17,9 +17,14 @@ > // RUN: %clang -### -c -glldb %s -target x86_64-linux-gnu 2>&1 \ > // RUN: | FileCheck -check-prefix=G -check-prefix=G_LLDB %s > // RUN: %clang -### -c -gsce %s -target x86_64-linux-gnu 2>&1 \ > +// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s > + > +// Android. > +// Android should always generate DWARF4. > +// RUN: %clang -### -c -g %s -target arm-linux-androideabi 2>&1 \ > +// RUN: | FileCheck -check-prefix=G -check-prefix=G_DWARF4 %s > > // Darwin. > -// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s > // RUN: %clang -### -c -g %s -target x86_64-apple-darwin 2>&1 \ > // RUN: | FileCheck -check-prefix=G_STANDALONE \ > // RUN: -check-prefix=G_DWARF2 \ > @@ -272,6 +277,7 @@ > // > // G_STANDALONE: "-cc1" > // G_STANDALONE: "-debug-info-kind=standalone" > +// G_DWARF2: "-dwarf-version=2" > // G_DWARF4: "-dwarf-version=4" > // > // G_GDB: "-debugger-tuning=gdb" > > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r357713 - Verify that Android targets generate DWARF 4 by default.
Thanks, for the explanation, it makes sense. It looks like an explicit `darwin14` in one of the non-versioned darwin triples fixes the issue. I will commit the fix right away. Cheers, Alex On Thu, 4 Apr 2019 at 18:24, Adrian Prantl wrote: > IIRC, the dwarf version on Darwin depends on the deployment target and is > 2 for earlier versions of macOS and and 4 for newer ones (I need to dig > through the driver code to determine the exact version). > > I can take a look at this tomorrow morning. > > -- adrian > > On Apr 4, 2019, at 6:21 PM, Alex L wrote: > > Hi Stephen, > > It looks like your change has caused the 'debug-options.c' test to start > failing on Darwin. It looks like we emit "-dwarf-version=4" by default, and > not 2. Could you please take a look. > > Here's a link to a latest build on the public LLVM CI that contains the > failure: > > http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/59772/console > > Here's the failure itself: > Command Output (stderr): -- > /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c:280:14: > error: G_DWARF2: expected string not found in input // G_DWARF2: > "-dwarf-version=2" ^ :5:515: note: scanning from here > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/bin/clang-9" > "-cc1" "-triple" "x86_64-apple-macosx10.13.0" "-Wdeprecated-objc-isa-usage" > "-Werror=deprecated-objc-isa-usage" "-emit-obj" "-mrelax-all" > "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model" > "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" > "-masm-verbose" "-munwind-tables" "-faligned-alloc-unavailable" > "-target-cpu" "penryn" "-dwarf-column-info" "-debug-info-kind=standalone" > "-dwarf-version=4" "-debugger-tuning=lldb" "-ggnu-pubnames" > "-target-linker-version" "351.8" "-coverage-notes-file" > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver/debug-options.gcno" > "-resource-dir" > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/9.0.0" > "-fdebug-compilation-dir" > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver" > "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "1" > "-fblocks" "-fencode-extended-block-signature" > "-fregister-global-dtors-with-atexit" "-fobjc-runtime=macosx-10.13.0" > "-fmax-type-align=16" "-fdiagnostics-show-option" "-o" "debug-options.o" > "-x" "c" > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c" > ^ > > > Adrian, I've looped you in since you reviewed the commit it looks like. Do > you know if that's expected behavior on Darwin? > > Cheers, > Alex > > On Thu, 4 Apr 2019 at 11:16, Stephen Hines via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: srhines >> Date: Thu Apr 4 11:17:46 2019 >> New Revision: 357713 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=357713&view=rev >> Log: >> Verify that Android targets generate DWARF 4 by default. >> >> Summary: >> In the future, Android releases will support DWARF 5, but we need to >> ensure that older targets only have DWARF 4 generated for them. This >> patch inserts that verification for all Android releases now. The patch >> also fixes 2 minor mistakes (a mistakenly moved RUN line, and the >> missing G_DWARF2 check label). >> >> Reviewers: aprantl >> >> Reviewed By: aprantl >> >> Subscribers: chh, pirama, cfe-commits >> >> Tags: #clang >> >> Differential Revision: https://reviews.llvm.org/D60238 >> >> Modified: >> cfe/trunk/test/Driver/debug-options.c >> >> Modified: cfe/trunk/test/Driver/debug-options.c >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=357713&r1=357712&r2=357713&view=diff >> >> == >> --- cfe/trunk/test/Driver/debug-options.c (original) >> +++ cfe/trunk/test/Driver/debug-options.c Thu Apr 4 11:17:46 2019 >> @@ -17,9 +17,14 @@ >> // RUN: %clang -### -c -glldb %s -target x86_64-linux-gnu 2>&1 \ >> // RUN: | FileCheck -check-prefix=G -check-prefix=G_LLDB %s >> // RUN: %clang -### -c -gsce %s -target x86_64-linux-gnu 2>&1 \ >> +// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s >> + >> +// Android. >> +// Android should always generate DWARF4. >> +// RUN: %clang -### -c -g %s -target arm-linux-androideabi 2>&1 \ >> +// RUN: | FileCheck -check-prefix=G -check-prefix=G_DWARF4 %s >> >> // Darwin. >> -// RUN: | FileCheck -check-prefix=G -check-prefix=G_SCE %s >> // RUN: %clang -### -c -g %s -target x86_64-apple-darwin 2>&1 \ >> // RUN: | FileCheck -check-prefix=G_STANDALONE \ >> // RUN: -check-prefix=G_DWARF2 \ >> @@ -272,6 +277,7 @@ >> // >> // G_STANDALONE: "-cc1" >> // G_
Re: r357713 - Verify that Android targets generate DWARF 4 by default.
Thanks! I committed the fix in r357740. The test should start passing now. Cheers, Alex On Thu, 4 Apr 2019 at 18:32, Stephen Hines wrote: > Ah I just saw this. Please feel free to CC me on the fix CL and I will > approve it. I didn't realize that the exact specification was missing > for that. > > Thanks, > Steve > > On Thu, Apr 4, 2019 at 6:31 PM Alex L wrote: > > > > Thanks, for the explanation, it makes sense. It looks like an explicit > `darwin14` in one of the non-versioned darwin triples fixes the issue. I > will commit the fix right away. > > > > Cheers, > > Alex > > > > > > On Thu, 4 Apr 2019 at 18:24, Adrian Prantl wrote: > >> > >> IIRC, the dwarf version on Darwin depends on the deployment target and > is 2 for earlier versions of macOS and and 4 for newer ones (I need to dig > through the driver code to determine the exact version). > >> > >> I can take a look at this tomorrow morning. > >> > >> -- adrian > >> > >> On Apr 4, 2019, at 6:21 PM, Alex L wrote: > >> > >> Hi Stephen, > >> > >> It looks like your change has caused the 'debug-options.c' test to > start failing on Darwin. It looks like we emit "-dwarf-version=4" by > default, and not 2. Could you please take a look. > >> > >> Here's a link to a latest build on the public LLVM CI that contains the > failure: > >> > http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental/59772/console > >> > >> Here's the failure itself: > >> Command Output (stderr): -- > /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c:280:14: > error: G_DWARF2: expected string not found in input // G_DWARF2: > "-dwarf-version=2" ^ :5:515: note: scanning from here > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/bin/clang-9" > "-cc1" "-triple" "x86_64-apple-macosx10.13.0" "-Wdeprecated-objc-isa-usage" > "-Werror=deprecated-objc-isa-usage" "-emit-obj" "-mrelax-all" > "-disable-free" "-main-file-name" "debug-options.c" "-mrelocation-model" > "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" > "-masm-verbose" "-munwind-tables" "-faligned-alloc-unavailable" > "-target-cpu" "penryn" "-dwarf-column-info" "-debug-info-kind=standalone" > "-dwarf-version=4" "-debugger-tuning=lldb" "-ggnu-pubnames" > "-target-linker-version" "351.8" "-coverage-notes-file" > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver/debug-options.gcno" > "-resource-dir" > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/lib/clang/9.0.0" > "-fdebug-compilation-dir" > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/clang-build/tools/clang/test/Driver" > "-ferror-limit" "19" "-fmessage-length" "0" "-stack-protector" "1" > "-fblocks" "-fencode-extended-block-signature" > "-fregister-global-dtors-with-atexit" "-fobjc-runtime=macosx-10.13.0" > "-fmax-type-align=16" "-fdiagnostics-show-option" "-o" "debug-options.o" > "-x" "c" > "/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/Driver/debug-options.c" > ^ > >> > >> > >> Adrian, I've looped you in since you reviewed the commit it looks like. > Do you know if that's expected behavior on Darwin? > >> > >> Cheers, > >> Alex > >> > >> On Thu, 4 Apr 2019 at 11:16, Stephen Hines via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >>> > >>> Author: srhines > >>> Date: Thu Apr 4 11:17:46 2019 > >>> New Revision: 357713 > >>> > >>> URL: http://llvm.org/viewvc/llvm-project?rev=357713&view=rev > >>> Log: > >>> Verify that Android targets generate DWARF 4 by default. > >>> > >>> Summary: > >>> In the future, Android releases will support DWARF 5, but we need to > >>> ensure that older targets only have DWARF 4 generated for them. This > >>> patch inserts that verification for all Android releases now. The patch > >>> also fixes 2 minor mistakes (a mistakenly moved RUN line, and the > >>> missing G_DWARF2 check label). > >>> > >>> Reviewers: aprantl > >>> > >>> Reviewed By: aprantl > >>> > >>> Subscribers: chh, pirama, cfe-commits > >>> > >>> Tags: #clang > >>> > >>> Differential Revision: https://reviews.llvm.org/D60238 > >>> > >>> Modified: > >>> cfe/trunk/test/Driver/debug-options.c > >>> > >>> Modified: cfe/trunk/test/Driver/debug-options.c > >>> URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=357713&r1=357712&r2=357713&view=diff > >>> > == > >>> --- cfe/trunk/test/Driver/debug-options.c (original) > >>> +++ cfe/trunk/test/Driver/debug-options.c Thu Apr 4 11:17:46 2019 > >>> @@ -17,9 +17,14 @@ > >>> // RUN: %clang -### -c -glldb %s -target x86_64-linux-gnu 2>&1 \ > >>> // RUN: | FileCheck -check-prefix=G -check-prefix=G_LLDB > %s > >>> // RUN: %clang -### -c -gsce %s -target x86_64-linux-gnu 2>&1 \ > >>> +// RUN: | FileCheck -check-pre
Re: r312633 - [AST] Traverse CXXOperatorCallExpr in LexicallyOrderedRecursiveASTVisitor
It's a good idea to merge the two. I'll work on moving the ObjC traversal
change when I get the time.
Thanks for the quick patches Johannes!
On 9 September 2017 at 12:03, Johannes Altmanninger
wrote:
> Richard Smith writes:
>
> > I am extremely uncomfortable about the direction this patch series is
> going.
> >
> > We have had two different RecursiveASTVisitors before
> (RecursiveASTVisitor
> > and DataRecursiveASTVisitor), and it was a maintenance nightmare:
> > frequently changes would be made to one of them and missed in the other
> > one, resulting in hard to track down bugs, as well as redundant
> development
> > effort making changes to both.
> >
> > Back when this was simply deriving from RecursiveASTVisitor and not
> > changing much, LexicallyOrderedRecursiveASTVisitor seemed like it
> wouldn't
> > suffer from the same problem, but it's becoming increasingly clear that
> > that simply isn't going to be the case long-term. And worse, there seems
> to
> > be absolutely no purpose in having two different visitors here -- the
> > existing users of RecursiveASTVisitor generally don't care about
> visitation
> > order.
> >
> > Also, we can play the "what if two people did this" game -- adding RAV
> > functionality in derived classes doesn't compose well. (If post-order
> > traversal were a derived class, you couldn't request a lexically-ordered
> > post-order traversal, and so on.)
> >
> > Therefore, I'd like to suggest that you stop making changes to
> > LexicallyOrderedRecursiveASTVisitor and instead start to fold its
> > functionality back into RecursiveASTVisitor, as follows:
> >
> > * in cases where there is no reason for RAV to visit in non-lexical
> order,
> > change it to visit in lexical order
> > * if there are any cases where there *is* a reason for non-lexical
> > visitation, add a bool function to it so the derived class can request
> > lexical / non-lexical order (like the existing shouldTraversePostOrder /
> > shouldVisitImplicitCode / ... functions).
>
> Ok, makes sense.
>
> +Alex so you are aware.
>
> I have created two revisions to move my changes to RecursiveASTVisitor,
> this should not break anything. I left the tests in
> LexicallyOrderedRecursiveASTVisitorTest for now because it saves some
> code duplication, but let's see, if we merge all the changes into
> RecursiveASTVisitor, then the tests will naturally follow.
>
> https://reviews.llvm.org/D37662
> https://reviews.llvm.org/D37663
>
> >
> > On 6 September 2017 at 06:12, Johannes Altmanninger via cfe-commits <
> > cfe-commits@lists.llvm.org> wrote:
> >
> >> Author: krobelus
> >> Date: Wed Sep 6 06:12:11 2017
> >> New Revision: 312633
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=312633&view=rev
> >> Log:
> >> [AST] Traverse CXXOperatorCallExpr in LexicallyOrderedRecursiveASTVi
> sitor
> >>
> >> Summary:
> >> This affects overloaded operators, which are represented by a
> >> CXXOperatorCallExpr whose first child is always a DeclRefExpr referring
> to
> >> the
> >> operator. For infix, postfix and call operators we want the first
> argument
> >> to be traversed before the operator.
> >>
> >> Reviewers: arphaman
> >>
> >> Subscribers: klimek, cfe-commits
> >>
> >> Differential Revision: https://reviews.llvm.org/D37200
> >>
> >> Modified:
> >> cfe/trunk/include/clang/AST/LexicallyOrderedRecursiveASTVisitor.h
> >> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
> >> cfe/trunk/unittests/Tooling/LexicallyOrderedRecursiveASTVi
> >> sitorTest.cpp
> >>
> >> Modified: cfe/trunk/include/clang/AST/LexicallyOrderedRecursiveASTVi
> >> sitor.h
> >> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/
> >> LexicallyOrderedRecursiveASTVisitor.h?rev=312633&r1=312632&
> >> r2=312633&view=diff
> >>
> >> ==
> >> --- cfe/trunk/include/clang/AST/LexicallyOrderedRecursiveASTVisitor.h
> >> (original)
> >> +++ cfe/trunk/include/clang/AST/LexicallyOrderedRecursiveASTVisitor.h
> Wed
> >> Sep 6 06:12:11 2017
> >> @@ -113,6 +113,33 @@ public:
> >>
> >>bool shouldTraverseTemplateArgumentsBeforeDecl() const { return
> true; }
> >>
> >> + Stmt::child_range getStmtChildren(Stmt *S) { return S->children(); }
> >> +
> >> + SmallVector getStmtChildren(CXXOperatorCallExpr *CE) {
> >> +SmallVector Children(CE->children());
> >> +bool Swap;
> >> +// Switch the operator and the first operand for all infix and
> postfix
> >> +// operations.
> >> +switch (CE->getOperator()) {
> >> +case OO_Arrow:
> >> +case OO_Call:
> >> +case OO_Subscript:
> >> + Swap = true;
> >> + break;
> >> +case OO_PlusPlus:
> >> +case OO_MinusMinus:
> >> + // These are postfix unless there is exactly one argument.
> >> + Swap = Children.size() != 2;
> >> + break;
> >> +default:
> >> + Swap = CE->isInfixBinaryOp();
> >> + break;
> >> +}
> >> +if (Swap && Children.size() > 1)
> >> +
Re: r310983 - PR19668, PR23034: Fix handling of move constructors and deleted copy
On 16 August 2017 at 02:49, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Tue Aug 15 18:49:53 2017
> New Revision: 310983
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310983&view=rev
> Log:
> PR19668, PR23034: Fix handling of move constructors and deleted copy
> constructors when deciding whether classes should be passed indirectly.
>
> This fixes ABI differences between Clang and GCC:
>
> * Previously, Clang ignored the move constructor when making this
>determination. It now takes the move constructor into account, per
>https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
>seem recent, but the ABI change was agreed on the Itanium C++ ABI
>list a long time ago).
>
> * Previously, Clang's behavior when the copy constructor was deleted
>was unstable -- depending on whether the lazy declaration of the
>copy constructor had been triggered, you might get different behavior.
>We now eagerly declare the copy constructor whenever its deletedness
>is unclear, and ignore deleted copy/move constructors when looking for
>a trivial such constructor.
>
> This also fixes an ABI difference between Clang and MSVC:
>
> * If the copy constructor would be implicitly deleted (but has not been
>lazily declared yet), for instance because the class has an rvalue
>reference member, we would pass it directly. We now pass such a class
>indirectly, matching MSVC.
>
> Based on a patch by Vassil Vassilev, which was based on a patch by Bernd
> Schmidt, which was based on a patch by Reid Kleckner!
>
> This is a re-commit of r310401, which was reverted in r310464 due to ARM
> failures (which should now be fixed).
>
> Modified:
> cfe/trunk/include/clang/AST/DeclCXX.h
> cfe/trunk/lib/AST/ASTImporter.cpp
> cfe/trunk/lib/AST/DeclCXX.cpp
> cfe/trunk/lib/CodeGen/CGCXXABI.cpp
> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> cfe/trunk/lib/Serialization/ASTWriter.cpp
> cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp
> cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
>
> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/AST/DeclCXX.h?rev=310983&r1=310982&r2=310983&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
> +++ cfe/trunk/include/clang/AST/DeclCXX.h Tue Aug 15 18:49:53 2017
> @@ -374,6 +374,7 @@ class CXXRecordDecl : public RecordDecl
> /// \brief These flags are \c true if a defaulted corresponding
> special
> /// member can't be fully analyzed without performing overload
> resolution.
> /// @{
> +unsigned NeedOverloadResolutionForCopyConstructor : 1;
> unsigned NeedOverloadResolutionForMoveConstructor : 1;
> unsigned NeedOverloadResolutionForMoveAssignment : 1;
> unsigned NeedOverloadResolutionForDestructor : 1;
> @@ -382,6 +383,7 @@ class CXXRecordDecl : public RecordDecl
> /// \brief These flags are \c true if an implicit defaulted
> corresponding
> /// special member would be defined as deleted.
> /// @{
> +unsigned DefaultedCopyConstructorIsDeleted : 1;
> unsigned DefaultedMoveConstructorIsDeleted : 1;
> unsigned DefaultedMoveAssignmentIsDeleted : 1;
> unsigned DefaultedDestructorIsDeleted : 1;
> @@ -414,6 +416,12 @@ class CXXRecordDecl : public RecordDecl
> /// constructor.
> unsigned HasDefaultedDefaultConstructor : 1;
>
> +/// \brief True if this class can be passed in a
> non-address-preserving
> +/// fashion (such as in registers) according to the C++ language
> rules.
> +/// This does not imply anything about how the ABI in use will
> actually
> +/// pass an object of this class.
> +unsigned CanPassInRegisters : 1;
> +
> /// \brief True if a defaulted default constructor for this class
> would
> /// be constexpr.
> unsigned DefaultedDefaultConstructorIsConstexpr : 1;
> @@ -810,18 +818,50 @@ public:
> return data().FirstFriend.isValid();
>}
>
> + /// \brief \c true if a defaulted copy constructor for this class would
> be
> + /// deleted.
> + bool defaultedCopyConstructorIsDeleted() const {
> +assert((!needsOverloadResolutionForCopyConstructor() ||
> +(data().DeclaredSpecialMembers & SMF_CopyConstructor)) &&
> + "this property has not yet been computed by Sema");
> +return data().DefaultedCopyConstructorIsDeleted;
> + }
> +
> + /// \brief \c true if a defaulted move constructor for this class would
> be
> + /// deleted.
> + bool defaultedMoveConstructorIsDeleted() const {
> +assert((!needsOverloadResolutionForMoveConstructor() ||
> +(data().DeclaredSpecialMembers & SMF_MoveConstructor)) &&
> + "
Re: [clang-tools-extra] r313754 - [clangd] Serialize onDiagnosticsReady callbacks for the same file.
This commit causes the formatting.test to fail on macOS with an uncaught
exception:
libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: mutex lock failed: Invalid argument
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/35642/
I'm still looking into it. It doesn't look like the sanitizers are
reporting anything suspicious. Do you by any chance know what went wrong?
If it will turn out to be a macOS only thing it might make sense to XFAIL
formatting.test until the issue is resolved.
Thanks,
Alex
On 20 September 2017 at 13:58, Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ibiryukov
> Date: Wed Sep 20 05:58:55 2017
> New Revision: 313754
>
> URL: http://llvm.org/viewvc/llvm-project?rev=313754&view=rev
> Log:
> [clangd] Serialize onDiagnosticsReady callbacks for the same file.
>
> Summary:
> Calls to onDiagnosticsReady were done concurrently before. This sometimes
> led to older versions of diagnostics being reported to the user after
> the newer versions.
>
> Reviewers: klimek, bkramer, krasimir
>
> Reviewed By: klimek
>
> Subscribers: cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D38032
>
> Modified:
> clang-tools-extra/trunk/clangd/ClangdServer.cpp
> clang-tools-extra/trunk/clangd/ClangdServer.h
> clang-tools-extra/trunk/clangd/DraftStore.h
> clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp
>
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/ClangdServer.cpp?rev=313754&r1=313753&r2=313754&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Wed Sep 20 05:58:55
> 2017
> @@ -315,6 +315,19 @@ std::future ClangdServer::schedule
> auto Diags = DeferredRebuild.get();
> if (!Diags)
>return; // A new reparse was requested before this one completed.
> +
> +// We need to serialize access to resulting diagnostics to avoid
> calling
> +// `onDiagnosticsReady` in the wrong order.
> +std::lock_guard DiagsLock(DiagnosticsMutex);
> +DocVersion &LastReportedDiagsVersion = ReportedDiagnosticVersions[
> FileStr];
> +// FIXME(ibiryukov): get rid of '<' comparison here. In the current
> +// implementation diagnostics will not be reported after version
> counters'
> +// overflow. This should not happen in practice, since DocVersion is a
> +// 64-bit unsigned integer.
> +if (Version < LastReportedDiagsVersion)
> + return;
> +LastReportedDiagsVersion = Version;
> +
> DiagConsumer.onDiagnosticsReady(FileStr,
> make_tagged(std::move(*Diags), Tag));
>};
>
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/ClangdServer.h?rev=313754&r1=313753&r2=313754&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
> +++ clang-tools-extra/trunk/clangd/ClangdServer.h Wed Sep 20 05:58:55 2017
> @@ -284,6 +284,13 @@ private:
>// ClangdServer
>ClangdScheduler WorkScheduler;
>bool SnippetCompletions;
> +
> + /// Used to serialize diagnostic callbacks.
> + /// FIXME(ibiryukov): get rid of an extra map and put all version
> counters
> + /// into CppFile.
> + std::mutex DiagnosticsMutex;
> + /// Maps from a filename to the latest version of reported diagnostics.
> + llvm::StringMap ReportedDiagnosticVersions;
> };
>
> } // namespace clangd
>
> Modified: clang-tools-extra/trunk/clangd/DraftStore.h
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clangd/DraftStore.h?rev=313754&r1=313753&r2=313754&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/DraftStore.h (original)
> +++ clang-tools-extra/trunk/clangd/DraftStore.h Wed Sep 20 05:58:55 2017
> @@ -13,6 +13,7 @@
> #include "Path.h"
> #include "clang/Basic/LLVM.h"
> #include "llvm/ADT/StringMap.h"
> +#include
> #include
> #include
> #include
> @@ -20,8 +21,8 @@
> namespace clang {
> namespace clangd {
>
> -/// Using 'unsigned' here to avoid undefined behaviour on overflow.
> -typedef unsigned DocVersion;
> +/// Using unsigned int type here to avoid undefined behaviour on overflow.
> +typedef uint64_t DocVersion;
>
> /// Document draft with a version of this draft.
> struct VersionedDraft {
>
> Modified: clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/unittests/clangd/ClangdTests.cpp?rev=313754&r1=
> 313753&r2=313754&view=diff
>
> ==
> --- clang-tools-extra/tru
Re: [clang-tools-extra] r313754 - [clangd] Serialize onDiagnosticsReady callbacks for the same file.
Perfect, thanks! On 20 September 2017 at 20:33, Ilya Biryukov wrote: > Fixed by r313801. > Sorry for all the trouble. > > On Wed, Sep 20, 2017 at 9:22 PM, Ilya Biryukov > wrote: > >> I think I know what's wrong. I've already seen those failures. std::mutex >> gets destroyed before threads waiting on it are joined. >> Will submit a fix shortly. >> >> On Wed, Sep 20, 2017 at 8:22 PM, Alex L wrote: >> >>> This commit causes the formatting.test to fail on macOS with an uncaught >>> exception: >>> >>> libc++abi.dylib: terminating with uncaught exception of type >>> std::__1::system_error: mutex lock failed: Invalid argument >>> http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA >>> _check/35642/ >>> >>> I'm still looking into it. It doesn't look like the sanitizers are >>> reporting anything suspicious. Do you by any chance know what went wrong? >>> If it will turn out to be a macOS only thing it might make sense to >>> XFAIL formatting.test until the issue is resolved. >>> >>> Thanks, >>> Alex >>> >>> On 20 September 2017 at 13:58, Ilya Biryukov via cfe-commits < >>> cfe-commits@lists.llvm.org> wrote: >>> Author: ibiryukov Date: Wed Sep 20 05:58:55 2017 New Revision: 313754 URL: http://llvm.org/viewvc/llvm-project?rev=313754&view=rev Log: [clangd] Serialize onDiagnosticsReady callbacks for the same file. Summary: Calls to onDiagnosticsReady were done concurrently before. This sometimes led to older versions of diagnostics being reported to the user after the newer versions. Reviewers: klimek, bkramer, krasimir Reviewed By: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D38032 Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp clang-tools-extra/trunk/clangd/ClangdServer.h clang-tools-extra/trunk/clangd/DraftStore.h clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/ clangd/ClangdServer.cpp?rev=313754&r1=313753&r2=313754&view=diff == --- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original) +++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Wed Sep 20 05:58:55 2017 @@ -315,6 +315,19 @@ std::future ClangdServer::schedule auto Diags = DeferredRebuild.get(); if (!Diags) return; // A new reparse was requested before this one completed. + +// We need to serialize access to resulting diagnostics to avoid calling +// `onDiagnosticsReady` in the wrong order. +std::lock_guard DiagsLock(DiagnosticsMutex); +DocVersion &LastReportedDiagsVersion = ReportedDiagnosticVersions[FileStr]; +// FIXME(ibiryukov): get rid of '<' comparison here. In the current +// implementation diagnostics will not be reported after version counters' +// overflow. This should not happen in practice, since DocVersion is a +// 64-bit unsigned integer. +if (Version < LastReportedDiagsVersion) + return; +LastReportedDiagsVersion = Version; + DiagConsumer.onDiagnosticsReady(FileStr, make_tagged(std::move(*Diags), Tag)); }; Modified: clang-tools-extra/trunk/clangd/ClangdServer.h URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/ clangd/ClangdServer.h?rev=313754&r1=313753&r2=313754&view=diff == --- clang-tools-extra/trunk/clangd/ClangdServer.h (original) +++ clang-tools-extra/trunk/clangd/ClangdServer.h Wed Sep 20 05:58:55 2017 @@ -284,6 +284,13 @@ private: // ClangdServer ClangdScheduler WorkScheduler; bool SnippetCompletions; + + /// Used to serialize diagnostic callbacks. + /// FIXME(ibiryukov): get rid of an extra map and put all version counters + /// into CppFile. + std::mutex DiagnosticsMutex; + /// Maps from a filename to the latest version of reported diagnostics. + llvm::StringMap ReportedDiagnosticVersions; }; } // namespace clangd Modified: clang-tools-extra/trunk/clangd/DraftStore.h URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/ clangd/DraftStore.h?rev=313754&r1=313753&r2=313754&view=diff == --- clang-tools-extra/trunk/clangd/DraftStore.h (original) +++ clang-tools-extra/trunk/clangd/DraftStore.h Wed Sep 20 05:58:55 2017 @@ -13,6 +13,7 @@ #include "Path.h" #include "clang/Basic
Re: r363009 - [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer
Hmm, the logging was meant to exercise the creation of chained diagnostic
consumer, so without it the test is kind of pointless. I'll undo your
change, but will set the file to "-" which will print the log to STDERR and
won't create new files. Does that sound reasonable?
Cheers,
Alex
On Tue, 11 Jun 2019 at 02:51, Ilya Biryukov wrote:
> Hi Alex,
>
> Just wanted to let you know that I removed logging of diagnostics into a
> file inside the unit test in r363041 to unbreak our integrate.
>
> On Tue, Jun 11, 2019 at 1:29 AM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Mon Jun 10 16:32:42 2019
>> New Revision: 363009
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=363009&view=rev
>> Log:
>> [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer
>> in the compiler
>>
>> The function SetUpDiagnosticLog that was called from createDiagnostics
>> didn't
>> handle the case where the diagnostics engine didn't own the diagnostics
>> consumer.
>> This is a potential problem for a clang tool, in particular some of the
>> follow-up
>> patches for clang-scan-deps will need this fix.
>>
>> Differential Revision: https://reviews.llvm.org/D63101
>>
>> Modified:
>> cfe/trunk/lib/Frontend/CompilerInstance.cpp
>> cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp
>>
>> Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=363009&r1=363008&r2=363009&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
>> +++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Mon Jun 10 16:32:42 2019
>> @@ -232,9 +232,13 @@ static void SetUpDiagnosticLog(Diagnosti
>>
>> std::move(StreamOwner));
>>if (CodeGenOpts)
>> Logger->setDwarfDebugFlags(CodeGenOpts->DwarfDebugFlags);
>> - assert(Diags.ownsClient());
>> - Diags.setClient(
>> - new ChainedDiagnosticConsumer(Diags.takeClient(),
>> std::move(Logger)));
>> + if (Diags.ownsClient()) {
>> +Diags.setClient(
>> +new ChainedDiagnosticConsumer(Diags.takeClient(),
>> std::move(Logger)));
>> + } else {
>> +Diags.setClient(
>> +new ChainedDiagnosticConsumer(Diags.getClient(),
>> std::move(Logger)));
>> + }
>> }
>>
>> static void SetupSerializedDiagnostics(DiagnosticOptions *DiagOpts,
>>
>> Modified: cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp?rev=363009&r1=363008&r2=363009&view=diff
>>
>> ==
>> --- cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp (original)
>> +++ cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp Mon Jun 10
>> 16:32:42 2019
>> @@ -8,6 +8,7 @@
>>
>> #include "clang/Frontend/CompilerInstance.h"
>> #include "clang/Frontend/CompilerInvocation.h"
>> +#include "clang/Frontend/TextDiagnosticPrinter.h"
>> #include "llvm/Support/FileSystem.h"
>> #include "llvm/Support/Format.h"
>> #include "llvm/Support/ToolOutputFile.h"
>> @@ -70,4 +71,21 @@ TEST(CompilerInstance, DefaultVFSOverlay
>>ASSERT_TRUE(Instance.getFileManager().getFile("vfs-virtual.file"));
>> }
>>
>> +TEST(CompilerInstance, AllowDiagnosticLogWithUnownedDiagnosticConsumer) {
>> + auto DiagOpts = new DiagnosticOptions();
>> + DiagOpts->DiagnosticLogFile = "log.diags";
>> +
>> + // Create the diagnostic engine with unowned consumer.
>> + std::string DiagnosticOutput;
>> + llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
>> + auto DiagPrinter = llvm::make_unique(
>> + DiagnosticsOS, new DiagnosticOptions());
>> + CompilerInstance Instance;
>> + IntrusiveRefCntPtr Diags =
>> Instance.createDiagnostics(
>> + DiagOpts, DiagPrinter.get(), /*ShouldOwnClient=*/false);
>> +
>> + Diags->Report(diag::err_expected) << "no crash";
>> + ASSERT_EQ(DiagnosticsOS.str(), "error: expected no crash\n");
>> +}
>> +
>> } // anonymous namespace
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
> --
> Regards,
> Ilya Biryukov
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r363009 - [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer
Thanks, that sounds good to me. I added the assignment with the new comment
in 363199.
On Wed, 12 Jun 2019 at 03:59, Ilya Biryukov wrote:
> Sure, that should work just fine. Could you also add a comment what events
> setting the log file sets in motion? It is not obvious from the test code.
>
> On Tue, Jun 11, 2019 at 6:51 PM Alex L wrote:
>
>> Hmm, the logging was meant to exercise the creation of chained diagnostic
>> consumer, so without it the test is kind of pointless. I'll undo your
>> change, but will set the file to "-" which will print the log to STDERR and
>> won't create new files. Does that sound reasonable?
>>
>> Cheers,
>> Alex
>>
>> On Tue, 11 Jun 2019 at 02:51, Ilya Biryukov wrote:
>>
>>> Hi Alex,
>>>
>>> Just wanted to let you know that I removed logging of diagnostics into a
>>> file inside the unit test in r363041 to unbreak our integrate.
>>>
>>> On Tue, Jun 11, 2019 at 1:29 AM Alex Lorenz via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
Author: arphaman
Date: Mon Jun 10 16:32:42 2019
New Revision: 363009
URL: http://llvm.org/viewvc/llvm-project?rev=363009&view=rev
Log:
[Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer
in the compiler
The function SetUpDiagnosticLog that was called from createDiagnostics
didn't
handle the case where the diagnostics engine didn't own the diagnostics
consumer.
This is a potential problem for a clang tool, in particular some of the
follow-up
patches for clang-scan-deps will need this fix.
Differential Revision: https://reviews.llvm.org/D63101
Modified:
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp
Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=363009&r1=363008&r2=363009&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Mon Jun 10 16:32:42 2019
@@ -232,9 +232,13 @@ static void SetUpDiagnosticLog(Diagnosti
std::move(StreamOwner));
if (CodeGenOpts)
Logger->setDwarfDebugFlags(CodeGenOpts->DwarfDebugFlags);
- assert(Diags.ownsClient());
- Diags.setClient(
- new ChainedDiagnosticConsumer(Diags.takeClient(),
std::move(Logger)));
+ if (Diags.ownsClient()) {
+Diags.setClient(
+new ChainedDiagnosticConsumer(Diags.takeClient(),
std::move(Logger)));
+ } else {
+Diags.setClient(
+new ChainedDiagnosticConsumer(Diags.getClient(),
std::move(Logger)));
+ }
}
static void SetupSerializedDiagnostics(DiagnosticOptions *DiagOpts,
Modified: cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp?rev=363009&r1=363008&r2=363009&view=diff
==
--- cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp (original)
+++ cfe/trunk/unittests/Frontend/CompilerInstanceTest.cpp Mon Jun 10
16:32:42 2019
@@ -8,6 +8,7 @@
#include "clang/Frontend/CompilerInstance.h"
#include "clang/Frontend/CompilerInvocation.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Format.h"
#include "llvm/Support/ToolOutputFile.h"
@@ -70,4 +71,21 @@ TEST(CompilerInstance, DefaultVFSOverlay
ASSERT_TRUE(Instance.getFileManager().getFile("vfs-virtual.file"));
}
+TEST(CompilerInstance,
AllowDiagnosticLogWithUnownedDiagnosticConsumer) {
+ auto DiagOpts = new DiagnosticOptions();
+ DiagOpts->DiagnosticLogFile = "log.diags";
+
+ // Create the diagnostic engine with unowned consumer.
+ std::string DiagnosticOutput;
+ llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
+ auto DiagPrinter = llvm::make_unique(
+ DiagnosticsOS, new DiagnosticOptions());
+ CompilerInstance Instance;
+ IntrusiveRefCntPtr Diags =
Instance.createDiagnostics(
+ DiagOpts, DiagPrinter.get(), /*ShouldOwnClient=*/false);
+
+ Diags->Report(diag::err_expected) << "no crash";
+ ASSERT_EQ(DiagnosticsOS.str(), "error: expected no crash\n");
+}
+
} // anonymous namespace
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>> --
>>> Regards,
>>> Ilya Biryukov
>>>
>>
>
> --
> Regards,
> Ilya Biryukov
>
Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find
On Wed, 12 Jun 2019 at 14:29, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Wed Jun 12 14:32:49 2019
> New Revision: 363204
>
> URL: http://llvm.org/viewvc/llvm-project?rev=363204&view=rev
> Log:
> [clang-scan-deps] initial outline of the tool that runs preprocessor to
> find
> dependencies over a JSON compilation database
>
> This commit introduces an outline for the clang-scan-deps tool that will be
> used to implement fast dependency discovery phase using implicit modules
> for
> explicit module builds.
>
> The initial version of the tool works by computing non-modular header
> dependencies
> for files in the compilation database without any optimizations
> (i.e. without source minimization from r362459).
> The tool spawns a number of worker threads to run the clang compiler
> workers in parallel.
>
> The immediate goal for clang-scan-deps is to create a ClangScanDeps library
> which will be used to build up this tool to use the source minimization and
> caching multi-threaded filesystem to implement the optimized
> non-incremental
> dependency scanning phase for a non-modular build. This will allow us to do
> benchmarks and comparisons for performance that the minimization and
> caching give us
>
> Differential Revision: https://reviews.llvm.org/D60233
>
> Added:
> cfe/trunk/test/ClangScanDeps/
> cfe/trunk/test/ClangScanDeps/Inputs/
> cfe/trunk/test/ClangScanDeps/Inputs/header.h
> cfe/trunk/test/ClangScanDeps/Inputs/header2.h
> cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
> cfe/trunk/tools/clang-scan-deps/
> cfe/trunk/tools/clang-scan-deps/CMakeLists.txt
> cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
> Modified:
> cfe/trunk/test/CMakeLists.txt
> cfe/trunk/tools/CMakeLists.txt
>
> Modified: cfe/trunk/test/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=363204&r1=363203&r2=363204&view=diff
>
> ==
> --- cfe/trunk/test/CMakeLists.txt (original)
> +++ cfe/trunk/test/CMakeLists.txt Wed Jun 12 14:32:49 2019
> @@ -57,6 +57,7 @@ list(APPEND CLANG_TEST_DEPS
>clang-rename
>clang-refactor
>clang-diff
> + clang-scan-deps
>diagtool
>hmaptool
>)
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/header.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header.h?rev=363204&view=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/header.h (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/header.h Wed Jun 12 14:32:49 2019
> @@ -0,0 +1,3 @@
> +#ifdef INCLUDE_HEADER2
> +#include "header2.h"
> +#endif
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/header2.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header2.h?rev=363204&view=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/header2.h (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/header2.h Wed Jun 12 14:32:49 2019
> @@ -0,0 +1 @@
> +// header 2.
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=363204&view=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json Wed Jun 12
> 14:32:49 2019
> @@ -0,0 +1,12 @@
> +[
> +{
> + "directory": "DIR",
> + "command": "clang -c DIR/regular_cdb.cpp -IInputs -MD -MF
> DIR/regular_cdb.d",
> + "file": "DIR/regular_cdb.cpp"
> +},
> +{
> + "directory": "DIR",
> + "command": "clang -c DIR/regular_cdb.cpp -IInputs -D INCLUDE_HEADER2
> -MD -MF DIR/regular_cdb2.d",
> + "file": "DIR/regular_cdb.cpp"
> +}
> +]
>
> Added: cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/regular_cdb.cpp?rev=363204&view=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/regular_cdb.cpp (added)
> +++ cfe/trunk/test/ClangScanDeps/regular_cdb.cpp Wed Jun 12 14:32:49 2019
> @@ -0,0 +1,27 @@
> +// RUN: rm -rf %t.dir
> +// RUN: rm -rf %t.cdb
> +// RUN: mkdir -p %t.dir
> +// RUN: cp %s %t.dir/regular_cdb.cpp
> +// RUN: mkdir %t.dir/Inputs
> +// RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
> +// RUN: cp %S/Inputs/header2.h %t.dir/Inputs/header2.h
> +// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/regular_cdb.json > %t.cdb
> +//
> +// RUN: clang-scan-deps -compilation-database %t.cdb -j 1
> +// RUN: cat %t.dir/regular_cdb.d | FileCheck %s
> +// RUN: cat %t.dir/regular_cdb2.d | FileCheck --check-prefix=CHECK2 %s
> +// RUN: rm -rf %t.dir/regular_cdb.
Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find
Hi Douglas,
Thanks for the heads up! That's definitely a bug.
I don't think "-c" is needed here. I will adjust this test this morning to
remove the "-c", and will address the bug later.
Thanks,
Alex
On Mon, 17 Jun 2019 at 18:02, wrote:
> Hi Alex,
>
> In the test you added here, the json file contains compile commands that
> includes "-c". Is that really necessary for the test to work properly?
>
> The reason I ask is that if you run in a configuration which does not use
> the integrated assembler, the test fails with an error due to the fact that
> an external assembler must be invoked:
>
> error: unable to handle compilation, expected exactly one compiler job in
> ' "clang" "-cc1" ...; "/usr/bin/as" "--64" "-I" "Inputs" "-o" "/dev/null"
>
> Changing the "-c" to "-S" still shows the test passing when I run it
> locally, so if the "-c" is not really needed, can it be changed to "-S" to
> work correctly where the integrated assembler is not the default option?
>
> Douglas Yung
>
> -Original Message-
> From: cfe-commits On Behalf Of Alex
> Lorenz via cfe-commits
> Sent: Wednesday, June 12, 2019 14:33
> To: cfe-commits@lists.llvm.org
> Subject: r363204 - [clang-scan-deps] initial outline of the tool that runs
> preprocessor to find
>
> Author: arphaman
> Date: Wed Jun 12 14:32:49 2019
> New Revision: 363204
>
> URL: http://llvm.org/viewvc/llvm-project?rev=363204&view=rev
> Log:
> [clang-scan-deps] initial outline of the tool that runs preprocessor to
> find dependencies over a JSON compilation database
>
> This commit introduces an outline for the clang-scan-deps tool that will
> be used to implement fast dependency discovery phase using implicit modules
> for explicit module builds.
>
> The initial version of the tool works by computing non-modular header
> dependencies for files in the compilation database without any
> optimizations (i.e. without source minimization from r362459).
> The tool spawns a number of worker threads to run the clang compiler
> workers in parallel.
>
> The immediate goal for clang-scan-deps is to create a ClangScanDeps
> library which will be used to build up this tool to use the source
> minimization and caching multi-threaded filesystem to implement the
> optimized non-incremental dependency scanning phase for a non-modular
> build. This will allow us to do benchmarks and comparisons for performance
> that the minimization and caching give us
>
> Differential Revision: https://reviews.llvm.org/D60233
>
> Added:
> cfe/trunk/test/ClangScanDeps/
> cfe/trunk/test/ClangScanDeps/Inputs/
> cfe/trunk/test/ClangScanDeps/Inputs/header.h
> cfe/trunk/test/ClangScanDeps/Inputs/header2.h
> cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
> cfe/trunk/tools/clang-scan-deps/
> cfe/trunk/tools/clang-scan-deps/CMakeLists.txt
> cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
> Modified:
> cfe/trunk/test/CMakeLists.txt
> cfe/trunk/tools/CMakeLists.txt
>
> Modified: cfe/trunk/test/CMakeLists.txt
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=363204&r1=363203&r2=363204&view=diff
>
> ==
> --- cfe/trunk/test/CMakeLists.txt (original)
> +++ cfe/trunk/test/CMakeLists.txt Wed Jun 12 14:32:49 2019
> @@ -57,6 +57,7 @@ list(APPEND CLANG_TEST_DEPS
>clang-rename
>clang-refactor
>clang-diff
> + clang-scan-deps
>diagtool
>hmaptool
>)
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/header.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header.h?rev=363204&view=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/header.h (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/header.h Wed Jun 12 14:32:49
> +++ 2019
> @@ -0,0 +1,3 @@
> +#ifdef INCLUDE_HEADER2
> +#include "header2.h"
> +#endif
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/header2.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header2.h?rev=363204&view=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/header2.h (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/header2.h Wed Jun 12 14:32:49
> +++ 2019
> @@ -0,0 +1 @@
> +// header 2.
>
> Added: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=363204&view=auto
>
> ==
> --- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (added)
> +++ cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json Wed Jun 12
> +++ 14:32:49 2019
> @@ -0,0 +1,12 @@
> +[
> +{
> + "directory": "DIR",
> + "command": "clang -c DIR/regular_cdb.cpp -IInputs -MD -MF
> +DIR/regular_cdb.d",
> + "file"
Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find
I committed r363742 with the fix to the test. Cheers, Alex On Tue, 18 Jun 2019 at 10:23, Alex L wrote: > Hi Douglas, > > Thanks for the heads up! That's definitely a bug. > I don't think "-c" is needed here. I will adjust this test this morning to > remove the "-c", and will address the bug later. > > Thanks, > Alex > > On Mon, 17 Jun 2019 at 18:02, wrote: > >> Hi Alex, >> >> In the test you added here, the json file contains compile commands that >> includes "-c". Is that really necessary for the test to work properly? >> >> The reason I ask is that if you run in a configuration which does not use >> the integrated assembler, the test fails with an error due to the fact that >> an external assembler must be invoked: >> >> error: unable to handle compilation, expected exactly one compiler job in >> ' "clang" "-cc1" ...; "/usr/bin/as" "--64" "-I" "Inputs" "-o" "/dev/null" >> >> Changing the "-c" to "-S" still shows the test passing when I run it >> locally, so if the "-c" is not really needed, can it be changed to "-S" to >> work correctly where the integrated assembler is not the default option? >> >> Douglas Yung >> >> -Original Message- >> From: cfe-commits On Behalf Of Alex >> Lorenz via cfe-commits >> Sent: Wednesday, June 12, 2019 14:33 >> To: cfe-commits@lists.llvm.org >> Subject: r363204 - [clang-scan-deps] initial outline of the tool that >> runs preprocessor to find >> >> Author: arphaman >> Date: Wed Jun 12 14:32:49 2019 >> New Revision: 363204 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=363204&view=rev >> Log: >> [clang-scan-deps] initial outline of the tool that runs preprocessor to >> find dependencies over a JSON compilation database >> >> This commit introduces an outline for the clang-scan-deps tool that will >> be used to implement fast dependency discovery phase using implicit modules >> for explicit module builds. >> >> The initial version of the tool works by computing non-modular header >> dependencies for files in the compilation database without any >> optimizations (i.e. without source minimization from r362459). >> The tool spawns a number of worker threads to run the clang compiler >> workers in parallel. >> >> The immediate goal for clang-scan-deps is to create a ClangScanDeps >> library which will be used to build up this tool to use the source >> minimization and caching multi-threaded filesystem to implement the >> optimized non-incremental dependency scanning phase for a non-modular >> build. This will allow us to do benchmarks and comparisons for performance >> that the minimization and caching give us >> >> Differential Revision: https://reviews.llvm.org/D60233 >> >> Added: >> cfe/trunk/test/ClangScanDeps/ >> cfe/trunk/test/ClangScanDeps/Inputs/ >> cfe/trunk/test/ClangScanDeps/Inputs/header.h >> cfe/trunk/test/ClangScanDeps/Inputs/header2.h >> cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json >> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp >> cfe/trunk/tools/clang-scan-deps/ >> cfe/trunk/tools/clang-scan-deps/CMakeLists.txt >> cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp >> Modified: >> cfe/trunk/test/CMakeLists.txt >> cfe/trunk/tools/CMakeLists.txt >> >> Modified: cfe/trunk/test/CMakeLists.txt >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=363204&r1=363203&r2=363204&view=diff >> >> == >> --- cfe/trunk/test/CMakeLists.txt (original) >> +++ cfe/trunk/test/CMakeLists.txt Wed Jun 12 14:32:49 2019 >> @@ -57,6 +57,7 @@ list(APPEND CLANG_TEST_DEPS >>clang-rename >>clang-refactor >>clang-diff >> + clang-scan-deps >>diagtool >>hmaptool >>) >> >> Added: cfe/trunk/test/ClangScanDeps/Inputs/header.h >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header.h?rev=363204&view=auto >> >> == >> --- cfe/trunk/test/ClangScanDeps/Inputs/header.h (added) >> +++ cfe/trunk/test/ClangScanDeps/Inputs/header.h Wed Jun 12 14:32:49 >> +++ 2019 >> @@ -0,0 +1,3 @@ >> +#ifdef INCLUDE_HEADER2 >> +#include "header2.h" >> +#endif >> >> Added: cfe/trunk/test/ClangScanDeps/Inputs/header2.h >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header2.h?rev=363204&view=auto >> >> == >> --- cfe/trunk/test/ClangScanDeps/Inputs/header2.h (added) >> +++ cfe/trunk/test/ClangScanDeps/Inputs/header2.h Wed Jun 12 14:32:49 >> +++ 2019 >> @@ -0,0 +1 @@ >> +// header 2. >> >> Added: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=363204&view=auto >> >> == >> --- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (added) >>
Re: r368354 - Mark clang-scan-deps test as requiring thread support
Thanks for fixing this! I think changing clang-scan-deps to ignore -j when `LLVM_ENABLE_THREADS` is probably a better solution. I'll work on a patch that does that. On Thu, 8 Aug 2019 at 15:07, Reid Kleckner wrote: > The specific issue here is that clang-scan-deps uses threads, which seems > to work just fine. But, it calls some code that sets up PrettyStackTrace > RAII objects, which normally use TLS. And when LLVM_ENABLE_THREADS is off, > LLVM_THREAD_LOCAL expands to nothing, so the TLS variables are simply > global, and the RAII objects assert that things haven't been constructed > and destructed in the correct order. > > So, going forward you will probably need to remember to add REQUIRES: > thread_support to individual tests, or change clang-scan-deps to ignore the > -j parameter when threads have been disabled. > > On Thu, Aug 8, 2019 at 2:45 PM Reid Kleckner via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: rnk >> Date: Thu Aug 8 14:45:59 2019 >> New Revision: 368354 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=368354&view=rev >> Log: >> Mark clang-scan-deps test as requiring thread support >> >> Otherwise the test calls a pure virtual method and crashes. Perhaps this >> could be improved. >> >> Modified: >> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp >> >> Modified: cfe/trunk/test/ClangScanDeps/regular_cdb.cpp >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/regular_cdb.cpp?rev=368354&r1=368353&r2=368354&view=diff >> >> == >> --- cfe/trunk/test/ClangScanDeps/regular_cdb.cpp (original) >> +++ cfe/trunk/test/ClangScanDeps/regular_cdb.cpp Thu Aug 8 14:45:59 2019 >> @@ -1,3 +1,4 @@ >> +// REQUIRES: thread_support >> // RUN: rm -rf %t.dir >> // RUN: rm -rf %t.cdb >> // RUN: mkdir -p %t.dir >> >> >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r368354 - Mark clang-scan-deps test as requiring thread support
Hi Reid, I have fixed this issue in r368640, clang-scan-deps will no longer spawn threads if threading if disabled. Cheers, Alex On Thu, 8 Aug 2019 at 15:13, Alex L wrote: > Thanks for fixing this! > > I think changing clang-scan-deps to ignore -j when `LLVM_ENABLE_THREADS` > is probably a better solution. I'll work on a patch that does that. > > > > On Thu, 8 Aug 2019 at 15:07, Reid Kleckner wrote: > >> The specific issue here is that clang-scan-deps uses threads, which seems >> to work just fine. But, it calls some code that sets up PrettyStackTrace >> RAII objects, which normally use TLS. And when LLVM_ENABLE_THREADS is off, >> LLVM_THREAD_LOCAL expands to nothing, so the TLS variables are simply >> global, and the RAII objects assert that things haven't been constructed >> and destructed in the correct order. >> >> So, going forward you will probably need to remember to add REQUIRES: >> thread_support to individual tests, or change clang-scan-deps to ignore the >> -j parameter when threads have been disabled. >> >> On Thu, Aug 8, 2019 at 2:45 PM Reid Kleckner via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> Author: rnk >>> Date: Thu Aug 8 14:45:59 2019 >>> New Revision: 368354 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=368354&view=rev >>> Log: >>> Mark clang-scan-deps test as requiring thread support >>> >>> Otherwise the test calls a pure virtual method and crashes. Perhaps this >>> could be improved. >>> >>> Modified: >>> cfe/trunk/test/ClangScanDeps/regular_cdb.cpp >>> >>> Modified: cfe/trunk/test/ClangScanDeps/regular_cdb.cpp >>> URL: >>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/regular_cdb.cpp?rev=368354&r1=368353&r2=368354&view=diff >>> >>> == >>> --- cfe/trunk/test/ClangScanDeps/regular_cdb.cpp (original) >>> +++ cfe/trunk/test/ClangScanDeps/regular_cdb.cpp Thu Aug 8 14:45:59 2019 >>> @@ -1,3 +1,4 @@ >>> +// REQUIRES: thread_support >>> // RUN: rm -rf %t.dir >>> // RUN: rm -rf %t.cdb >>> // RUN: mkdir -p %t.dir >>> >>> >>> ___ >>> cfe-commits mailing list >>> cfe-commits@lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>> >> ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D64149: [clang-scan-deps] use `-Wno-error` when scanning for dependencies
The warning output is suppressed, yes. Yeah, we should probably just disable them. I'll follow up with a commit. On Wed, 3 Jul 2019 at 15:25, Duncan P. N. Exon Smith via Phabricator < revi...@reviews.llvm.org> wrote: > dexonsmith added a comment. > > Is warning output suppressed? If so, should we just/also disable all > warnings? (IIRC, the flag is `-w`.) > > > Repository: > rL LLVM > > CHANGES SINCE LAST ACTION > https://reviews.llvm.org/D64149/new/ > > https://reviews.llvm.org/D64149 > > > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r350282 - [libclang] CoroutineBody/Coreturn statements are UnexposedStmts and not Exprs
Oops, I committed wrong column number in the test due to reindentation.
Fixed in r350283.
~ Alex
On Wed, 2 Jan 2019 at 17:16, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Wed Jan 2 17:13:33 2019
> New Revision: 350282
>
> URL: http://llvm.org/viewvc/llvm-project?rev=350282&view=rev
> Log:
> [libclang] CoroutineBody/Coreturn statements are UnexposedStmts and not
> Exprs
>
> This change ensures that the libclang CXCursor represents the CoroutineBody
> and the Coreturn statement using the appropriate CXCursor_UnexposedStmt
> kind
> instead of CXCursor_UnexposedExpr. The problem with CXCursor_UnexposedExpr
> is
> that the consumer functions assumed that CoroutineBody/Coreturn statements
> were valid expressions and performed an invalid downcast to Expr causing
> assertion failures or other crashes.
>
> rdar://40204290
>
> Added:
> cfe/trunk/test/Index/coroutines.cpp
> Modified:
> cfe/trunk/tools/libclang/CXCursor.cpp
>
> Added: cfe/trunk/test/Index/coroutines.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/coroutines.cpp?rev=350282&view=auto
>
> ==
> --- cfe/trunk/test/Index/coroutines.cpp (added)
> +++ cfe/trunk/test/Index/coroutines.cpp Wed Jan 2 17:13:33 2019
> @@ -0,0 +1,24 @@
> +// RUN: c-index-test -test-load-source all -c %s -fsyntax-only -target
> x86_64-apple-darwin9 -fcoroutines-ts -std=c++1z -I%S/../SemaCXX/Inputs |
> FileCheck %s
> +#include "std-coroutine.h"
> +
> +using std::experimental::suspend_always;
> +using std::experimental::suspend_never;
> +
> +struct promise_void {
> + void get_return_object();
> + suspend_always initial_suspend();
> + suspend_always final_suspend();
> + void return_void();
> + void unhandled_exception();
> +};
> +
> +template <>
> +struct std::experimental::coroutine_traits { using promise_type =
> promise_void; };
> +
> +void CoroutineTestRet() {
> + co_return;
> +}
> +// CHECK: [[@LINE-3]]:25: UnexposedStmt=
> +// CHECK-SAME: [[@LINE-4]]:25 - [[@LINE-2]]:2]
> +// CHECK: [[@LINE-4]]:5: UnexposedStmt=
> +// CHECK-SAME: [[@LINE-5]]:5 - [[@LINE-5]]:14]
>
> Modified: cfe/trunk/tools/libclang/CXCursor.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CXCursor.cpp?rev=350282&r1=350281&r2=350282&view=diff
>
> ==
> --- cfe/trunk/tools/libclang/CXCursor.cpp (original)
> +++ cfe/trunk/tools/libclang/CXCursor.cpp Wed Jan 2 17:13:33 2019
> @@ -241,16 +241,19 @@ CXCursor cxcursor::MakeCXCursor(const St
>case Stmt::SEHLeaveStmtClass:
> K = CXCursor_SEHLeaveStmt;
> break;
> -
> +
> + case Stmt::CoroutineBodyStmtClass:
> + case Stmt::CoreturnStmtClass:
> +K = CXCursor_UnexposedStmt;
> +break;
> +
>case Stmt::ArrayTypeTraitExprClass:
>case Stmt::AsTypeExprClass:
>case Stmt::AtomicExprClass:
>case Stmt::BinaryConditionalOperatorClass:
>case Stmt::TypeTraitExprClass:
> - case Stmt::CoroutineBodyStmtClass:
>case Stmt::CoawaitExprClass:
>case Stmt::DependentCoawaitExprClass:
> - case Stmt::CoreturnStmtClass:
>case Stmt::CoyieldExprClass:
>case Stmt::CXXBindTemporaryExprClass:
>case Stmt::CXXDefaultArgExprClass:
>
>
> ___
> 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: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"
Thanks for reverting the commit! Unfortunately I missed the failure back
then.
I fixed the leak and recommitted the change in r350666.
Cheers,
Alex
On Tue, 10 Jul 2018 at 12:53, Evgeniy Stepanov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: eugenis
> Date: Tue Jul 10 12:49:07 2018
> New Revision: 336716
>
> URL: http://llvm.org/viewvc/llvm-project?rev=336716&view=rev
> Log:
> Revert r336590 "[libclang] evalute compound statement cursors before
> trying to evaluate"
>
> New memory leaks in
> LibclangParseTest_EvaluateChildExpression_Test::TestBody()
>
> Modified:
> cfe/trunk/tools/libclang/CIndex.cpp
> cfe/trunk/unittests/libclang/LibclangTest.cpp
>
> Modified: cfe/trunk/tools/libclang/CIndex.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=336716&r1=336715&r2=336716&view=diff
>
> ==
> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
> +++ cfe/trunk/tools/libclang/CIndex.cpp Tue Jul 10 12:49:07 2018
> @@ -3890,19 +3890,6 @@ static const ExprEvalResult* evaluateExp
> }
>
> CXEvalResult clang_Cursor_Evaluate(CXCursor C) {
> - if (clang_getCursorKind(C) == CXCursor_CompoundStmt) {
> -const CompoundStmt *compoundStmt =
> cast(getCursorStmt(C));
> -Expr *expr = nullptr;
> -for (auto *bodyIterator : compoundStmt->body()) {
> - if ((expr = dyn_cast(bodyIterator))) {
> -break;
> - }
> -}
> -if (expr)
> - return const_cast(
> - reinterpret_cast(evaluateExpr(expr, C)));
> - }
> -
>const Decl *D = getCursorDecl(C);
>if (D) {
> const Expr *expr = nullptr;
> @@ -3916,6 +3903,19 @@ CXEvalResult clang_Cursor_Evaluate(CXCur
>evaluateExpr(const_cast(expr), C)));
> return nullptr;
>}
> +
> + const CompoundStmt *compoundStmt =
> dyn_cast_or_null(getCursorStmt(C));
> + if (compoundStmt) {
> +Expr *expr = nullptr;
> +for (auto *bodyIterator : compoundStmt->body()) {
> + if ((expr = dyn_cast(bodyIterator))) {
> +break;
> + }
> +}
> +if (expr)
> + return const_cast(
> + reinterpret_cast(evaluateExpr(expr, C)));
> + }
>return nullptr;
> }
>
>
> Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=336716&r1=336715&r2=336716&view=diff
>
> ==
> --- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
> +++ cfe/trunk/unittests/libclang/LibclangTest.cpp Tue Jul 10 12:49:07 2018
> @@ -461,47 +461,6 @@ TEST_F(LibclangParseTest, AllSkippedRang
>clang_disposeSourceRangeList(Ranges);
> }
>
> -TEST_F(LibclangParseTest, EvaluateChildExpression) {
> - std::string Main = "main.m";
> - WriteFile(Main, "#define kFOO @\"foo\"\n"
> - "void foobar(void) {\n"
> - " {kFOO;}\n"
> - "}\n");
> - ClangTU = clang_parseTranslationUnit(Index, Main.c_str(), nullptr, 0,
> nullptr,
> - 0, TUFlags);
> -
> - CXCursor C = clang_getTranslationUnitCursor(ClangTU);
> - clang_visitChildren(
> - C,
> - [](CXCursor cursor, CXCursor parent,
> - CXClientData client_data) -> CXChildVisitResult {
> -if (clang_getCursorKind(cursor) == CXCursor_FunctionDecl) {
> - int numberedStmt = 0;
> - clang_visitChildren(
> - cursor,
> - [](CXCursor cursor, CXCursor parent,
> - CXClientData client_data) -> CXChildVisitResult {
> -int &numberedStmt = *((int *)client_data);
> -if (clang_getCursorKind(cursor) == CXCursor_CompoundStmt)
> {
> - if (numberedStmt) {
> -CXEvalResult RE = clang_Cursor_Evaluate(cursor);
> -EXPECT_NE(RE, nullptr);
> -EXPECT_EQ(clang_EvalResult_getKind(RE),
> - CXEval_ObjCStrLiteral);
> -return CXChildVisit_Break;
> - }
> - numberedStmt++;
> -}
> -return CXChildVisit_Recurse;
> - },
> - &numberedStmt);
> - EXPECT_EQ(numberedStmt, 1);
> -}
> -return CXChildVisit_Continue;
> - },
> - nullptr);
> -}
> -
> class LibclangReparseTest : public LibclangParseTest {
> public:
>void DisplayDiagnostics() {
>
>
> ___
> 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: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"
Looks like there was another leak I missed. I'm working on fixing it now.
Cheers,
Alex
On Tue, 8 Jan 2019 at 14:38, Alex L wrote:
> Thanks for reverting the commit! Unfortunately I missed the failure back
> then.
> I fixed the leak and recommitted the change in r350666.
>
> Cheers,
> Alex
>
> On Tue, 10 Jul 2018 at 12:53, Evgeniy Stepanov via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: eugenis
>> Date: Tue Jul 10 12:49:07 2018
>> New Revision: 336716
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=336716&view=rev
>> Log:
>> Revert r336590 "[libclang] evalute compound statement cursors before
>> trying to evaluate"
>>
>> New memory leaks in
>> LibclangParseTest_EvaluateChildExpression_Test::TestBody()
>>
>> Modified:
>> cfe/trunk/tools/libclang/CIndex.cpp
>> cfe/trunk/unittests/libclang/LibclangTest.cpp
>>
>> Modified: cfe/trunk/tools/libclang/CIndex.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=336716&r1=336715&r2=336716&view=diff
>>
>> ==
>> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
>> +++ cfe/trunk/tools/libclang/CIndex.cpp Tue Jul 10 12:49:07 2018
>> @@ -3890,19 +3890,6 @@ static const ExprEvalResult* evaluateExp
>> }
>>
>> CXEvalResult clang_Cursor_Evaluate(CXCursor C) {
>> - if (clang_getCursorKind(C) == CXCursor_CompoundStmt) {
>> -const CompoundStmt *compoundStmt =
>> cast(getCursorStmt(C));
>> -Expr *expr = nullptr;
>> -for (auto *bodyIterator : compoundStmt->body()) {
>> - if ((expr = dyn_cast(bodyIterator))) {
>> -break;
>> - }
>> -}
>> -if (expr)
>> - return const_cast(
>> - reinterpret_cast(evaluateExpr(expr, C)));
>> - }
>> -
>>const Decl *D = getCursorDecl(C);
>>if (D) {
>> const Expr *expr = nullptr;
>> @@ -3916,6 +3903,19 @@ CXEvalResult clang_Cursor_Evaluate(CXCur
>>evaluateExpr(const_cast(expr), C)));
>> return nullptr;
>>}
>> +
>> + const CompoundStmt *compoundStmt =
>> dyn_cast_or_null(getCursorStmt(C));
>> + if (compoundStmt) {
>> +Expr *expr = nullptr;
>> +for (auto *bodyIterator : compoundStmt->body()) {
>> + if ((expr = dyn_cast(bodyIterator))) {
>> +break;
>> + }
>> +}
>> +if (expr)
>> + return const_cast(
>> + reinterpret_cast(evaluateExpr(expr, C)));
>> + }
>>return nullptr;
>> }
>>
>>
>> Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=336716&r1=336715&r2=336716&view=diff
>>
>> ==
>> --- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
>> +++ cfe/trunk/unittests/libclang/LibclangTest.cpp Tue Jul 10 12:49:07 2018
>> @@ -461,47 +461,6 @@ TEST_F(LibclangParseTest, AllSkippedRang
>>clang_disposeSourceRangeList(Ranges);
>> }
>>
>> -TEST_F(LibclangParseTest, EvaluateChildExpression) {
>> - std::string Main = "main.m";
>> - WriteFile(Main, "#define kFOO @\"foo\"\n"
>> - "void foobar(void) {\n"
>> - " {kFOO;}\n"
>> - "}\n");
>> - ClangTU = clang_parseTranslationUnit(Index, Main.c_str(), nullptr, 0,
>> nullptr,
>> - 0, TUFlags);
>> -
>> - CXCursor C = clang_getTranslationUnitCursor(ClangTU);
>> - clang_visitChildren(
>> - C,
>> - [](CXCursor cursor, CXCursor parent,
>> - CXClientData client_data) -> CXChildVisitResult {
>> -if (clang_getCursorKind(cursor) == CXCursor_FunctionDecl) {
>> - int numberedStmt = 0;
>> - clang_visitChildren(
>> - cursor,
>> - [](CXCursor cursor, CXCursor parent,
>> - CXClientData client_data) -> CXChildVisitResult {
>> -int &numberedStmt = *((int *)client_data);
>> -if (clang_getCursorKind(cursor) ==
>> CXCursor_CompoundStmt) {
>> - if (numberedStmt) {
>> -CXEvalResult RE = clang_Cursor_Evaluate(cursor);
>> -EXPECT_NE(RE, nullptr);
>> -EXPECT_EQ(clang_EvalResult_getKind(RE),
>> - CXEval_ObjCStrLiteral);
>> -return CXChildVisit_Break;
>> - }
>> - numberedStmt++;
>> -}
>> -return CXChildVisit_Recurse;
>> - },
>> - &numberedStmt);
>> - EXPECT_EQ(numberedStmt, 1);
>> -}
>> -return CXChildVisit_Continue;
>> - },
>> - nullptr);
>> -}
>> -
>> class LibclangReparseTest : public LibclangParseTest {
>> public:
>>void DisplayDiagnostics() {
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
Re: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"
Fixed in r350680.
On Tue, 8 Jan 2019 at 15:24, Alex L wrote:
> Looks like there was another leak I missed. I'm working on fixing it now.
> Cheers,
> Alex
>
> On Tue, 8 Jan 2019 at 14:38, Alex L wrote:
>
>> Thanks for reverting the commit! Unfortunately I missed the failure back
>> then.
>> I fixed the leak and recommitted the change in r350666.
>>
>> Cheers,
>> Alex
>>
>> On Tue, 10 Jul 2018 at 12:53, Evgeniy Stepanov via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: eugenis
>>> Date: Tue Jul 10 12:49:07 2018
>>> New Revision: 336716
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=336716&view=rev
>>> Log:
>>> Revert r336590 "[libclang] evalute compound statement cursors before
>>> trying to evaluate"
>>>
>>> New memory leaks in
>>> LibclangParseTest_EvaluateChildExpression_Test::TestBody()
>>>
>>> Modified:
>>> cfe/trunk/tools/libclang/CIndex.cpp
>>> cfe/trunk/unittests/libclang/LibclangTest.cpp
>>>
>>> Modified: cfe/trunk/tools/libclang/CIndex.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=336716&r1=336715&r2=336716&view=diff
>>>
>>> ==
>>> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
>>> +++ cfe/trunk/tools/libclang/CIndex.cpp Tue Jul 10 12:49:07 2018
>>> @@ -3890,19 +3890,6 @@ static const ExprEvalResult* evaluateExp
>>> }
>>>
>>> CXEvalResult clang_Cursor_Evaluate(CXCursor C) {
>>> - if (clang_getCursorKind(C) == CXCursor_CompoundStmt) {
>>> -const CompoundStmt *compoundStmt =
>>> cast(getCursorStmt(C));
>>> -Expr *expr = nullptr;
>>> -for (auto *bodyIterator : compoundStmt->body()) {
>>> - if ((expr = dyn_cast(bodyIterator))) {
>>> -break;
>>> - }
>>> -}
>>> -if (expr)
>>> - return const_cast(
>>> - reinterpret_cast(evaluateExpr(expr, C)));
>>> - }
>>> -
>>>const Decl *D = getCursorDecl(C);
>>>if (D) {
>>> const Expr *expr = nullptr;
>>> @@ -3916,6 +3903,19 @@ CXEvalResult clang_Cursor_Evaluate(CXCur
>>>evaluateExpr(const_cast(expr), C)));
>>> return nullptr;
>>>}
>>> +
>>> + const CompoundStmt *compoundStmt =
>>> dyn_cast_or_null(getCursorStmt(C));
>>> + if (compoundStmt) {
>>> +Expr *expr = nullptr;
>>> +for (auto *bodyIterator : compoundStmt->body()) {
>>> + if ((expr = dyn_cast(bodyIterator))) {
>>> +break;
>>> + }
>>> +}
>>> +if (expr)
>>> + return const_cast(
>>> + reinterpret_cast(evaluateExpr(expr, C)));
>>> + }
>>>return nullptr;
>>> }
>>>
>>>
>>> Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=336716&r1=336715&r2=336716&view=diff
>>>
>>> ==
>>> --- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
>>> +++ cfe/trunk/unittests/libclang/LibclangTest.cpp Tue Jul 10 12:49:07
>>> 2018
>>> @@ -461,47 +461,6 @@ TEST_F(LibclangParseTest, AllSkippedRang
>>>clang_disposeSourceRangeList(Ranges);
>>> }
>>>
>>> -TEST_F(LibclangParseTest, EvaluateChildExpression) {
>>> - std::string Main = "main.m";
>>> - WriteFile(Main, "#define kFOO @\"foo\"\n"
>>> - "void foobar(void) {\n"
>>> - " {kFOO;}\n"
>>> - "}\n");
>>> - ClangTU = clang_parseTranslationUnit(Index, Main.c_str(), nullptr, 0,
>>> nullptr,
>>> - 0, TUFlags);
>>> -
>>> - CXCursor C = clang_getTranslationUnitCursor(ClangTU);
>>> - clang_visitChildren(
>>> - C,
>>> - [](CXCursor cursor, CXCursor parent,
>>> - CXClientData client_data) -> CXChildVisitResult {
>>> -if (clang_getCursorKind(cursor) == CXCursor_FunctionDecl) {
>>> - int numberedStmt = 0;
>>> - clang_visitChildren(
>>> - cursor,
>>> - [](CXCursor cursor, CXCursor parent,
>>> - CXClientData client_data) -> CXChildVisitResult {
>>> -int &numberedStmt = *((int *)client_data);
>>> -if (clang_getCursorKind(cursor) ==
>>> CXCursor_CompoundStmt) {
>>> - if (numberedStmt) {
>>> -CXEvalResult RE = clang_Cursor_Evaluate(cursor);
>>> -EXPECT_NE(RE, nullptr);
>>> -EXPECT_EQ(clang_EvalResult_getKind(RE),
>>> - CXEval_ObjCStrLiteral);
>>> -return CXChildVisit_Break;
>>> - }
>>> - numberedStmt++;
>>> -}
>>> -return CXChildVisit_Recurse;
>>> - },
>>> - &numberedStmt);
>>> - EXPECT_EQ(numberedStmt, 1);
>>> -}
>>> -return CXChildVisit_Continue;
>>> - },
>>> - nullptr);
>>> -}
>>> -
>>> class LibclangReparseTest : public LibclangParseTest {
>>> public:
>>>
Re: r274222 - [GCC] PR23529 Mangler part of attrbute abi_tag support
Hi Dmitry,
I think that this commit has caused a regression that's tracked by PR
30440. I'll try working on a fix for it.
Alex
On 30 June 2016 at 02:40, Dmitry Polukhin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: dpolukhin
> Date: Thu Jun 30 04:40:38 2016
> New Revision: 274222
>
> URL: http://llvm.org/viewvc/llvm-project?rev=274222&view=rev
> Log:
> [GCC] PR23529 Mangler part of attrbute abi_tag support
>
> Original patch by Stefan Bühler http://reviews.llvm.org/D12834
>
> Difference between original and this one:
> - fixed all failing tests
> - fixed mangling for global variable outside namespace
> - emit ABI tags for guards and local names
> - clang-format + other stylistic changes
> - significantly reworked patch according to Richard's suggestions
>
> Sema part, committed before http://reviews.llvm.org/D17567
>
> Differential revision: http://reviews.llvm.org/D18035
>
> Added:
> cfe/trunk/test/CodeGenCXX/mangle-abi-tag.cpp (with props)
> Modified:
> cfe/trunk/lib/AST/ItaniumMangle.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/PCH/attrs.c
> cfe/trunk/test/SemaCXX/attr-abi-tag-syntax.cpp
>
> Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/
> ItaniumMangle.cpp?rev=274222&r1=274221&r2=274222&view=diff
>
> ==
> --- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
> +++ cfe/trunk/lib/AST/ItaniumMangle.cpp Thu Jun 30 04:40:38 2016
> @@ -214,6 +214,12 @@ public:
> class CXXNameMangler {
>ItaniumMangleContextImpl &Context;
>raw_ostream &Out;
> + bool NullOut = false;
> + /// In the "DisableDerivedAbiTags" mode derived ABI tags are not
> calculated.
> + /// This mode is used when mangler creates another mangler recursively
> to
> + /// calculate ABI tags for the function return value or the variable
> type.
> + /// Also it is required to avoid infinite recursion in some cases.
> + bool DisableDerivedAbiTags = false;
>
>/// The "structor" is the top-level declaration being mangled, if
>/// that's not a template specialization; otherwise it's the pattern
> @@ -263,15 +269,126 @@ class CXXNameMangler {
>
>} FunctionTypeDepth;
>
> + // abi_tag is a gcc attribute, taking one or more strings called "tags".
> + // The goal is to annotate against which version of a library an object
> was
> + // built and to be able to provide backwards compatibility ("dual abi").
> + // For more information see docs/ItaniumMangleAbiTags.rst.
> + typedef SmallVector AbiTagList;
> +
> + // State to gather all implicit and explicit tags used in a mangled
> name.
> + // Must always have an instance of this while emitting any name to keep
> + // track.
> + class AbiTagState final {
> + public:
> +explicit AbiTagState(AbiTagState *&Head) : LinkHead(Head) {
> + Parent = LinkHead;
> + LinkHead = this;
> +}
> +
> +// No copy, no move.
> +AbiTagState(const AbiTagState &) = delete;
> +AbiTagState &operator=(const AbiTagState &) = delete;
> +
> +~AbiTagState() { pop(); }
> +
> +void write(raw_ostream &Out, const NamedDecl *ND,
> + const AbiTagList *AdditionalAbiTags) {
> + ND = cast(ND->getCanonicalDecl());
> + if (!isa(ND) && !isa(ND)) {
> +assert(
> +!AdditionalAbiTags &&
> +"only function and variables need a list of additional abi
> tags");
> +if (const auto *NS = dyn_cast(ND)) {
> + if (const auto *AbiTag = NS->getAttr()) {
> +UsedAbiTags.insert(UsedAbiTags.end(), AbiTag->tags().begin(),
> + AbiTag->tags().end());
> + }
> + // Don't emit abi tags for namespaces.
> + return;
> +}
> + }
> +
> + AbiTagList TagList;
> + if (const auto *AbiTag = ND->getAttr()) {
> +UsedAbiTags.insert(UsedAbiTags.end(), AbiTag->tags().begin(),
> + AbiTag->tags().end());
> +TagList.insert(TagList.end(), AbiTag->tags().begin(),
> + AbiTag->tags().end());
> + }
> +
> + if (AdditionalAbiTags) {
> +UsedAbiTags.insert(UsedAbiTags.end(), AdditionalAbiTags->begin(),
> + AdditionalAbiTags->end());
> +TagList.insert(TagList.end(), AdditionalAbiTags->begin(),
> + AdditionalAbiTags->end());
> + }
> +
> + std::sort(TagList.begin(), TagList.end());
> + TagList.erase(std::unique(TagList.begin(), TagList.end()),
> TagList.end());
> +
> + writeSortedUniqueAbiTags(Out, TagList);
> +}
> +
> +const AbiTagList &getUsedAbiTags() const { return UsedAbiTags; }
> +void setUsedAbiTags(const AbiTagList &AbiTags) {
> + UsedAbiTags = AbiTags;
> +}
> +
> +const AbiTagList &getEmittedAbiTags() const {
> + return EmittedAbiTags;
> +}
> +
> +const AbiTagList &getSortedUniqueUsedAbi
Re: r283102 - Fix PR 28885: Fix AST Printer output for the inherited constructor using
On 3 October 2016 at 13:12, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Mon Oct 3 07:12:03 2016
> New Revision: 283102
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283102&view=rev
> Log:
> Fix PR 28885: Fix AST Printer output for the inherited constructor using
> declarations.
>
> This commit ensures that the correct record type is printed out for the
> using declarations that represent C++ inherited constructors.
> It fixes a regression introduced in r274049 which changed the name that's
> stored in the using declarations that correspond to inherited constructors.
>
> Differential Revision: https://reviews.llvm.org/D25131
This was meant to be D25113, I'll revert and recommit.
Sorry about that,
Alex
>
>
> Modified:
> cfe/trunk/lib/AST/DeclPrinter.cpp
> cfe/trunk/test/SemaCXX/cxx11-ast-print.cpp
>
> Modified: cfe/trunk/lib/AST/DeclPrinter.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/
> DeclPrinter.cpp?rev=283102&r1=283101&r2=283102&view=diff
>
> ==
> --- cfe/trunk/lib/AST/DeclPrinter.cpp (original)
> +++ cfe/trunk/lib/AST/DeclPrinter.cpp Mon Oct 3 07:12:03 2016
> @@ -1346,6 +1346,17 @@ void DeclPrinter::VisitUsingDecl(UsingDe
>if (D->hasTypename())
> Out << "typename ";
>D->getQualifier()->print(Out, Policy);
> +
> + // Use the correct record name when the using declaration is used for
> + // inheriting constructors.
> + for (const auto *Shadow : D->shadows()) {
> +if (const auto *ConstructorShadow =
> +dyn_cast(Shadow)) {
> + assert(Shadow->getDeclContext() == ConstructorShadow->
> getDeclContext());
> + Out << *ConstructorShadow->getNominatedBaseClass();
> + return;
> +}
> + }
>Out << *D;
> }
>
>
> Modified: cfe/trunk/test/SemaCXX/cxx11-ast-print.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> SemaCXX/cxx11-ast-print.cpp?rev=283102&r1=283101&r2=283102&view=diff
>
> ==
> --- cfe/trunk/test/SemaCXX/cxx11-ast-print.cpp (original)
> +++ cfe/trunk/test/SemaCXX/cxx11-ast-print.cpp Mon Oct 3 07:12:03 2016
> @@ -43,6 +43,14 @@ template const char *ope
> // CHECK: const char *PR23120 = operator""_suffix();
> const char *PR23120 = U"ð ·"_suffix;
>
> +// PR28885
> +struct A {
> + A();
> +};
> +struct B : A {
> + using A::A; // CHECK: using A::A;
> +};// CHECK-NEXT: };
> +
> // CHECK: ;
> ;
> // CHECK-NOT: ;
>
>
> ___
> 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: r283102 - Fix PR 28885: Fix AST Printer output for the inherited constructor using
On 3 October 2016 at 13:23, Alex L wrote:
>
>
> On 3 October 2016 at 13:12, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Mon Oct 3 07:12:03 2016
>> New Revision: 283102
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=283102&view=rev
>> Log:
>> Fix PR 28885: Fix AST Printer output for the inherited constructor using
>> declarations.
>>
>> This commit ensures that the correct record type is printed out for the
>> using declarations that represent C++ inherited constructors.
>> It fixes a regression introduced in r274049 which changed the name that's
>> stored in the using declarations that correspond to inherited
>> constructors.
>>
>> Differential Revision: https://reviews.llvm.org/D25131
>
>
> This was meant to be D25113, I'll revert and recommit.
> Sorry about that,
> Alex
>
>
I ended up looking at the wrong tab, and though that this was meant to be
D25113 (another one my phabricator diff), but the original link is correct.
I re-committed with the right link.
Sorry about all the noise (I just had a bad morning),
Alex
>
>>
>> Modified:
>> cfe/trunk/lib/AST/DeclPrinter.cpp
>> cfe/trunk/test/SemaCXX/cxx11-ast-print.cpp
>>
>> Modified: cfe/trunk/lib/AST/DeclPrinter.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclPr
>> inter.cpp?rev=283102&r1=283101&r2=283102&view=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/DeclPrinter.cpp (original)
>> +++ cfe/trunk/lib/AST/DeclPrinter.cpp Mon Oct 3 07:12:03 2016
>> @@ -1346,6 +1346,17 @@ void DeclPrinter::VisitUsingDecl(UsingDe
>>if (D->hasTypename())
>> Out << "typename ";
>>D->getQualifier()->print(Out, Policy);
>> +
>> + // Use the correct record name when the using declaration is used for
>> + // inheriting constructors.
>> + for (const auto *Shadow : D->shadows()) {
>> +if (const auto *ConstructorShadow =
>> +dyn_cast(Shadow)) {
>> + assert(Shadow->getDeclContext() == ConstructorShadow->getDeclCont
>> ext());
>> + Out << *ConstructorShadow->getNominatedBaseClass();
>> + return;
>> +}
>> + }
>>Out << *D;
>> }
>>
>>
>> Modified: cfe/trunk/test/SemaCXX/cxx11-ast-print.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/
>> cxx11-ast-print.cpp?rev=283102&r1=283101&r2=283102&view=diff
>>
>> ==
>> --- cfe/trunk/test/SemaCXX/cxx11-ast-print.cpp (original)
>> +++ cfe/trunk/test/SemaCXX/cxx11-ast-print.cpp Mon Oct 3 07:12:03 2016
>> @@ -43,6 +43,14 @@ template const char *ope
>> // CHECK: const char *PR23120 = operator""_suffix();
>> const char *PR23120 = U"ð ·"_suffix;
>>
>> +// PR28885
>> +struct A {
>> + A();
>> +};
>> +struct B : A {
>> + using A::A; // CHECK: using A::A;
>> +};// CHECK-NEXT: };
>> +
>> // CHECK: ;
>> ;
>> // CHECK-NOT: ;
>>
>>
>> ___
>> 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] D25321: Fix PR13910: Don't warn that __builtin_unreachable() is unreachable
On 6 October 2016 at 15:50, David Blaikie wrote:
>
>
> On Thu, Oct 6, 2016 at 6:16 AM Alex Lorenz wrote:
>
>> arphaman created this revision.
>> arphaman added reviewers: dblaikie, krememek.
>> arphaman added a subscriber: cfe-commits.
>> arphaman set the repository for this revision to rL LLVM.
>>
>> This patch fixes the issue of clang emitting an unreachable warning when
>> it encounters unreachable `__builtin_unreachable()` statements. It detects
>> references to `__builtin_unreachable` and doesn't emit an unreachable
>> warning for them.
>>
>>
>> Repository:
>> rL LLVM
>>
>> https://reviews.llvm.org/D25321
>>
>> Files:
>> lib/Analysis/ReachableCode.cpp
>> test/Sema/warn-unreachable.c
>>
>>
>> Index: test/Sema/warn-unreachable.c
>> ===
>> --- test/Sema/warn-unreachable.c
>> +++ test/Sema/warn-unreachable.c
>> @@ -396,3 +396,40 @@
>>else
>> calledFun();
>> }
>> +
>> +int pr13910_foo(int x) {
>> + if (x == 1)
>> +return 0;
>> + else
>> +return x;
>> + __builtin_unreachable(); // expected no warning
>> +}
>> +
>> +int pr13910_bar(int x) {
>> + switch (x) {
>> + default:
>> +return x + 1;
>> + }
>> + pr13910_foo(x); // expected-warning {{code will never be executed}}
>> +}
>> +
>> +int pr13910_bar2(int x) {
>> + if (x == 1)
>> +return 0;
>> + else
>> +return x;
>> + pr13910_foo(x); // expected-warning {{code will never be
>> executed}}
>> + __builtin_unreachable(); // expected no warning
>> + pr13910_foo(x); // expected-warning {{code will never be
>> executed}}
>>
>
> Seems strange to have two warnings here ^ is that a separate bug?
>
It seems that it might be, yeah. For example, clang emits two unreachable
warnings for the two `foo` calls in this code:
int foo() {
return 0;
}
int bar(int x) {
if (x == 0)
return x + 1;
else
return x;
foo();
return 0;
foo();
}
But just one when the `return 0` that's between the two `foo` calls is
removed. It doesn't seem like there's a PR for this issue, I'll file one
later on today.
>
>
>> +}
>> +
>> +void pr13910_noreturn() {
>> + raze();
>> + __builtin_unreachable(); // expected no warning
>> +}
>> +
>> +void pr13910_assert() {
>> + myassert(0 && "unreachable");
>> + return;
>> + __builtin_unreachable(); // expected no warning
>> +}
>> Index: lib/Analysis/ReachableCode.cpp
>> ===
>> --- lib/Analysis/ReachableCode.cpp
>> +++ lib/Analysis/ReachableCode.cpp
>> @@ -58,6 +58,15 @@
>>return false;
>> }
>>
>> +static bool isBuiltinUnreachable(const CFGBlock *B, const Stmt *S) {
>> + if (const DeclRefExpr *DRE = dyn_cast(S)) {
>> +const FunctionDecl *FDecl = dyn_cast(DRE->getDecl());
>> +return FDecl && FDecl->getIdentifier() &&
>> + FDecl->getBuiltinID() == Builtin::BI__builtin_unreachable;
>> + }
>> + return false;
>> +}
>> +
>> static bool isDeadReturn(const CFGBlock *B, const Stmt *S) {
>>// Look to see if the current control flow ends with a 'return', and
>> see if
>>// 'S' is a substatement. The 'return' may not be the last element in
>> the
>> @@ -574,8 +583,7 @@
>>
>>if (isa(S)) {
>> UK = reachable_code::UK_Break;
>> - }
>> - else if (isTrivialDoWhile(B, S)) {
>> + } else if (isTrivialDoWhile(B, S) || isBuiltinUnreachable(B, S)) {
>> return;
>>}
>>else if (isDeadReturn(B, S)) {
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D25539: [Coverage] Support for C++17 switch initializers
On 13 October 2016 at 03:42, Richard Smith wrote:
> Do we need the same change for if-statements too?
>
Yes, a similar change should be made for them as well.
>
> On 12 Oct 2016 6:26 pm, "Vedant Kumar via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
>> vsk created this revision.
>> vsk added reviewers: arphaman, ikudrin.
>> vsk added a subscriber: cfe-commits.
>>
>> Generate coverage mappings for in switch (; ).
>>
>> I'm unsure about whether or not the CodeGenPGO change in this patch
>> deserves more testing.
>>
>>
>> https://reviews.llvm.org/D25539
>>
>> Files:
>> lib/CodeGen/CodeGenPGO.cpp
>> lib/CodeGen/CoverageMappingGen.cpp
>> test/CoverageMapping/switch.c
>> test/CoverageMapping/switch.cpp
>>
>>
>> Index: test/CoverageMapping/switch.cpp
>> ===
>> --- test/CoverageMapping/switch.cpp
>> +++ test/CoverageMapping/switch.cpp
>> @@ -1,4 +1,5 @@
>> -// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping
>> -dump-coverage-mapping -emit-llvm-only -main-file-name switch.c %s |
>> FileCheck %s
>> +// RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping
>> -dump-coverage-mapping -emit-llvm-only -std=c++1z -triple
>> %itanium_abi_triple -main-file-name switch.cpp %s | FileCheck %s
>> +
>> // CHECK: foo
>> void foo(int i) { // CHECK-NEXT: File 0, [[@LINE]]:17 -> [[@LINE+8]]:2
>> = #0
>>switch(i) {
>> @@ -10,7 +11,7 @@
>>int x = 0;// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:2
>> = #1
>> }
>>
>> -void nop() {}
>> +int nop() { return 0; }
>>
>> // CHECK: bar
>> void bar(int i) { // CHECK-NEXT: File 0, [[@LINE]]:17 ->
>> [[@LINE+20]]:2 = #0
>> @@ -35,8 +36,16 @@
>>nop();// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:2
>> = #6
>> }
>>
>> +// CHECK: baz
>> +void baz() {// CHECK-NEXT: File 0, [[@LINE]]:12 -> [[@LINE+5]]:2
>> = #0
>> + switch (int i = true ? nop() // CHECK-NEXT: [[@LINE]]:26 ->
>> [[@LINE]]:31 = #2
>> + : nop(); // CHECK-NEXT: [[@LINE]]:26 ->
>> [[@LINE]]:31 = (#0 - #2)
>> + i) {}
>> + nop();// CHECK-NEXT: [[@LINE]]:3 -> [[@LINE+1]]:2 = #1
>> +}
>> +
>> // CHECK-NEXT: main
>> -int main() {// CHECK-NEXT: File 0, [[@LINE]]:12 ->
>> [[@LINE+34]]:2 = #0
>> +int main() {// CHECK-NEXT: File 0, [[@LINE]]:12 ->
>> [[@LINE+35]]:2 = #0
>>int i = 0;
>>switch(i) {
>>case 0: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+7]]:10
>> = #2
>> @@ -48,7 +57,7 @@
>>default: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10
>> = #4
>> break;
>>}
>> - switch(i) { // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+22]]:2
>> = #1
>> + switch(i) { // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+23]]:2
>> = #1
>>case 0: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+6]]:10
>> = #6
>> i = 1;
>> break;
>> @@ -58,16 +67,17 @@
>> break;
>>}
>>
>> - switch(i) { // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+12]]:2
>> = #5
>> + switch(i) { // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+13]]:2
>> = #5
>>case 1: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+5]]:11
>> = #10
>>case 2: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+4]]:11
>> = (#10 + #11)
>> i = 11;
>>case 3: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:11
>> = ((#10 + #11) + #12)
>>case 4: // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:11
>> = (((#10 + #11) + #12) + #13)
>> i = 99;
>>}
>>
>> - foo(1); // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:11
>> = #9
>> + foo(1); // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+3]]:11
>> = #9
>>bar(1);
>> + baz();
>>return 0;
>> }
>> Index: lib/CodeGen/CoverageMappingGen.cpp
>> ===
>> --- lib/CodeGen/CoverageMappingGen.cpp
>> +++ lib/CodeGen/CoverageMappingGen.cpp
>> @@ -813,6 +813,9 @@
>>
>>void VisitSwitchStmt(const SwitchStmt *S) {
>> extendRegion(S);
>> +if (S->getInit())
>> + Visit(S->getInit());
>> +
>> Visit(S->getCond());
>>
>> BreakContinueStack.push_back(BreakContinue());
>> Index: lib/CodeGen/CodeGenPGO.cpp
>> ===
>> --- lib/CodeGen/CodeGenPGO.cpp
>> +++ lib/CodeGen/CodeGenPGO.cpp
>> @@ -458,6 +458,8 @@
>>
>>void VisitSwitchStmt(const SwitchStmt *S) {
>> RecordStmtCount(S);
>> +if (S->getInit())
>> + Visit(S->getInit());
>> Visit(S->getCond());
>> CurrentCount = 0;
>> BreakContinueStack.push_back(BreakContinue());
>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
___
Re: r319715 - Fix record-parsing-invocation.c test on Windows
Thanks, I will take a look at it right now. I believe your solution is the
right fix.
On 5 December 2017 at 07:09, Sean Eveson wrote:
> Hi,
>
> It looks like the test is still failing on one of the Windows build bots:
> http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015
>
> From looking at the test locally it seems the problem is when you do `//
> RUN: not env...`. The env command doesn't get handled by llvm-lit.py,
> because it gets passed through to `not.exe`.
>
> In terms of fixing this test, changing from `not env X=Y COMMAND` to `env
> X=Y not COMMAND` works on my machine. Otherwise maybe llvm-lit could be
> changed to make the handling of env (and other utilities) consistent when
> used after a not?
>
> Thanks,
>
> Sean Eveson
> SN Systems - Sony Interactive Entertainment
>
> On Mon, Dec 4, 2017 at 11:21 PM, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Mon Dec 4 15:21:07 2017
>> New Revision: 319715
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=319715&view=rev
>> Log:
>> Fix record-parsing-invocation.c test on Windows
>>
>> We should not check for the forward slash '/'
>>
>> Modified:
>> cfe/trunk/test/Index/record-parsing-invocation.c
>>
>> Modified: cfe/trunk/test/Index/record-parsing-invocation.c
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/rec
>> ord-parsing-invocation.c?rev=319715&r1=319714&r2=319715&view=diff
>>
>> ==
>> --- cfe/trunk/test/Index/record-parsing-invocation.c (original)
>> +++ cfe/trunk/test/Index/record-parsing-invocation.c Mon Dec 4 15:21:07
>> 2017
>> @@ -18,4 +18,4 @@
>> # pragma clang __debug parser_crash
>> #endif
>>
>> -// CHECK: {"toolchain":"{{.*}}","libclang.operation":"parse","libclang
>> .opts":1,"args":["clang","-fno-spell-checking","{{.*}}/
>> record-parsing-invocation.c","-Xclang","-detailed-
>> preprocessing-record","-fallow-editor-placeholders"]}
>> +// CHECK: {"toolchain":"{{.*}}","libclang.operation":"parse","libclang
>> .opts":1,"args":["clang","-fno-spell-checking","{{.*}}
>> record-parsing-invocation.c","-Xclang","-detailed-
>> preprocessing-record","-fallow-editor-placeholders"]}
>>
>>
>> ___
>> 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: r319715 - Fix record-parsing-invocation.c test on Windows
I committed the fix in r319836.
On 5 December 2017 at 12:49, Alex L wrote:
> Thanks, I will take a look at it right now. I believe your solution is the
> right fix.
>
> On 5 December 2017 at 07:09, Sean Eveson wrote:
>
>> Hi,
>>
>> It looks like the test is still failing on one of the Windows build bots:
>> http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015
>>
>> From looking at the test locally it seems the problem is when you do `//
>> RUN: not env...`. The env command doesn't get handled by llvm-lit.py,
>> because it gets passed through to `not.exe`.
>>
>> In terms of fixing this test, changing from `not env X=Y COMMAND` to `env
>> X=Y not COMMAND` works on my machine. Otherwise maybe llvm-lit could be
>> changed to make the handling of env (and other utilities) consistent when
>> used after a not?
>>
>> Thanks,
>>
>> Sean Eveson
>> SN Systems - Sony Interactive Entertainment
>>
>> On Mon, Dec 4, 2017 at 11:21 PM, Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Mon Dec 4 15:21:07 2017
>>> New Revision: 319715
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=319715&view=rev
>>> Log:
>>> Fix record-parsing-invocation.c test on Windows
>>>
>>> We should not check for the forward slash '/'
>>>
>>> Modified:
>>> cfe/trunk/test/Index/record-parsing-invocation.c
>>>
>>> Modified: cfe/trunk/test/Index/record-parsing-invocation.c
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/rec
>>> ord-parsing-invocation.c?rev=319715&r1=319714&r2=319715&view=diff
>>>
>>> ==
>>> --- cfe/trunk/test/Index/record-parsing-invocation.c (original)
>>> +++ cfe/trunk/test/Index/record-parsing-invocation.c Mon Dec 4
>>> 15:21:07 2017
>>> @@ -18,4 +18,4 @@
>>> # pragma clang __debug parser_crash
>>> #endif
>>>
>>> -// CHECK: {"toolchain":"{{.*}}","libclang.operation":"parse","libclang
>>> .opts":1,"args":["clang","-fno-spell-checking","{{.*}}/recor
>>> d-parsing-invocation.c","-Xclang","-detailed-preprocessi
>>> ng-record","-fallow-editor-placeholders"]}
>>> +// CHECK: {"toolchain":"{{.*}}","libclang.operation":"parse","libclang
>>> .opts":1,"args":["clang","-fno-spell-checking","{{.*}}record
>>> -parsing-invocation.c","-Xclang","-detailed-preprocessi
>>> ng-record","-fallow-editor-placeholders"]}
>>>
>>>
>>> ___
>>> 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: r319848 - Fix another record-parsing-invocation.c test issue on Windows
I missed that one, thanks! Sorry about the breakages. On 5 December 2017 at 15:04, Douglas Yung via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: dyung > Date: Tue Dec 5 15:04:12 2017 > New Revision: 319848 > > URL: http://llvm.org/viewvc/llvm-project?rev=319848&view=rev > Log: > Fix another record-parsing-invocation.c test issue on Windows > > Lit's env should be used before not. (Another case missed by the previous > commit) > > > Modified: > cfe/trunk/test/Index/record-parsing-invocation.c > > Modified: cfe/trunk/test/Index/record-parsing-invocation.c > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/ > record-parsing-invocation.c?rev=319848&r1=319847&r2=319848&view=diff > > == > --- cfe/trunk/test/Index/record-parsing-invocation.c (original) > +++ cfe/trunk/test/Index/record-parsing-invocation.c Tue Dec 5 15:04:12 > 2017 > @@ -1,6 +1,6 @@ > // RUN: rm -rf %t > // RUN: mkdir %t > -// RUN: not env CINDEXTEST_INVOCATION_EMISSION_PATH=%t c-index-test > -test-load-source all %s > +// RUN: env CINDEXTEST_INVOCATION_EMISSION_PATH=%t not c-index-test > -test-load-source all %s > // RUN: cat %t/libclang-* | FileCheck %s > > // RUN: rm -rf %t > > > ___ > 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: r320297 - Fix MSVC 'not all control paths return a value' warning
Thanks!
On 10 December 2017 at 03:05, Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rksimon
> Date: Sun Dec 10 03:05:14 2017
> New Revision: 320297
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320297&view=rev
> Log:
> Fix MSVC 'not all control paths return a value' warning
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/
> ToolChains/Darwin.cpp?rev=320297&r1=320296&r2=320297&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Sun Dec 10 03:05:14 2017
> @@ -1230,6 +1230,7 @@ struct DarwinPlatform {
> case DeploymentTargetEnv:
>return (llvm::Twine(EnvVarName) + "=" + OSVersion).str();
> }
> +llvm_unreachable("Unsupported Darwin Source Kind");
>}
>
>static DarwinPlatform createOSVersionArg(DarwinPlatformKind Platform,
>
>
> ___
> 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: r369932 - Fix use of invalidated iterator introduced by r369680.
Thanks for the fix!
On Mon, 26 Aug 2019 at 10:29, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Mon Aug 26 10:31:06 2019
> New Revision: 369932
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369932&view=rev
> Log:
> Fix use of invalidated iterator introduced by r369680.
>
> Modified:
> cfe/trunk/lib/Basic/FileManager.cpp
>
> Modified: cfe/trunk/lib/Basic/FileManager.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/FileManager.cpp?rev=369932&r1=369931&r2=369932&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/FileManager.cpp (original)
> +++ cfe/trunk/lib/Basic/FileManager.cpp Mon Aug 26 10:31:06 2019
> @@ -263,15 +263,15 @@ FileManager::getFileRef(StringRef Filena
>// If the name returned by getStatValue is different than Filename,
> re-intern
>// the name.
>if (Status.getName() != Filename) {
> -auto &NamedFileEnt =
> +auto &NewNamedFileEnt =
> *SeenFileEntries.insert({Status.getName(), &UFE}).first;
> -assert((*NamedFileEnt.second).get() == &UFE &&
> +assert((*NewNamedFileEnt.second).get() == &UFE &&
> "filename from getStatValue() refers to wrong file");
> -InterndFileName = NamedFileEnt.first().data();
> +InterndFileName = NewNamedFileEnt.first().data();
> // In addition to re-interning the name, construct a redirecting seen
> file
> // entry, that will point to the name the filesystem actually wants
> to use.
> StringRef *Redirect = new (CanonicalNameStorage)
> StringRef(InterndFileName);
> -SeenFileInsertResult.first->second = Redirect;
> +NamedFileEnt.second = Redirect;
>}
>
>if (UFE.isValid()) { // Already have an entry with this inode, return
> it.
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r309106 - Recommit r308327 2nd time: Add a warning for missing
Thanks, I recommitted it in r309386. On 27 July 2017 at 15:53, Hans Wennborg wrote: > On Thu, Jul 27, 2017 at 3:41 AM, Alex L wrote: > > > > > > On 26 July 2017 at 22:32, Hans Wennborg wrote: > >> > >> On Wed, Jul 26, 2017 at 11:27 AM, Hans Wennborg > wrote: > >> > On Wed, Jul 26, 2017 at 5:20 AM, Alex Lorenz via cfe-commits > >> > wrote: > >> >> Author: arphaman > >> >> Date: Wed Jul 26 05:20:57 2017 > >> >> New Revision: 309106 > >> >> > >> >> URL: http://llvm.org/viewvc/llvm-project?rev=309106&view=rev > >> >> Log: > >> >> Recommit r308327 2nd time: Add a warning for missing > >> >> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in > included > >> >> files > >> >> > >> >> The first recommit (r308441) caused a "non-default #pragma pack value > >> >> might > >> >> change the alignment of struct or union members in the included file" > >> >> warning > >> >> in LLVM itself. This recommit tweaks the added warning to avoid > >> >> warnings for > >> >> #includes that don't have any records that are affected by the > >> >> non-default > >> >> alignment. This tweak avoids the previously emitted warning in LLVM. > >> >> > >> >> Original message: > >> >> > >> >> This commit adds a new -Wpragma-pack warning. It warns in the > following > >> >> cases: > >> >> > >> >> - When a translation unit is missing terminating #pragma pack (pop) > >> >> directives. > >> >> - When entering an included file if the current alignment value as > >> >> determined > >> >> by '#pragma pack' directives is different from the default > alignment > >> >> value. > >> >> - When leaving an included file that changed the state of the current > >> >> alignment > >> >> value. > >> >> > >> >> rdar://10184173 > >> >> > >> >> Differential Revision: https://reviews.llvm.org/D35484 > >> > > >> > We have code in Chromium that does exactly this: > >> > > >> > gles2_cmd_format.h does #pragma pack(push, 4) and then #includes a > >> > file with some generated structs, with the intention that the pragma > >> > applies to them. > >> > > >> > What's the best way to pacify the warning in this case? > >> > > >> > (We're tracking this in > >> > https://bugs.chromium.org/p/chromium/issues/detail?id=749197) > >> > >> I agree that cases 1) and 3) from your patch description make sense to > >> warn for, but I'm not sure that's the case for 2). Do you have > >> examples where this catches any bugs? In our case #pragma packing an > >> included file is intentional, and I suspect it might be a bit of a > >> pattern. > > > > > > I see, thanks for your input. > > > > 2) is generally designed for times when #pragma pack pop was accidentally > > used too late (after some #includes that unintentionally receive the > > alignment). I can see how some projects use this pattern heavily, and I > > don't think there's a good way to pacify this warning in that case. > > > > I think that for us it would be reasonable to turn 2) off by default, and > > allow users to enable it explicitly using a stronger flag (something like > > -Wpragma-pack-suspicious-include?). I think that I will leave 2) out of > this > > commit, recommit it without 2) and then commit 2) as a non-default > warning > > that uses a separate flag. > > That sounds reasonable. You can probably still do it with the same > commit, just moving 2) behind a separate flag. > > Thanks, > Hans > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r309386 - Recommit r308327 3rd time: Add a warning for missing
That's an interesting case. I'll tweak the warning to diagnose this scenario better today. On 29 July 2017 at 00:56, Hans Wennborg wrote: > On Fri, Jul 28, 2017 at 7:41 AM, Alex Lorenz via cfe-commits > wrote: > > Author: arphaman > > Date: Fri Jul 28 07:41:21 2017 > > New Revision: 309386 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=309386&view=rev > > Log: > > Recommit r308327 3rd time: Add a warning for missing > > '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included > files > > > > The second recommit (r309106) was reverted because the "non-default > #pragma > > pack value chages the alignment of struct or union members in the > included file" > > warning proved to be too aggressive for external projects like Chromium > > (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This > recommit > > makes the problematic warning a non-default one, and gives it the > > -Wpragma-pack-suspicious-include warning option. > > > > The first recommit (r308441) caused a "non-default #pragma pack value > might > > change the alignment of struct or union members in the included file" > warning > > in LLVM itself. This recommit tweaks the added warning to avoid warnings > for > > #includes that don't have any records that are affected by the > non-default > > alignment. This tweak avoids the previously emitted warning in LLVM. > > > > Original message: > > > > This commit adds a new -Wpragma-pack warning. It warns in the following > cases: > > > > - When a translation unit is missing terminating #pragma pack (pop) > directives. > > - When entering an included file if the current alignment value as > determined > > by '#pragma pack' directives is different from the default alignment > value. > > - When leaving an included file that changed the state of the current > alignment > > value. > > > > rdar://10184173 > > > > Differential Revision: https://reviews.llvm.org/D35484 > > We did get warnings with this version too, but this time it looks like > a real bug :-) > > C:\b\c\builder\ClangToTWin_dll_\src\third_party\usrsctp\ > usrsctplib\usrsctplib\netinet\sctp.h(51,9): > error: unterminated '#pragma pack (push, ...)' at end of file > [-Werror,-Wpragma-pack] > > The interesting thing is that the file does reset the alignment, but > it does it with a "#pragma pack()" which doesn't pop the stack, but > just resets to the default value. > > It might be worth tweaking the warning to give a better message for > this. A "#pragma pack(push, ..)" followed by "#pragma pack()" seems > pretty dodgy since there's no point in pushing if the code isn't going > to pop. > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r309386 - Recommit r308327 3rd time: Add a warning for missing
Add a note with a fixit in r309559. On 31 July 2017 at 10:50, Alex L wrote: > That's an interesting case. I'll tweak the warning to diagnose this > scenario better today. > > On 29 July 2017 at 00:56, Hans Wennborg wrote: > >> On Fri, Jul 28, 2017 at 7:41 AM, Alex Lorenz via cfe-commits >> wrote: >> > Author: arphaman >> > Date: Fri Jul 28 07:41:21 2017 >> > New Revision: 309386 >> > >> > URL: http://llvm.org/viewvc/llvm-project?rev=309386&view=rev >> > Log: >> > Recommit r308327 3rd time: Add a warning for missing >> > '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included >> files >> > >> > The second recommit (r309106) was reverted because the "non-default >> #pragma >> > pack value chages the alignment of struct or union members in the >> included file" >> > warning proved to be too aggressive for external projects like Chromium >> > (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This >> recommit >> > makes the problematic warning a non-default one, and gives it the >> > -Wpragma-pack-suspicious-include warning option. >> > >> > The first recommit (r308441) caused a "non-default #pragma pack value >> might >> > change the alignment of struct or union members in the included file" >> warning >> > in LLVM itself. This recommit tweaks the added warning to avoid >> warnings for >> > #includes that don't have any records that are affected by the >> non-default >> > alignment. This tweak avoids the previously emitted warning in LLVM. >> > >> > Original message: >> > >> > This commit adds a new -Wpragma-pack warning. It warns in the following >> cases: >> > >> > - When a translation unit is missing terminating #pragma pack (pop) >> directives. >> > - When entering an included file if the current alignment value as >> determined >> > by '#pragma pack' directives is different from the default alignment >> value. >> > - When leaving an included file that changed the state of the current >> alignment >> > value. >> > >> > rdar://10184173 >> > >> > Differential Revision: https://reviews.llvm.org/D35484 >> >> We did get warnings with this version too, but this time it looks like >> a real bug :-) >> >> C:\b\c\builder\ClangToTWin_dll_\src\third_party\usrsctp\usrs >> ctplib\usrsctplib\netinet\sctp.h(51,9): >> error: unterminated '#pragma pack (push, ...)' at end of file >> [-Werror,-Wpragma-pack] >> >> The interesting thing is that the file does reset the alignment, but >> it does it with a "#pragma pack()" which doesn't pop the stack, but >> just resets to the default value. >> >> It might be worth tweaking the warning to give a better message for >> this. A "#pragma pack(push, ..)" followed by "#pragma pack()" seems >> pretty dodgy since there's no point in pushing if the code isn't going >> to pop. >> > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r308722 - Fixed failing assert in code completion.
Ping?
On 21 July 2017 at 10:44, Alex L wrote:
> Hans, can you please merge this to the LLVM 5.0 branch?
>
> AFAIK It's a recent regression that should get fixed in LLVM 5.0.
>
> Cheers,
> Alex
>
>
> On 21 July 2017 at 10:24, Ilya Biryukov via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: ibiryukov
>> Date: Fri Jul 21 02:24:00 2017
>> New Revision: 308722
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=308722&view=rev
>> Log:
>> Fixed failing assert in code completion.
>>
>> Summary:
>> The code was accessing uninstantiated default argument.
>> This resulted in failing assertion at ParmVarDecl::getDefaultArg().
>>
>> Reviewers: erikjv, klimek, bkramer, krasimir
>>
>> Reviewed By: krasimir
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D35682
>>
>> Added:
>> cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp
>> Modified:
>> cfe/trunk/lib/Sema/SemaCodeComplete.cpp
>>
>> Modified: cfe/trunk/lib/Sema/SemaCodeComplete.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaC
>> odeComplete.cpp?rev=308722&r1=308721&r2=308722&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Sema/SemaCodeComplete.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaCodeComplete.cpp Fri Jul 21 02:24:00 2017
>> @@ -2401,10 +2401,7 @@ formatBlockPlaceholder(const PrintingPol
>> static std::string GetDefaultValueString(const ParmVarDecl *Param,
>> const SourceManager &SM,
>> const LangOptions &LangOpts) {
>> - const Expr *defaultArg = Param->getDefaultArg();
>> - if (!defaultArg)
>> -return "";
>> - const SourceRange SrcRange = defaultArg->getSourceRange();
>> + const SourceRange SrcRange = Param->getDefaultArgRange();
>>CharSourceRange CharSrcRange = CharSourceRange::getTokenRange
>> (SrcRange);
>>bool Invalid = CharSrcRange.isInvalid();
>>if (Invalid)
>>
>> Added: cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeCompl
>> etion/uninstantiated_params.cpp?rev=308722&view=auto
>>
>> ==
>> --- cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp (added)
>> +++ cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp Fri Jul 21
>> 02:24:00 2017
>> @@ -0,0 +1,13 @@
>> +template
>> +struct unique_ptr {
>> + typedef T* pointer;
>> +
>> + void reset(pointer ptr = pointer());
>> +};
>> +
>> +void test() {
>> + unique_ptr x;
>> + x.
>> + // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:10:5 %s -o - |
>> FileCheck -check-prefix=CHECK-CC1 %s
>> + // CHECK-CC1: [#void#]reset({#<#unique_ptr::pointer ptr =
>> pointer()#>#})
>> +}
>>
>>
>> ___
>> 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: r310706 - [modules] Set the lexical DC for dummy tag decls that refer to hidden
Hi Hans & Richard,
Is it possible to get this merged into LLVM 5.0?
Cheers,
Alex
On 11 August 2017 at 13:06, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Fri Aug 11 05:06:52 2017
> New Revision: 310706
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310706&view=rev
> Log:
> [modules] Set the lexical DC for dummy tag decls that refer to hidden
> declarations that are made visible after the dummy is parsed and ODR
> verified
>
> Prior to this commit the
> "(getContainingDC(DC) == CurContext && "The next DeclContext should be
> lexically contained in the current one."),"
> assertion failure was triggered during semantic analysis of the dummy
> tag declaration that was declared in another tag declaration because its
> lexical context did not point to the outer tag decl.
>
> rdar://32292196
>
> Added:
> cfe/trunk/test/Modules/Inputs/innerstructredef.h
> cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
> Modified:
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/test/Modules/Inputs/module.map
>
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaDecl.cpp?rev=310706&r1=310705&r2=310706&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Aug 11 05:06:52 2017
> @@ -13722,6 +13722,7 @@ Decl *Sema::ActOnTag(Scope *S, unsigned
>// comparison.
>SkipBody->CheckSameAsPrevious = true;
>SkipBody->New = createTagFromNewDecl();
> + SkipBody->New->setLexicalDeclContext(CurContext);
>SkipBody->Previous = Hidden;
> } else {
>SkipBody->ShouldSkip = true;
>
> Added: cfe/trunk/test/Modules/Inputs/innerstructredef.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/
> innerstructredef.h?rev=310706&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/innerstructredef.h (added)
> +++ cfe/trunk/test/Modules/Inputs/innerstructredef.h Fri Aug 11 05:06:52
> 2017
> @@ -0,0 +1,6 @@
> +struct Outer {
> +// This definition is actually hidden since only submodule 'one' is
> imported.
> +struct Inner {
> + int x;
> +} field;
> +};
>
> Modified: cfe/trunk/test/Modules/Inputs/module.map
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/Inputs/module.map?rev=310706&r1=310705&r2=310706&view=diff
>
> ==
> --- cfe/trunk/test/Modules/Inputs/module.map (original)
> +++ cfe/trunk/test/Modules/Inputs/module.map Fri Aug 11 05:06:52 2017
> @@ -451,3 +451,12 @@ module DebugNestedB {
> module objcAtKeywordMissingEnd {
>header "objcAtKeywordMissingEnd.h"
> }
> +
> +module innerstructredef {
> + module one {
> +header "empty.h"
> + }
> + module two {
> + header "innerstructredef.h"
> + }
> +}
>
> Added: cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/inner-struct-redefines-invisible.m?rev=310706&view=auto
>
> ==
> --- cfe/trunk/test/Modules/inner-struct-redefines-invisible.m (added)
> +++ cfe/trunk/test/Modules/inner-struct-redefines-invisible.m Fri Aug 11
> 05:06:52 2017
> @@ -0,0 +1,12 @@
> +// RUN: rm -rf %t
> +// RUN: %clang_cc1 -fsyntax-only -I%S/Inputs -fmodules
> -fimplicit-module-maps -fmodules-cache-path=%t -verify %s
> +// expected-no-diagnostics
> +
> +@import innerstructredef.one;
> +
> +struct Outer {
> +// Should set lexical context when parsing 'Inner' here, otherwise
> there's a crash:
> +struct Inner {
> + int x;
> +} field;
> +};
>
>
> ___
> 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: r310706 - [modules] Set the lexical DC for dummy tag decls that refer to hidden
Sure, I committed r310829 which moves the lexical decl adjustment.
Hans, can you please merge r310706 with r310829.
Cheers,
Alex
On 12 August 2017 at 01:29, Richard Smith wrote:
> On 11 August 2017 at 17:20, Bruno Cardoso Lopes via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Alex,
>>
>> On Fri, Aug 11, 2017 at 9:06 AM, Alex Lorenz via cfe-commits
>> wrote:
>> > Author: arphaman
>> > Date: Fri Aug 11 05:06:52 2017
>> > New Revision: 310706
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=310706&view=rev
>> > Log:
>> > [modules] Set the lexical DC for dummy tag decls that refer to hidden
>> > declarations that are made visible after the dummy is parsed and ODR
>> verified
>> >
>> > Prior to this commit the
>> > "(getContainingDC(DC) == CurContext && "The next DeclContext should be
>> lexically contained in the current one."),"
>> > assertion failure was triggered during semantic analysis of the dummy
>> > tag declaration that was declared in another tag declaration because its
>> > lexical context did not point to the outer tag decl.
>> >
>> > rdar://32292196
>> >
>> > Added:
>> > cfe/trunk/test/Modules/Inputs/innerstructredef.h
>> > cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
>> > Modified:
>> > cfe/trunk/lib/Sema/SemaDecl.cpp
>> > cfe/trunk/test/Modules/Inputs/module.map
>> >
>> > Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
>> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaD
>> ecl.cpp?rev=310706&r1=310705&r2=310706&view=diff
>> >
>> ==
>> > --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>> > +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Aug 11 05:06:52 2017
>> > @@ -13722,6 +13722,7 @@ Decl *Sema::ActOnTag(Scope *S, unsigned
>> >// comparison.
>> >SkipBody->CheckSameAsPrevious = true;
>> >SkipBody->New = createTagFromNewDecl();
>> > + SkipBody->New->setLexicalDeclContext(CurContext);
>>
>> I think it would be cleaner to do this inside "createTagFromNewDecl" than
>> here.
>
>
> I agree. Either before or after that change, this seems sufficiently
> isolated and low-risk that it makes sense to take it for Clang 5.
>
>
>> >SkipBody->Previous = Hidden;
>> > } else {
>> >SkipBody->ShouldSkip = true;
>> >
>> > Added: cfe/trunk/test/Modules/Inputs/innerstructredef.h
>> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/
>> Inputs/innerstructredef.h?rev=310706&view=auto
>> >
>> ==
>> > --- cfe/trunk/test/Modules/Inputs/innerstructredef.h (added)
>> > +++ cfe/trunk/test/Modules/Inputs/innerstructredef.h Fri Aug 11
>> 05:06:52 2017
>> > @@ -0,0 +1,6 @@
>> > +struct Outer {
>> > +// This definition is actually hidden since only submodule 'one' is
>> imported.
>> > +struct Inner {
>> > + int x;
>> > +} field;
>> > +};
>> >
>> > Modified: cfe/trunk/test/Modules/Inputs/module.map
>> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/
>> Inputs/module.map?rev=310706&r1=310705&r2=310706&view=diff
>> >
>> ==
>> > --- cfe/trunk/test/Modules/Inputs/module.map (original)
>> > +++ cfe/trunk/test/Modules/Inputs/module.map Fri Aug 11 05:06:52 2017
>> > @@ -451,3 +451,12 @@ module DebugNestedB {
>> > module objcAtKeywordMissingEnd {
>> >header "objcAtKeywordMissingEnd.h"
>> > }
>> > +
>> > +module innerstructredef {
>> > + module one {
>> > +header "empty.h"
>> > + }
>> > + module two {
>> > + header "innerstructredef.h"
>> > + }
>> > +}
>> >
>> > Added: cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
>> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/
>> inner-struct-redefines-invisible.m?rev=310706&view=auto
>> >
>> ==
>> > --- cfe/trunk/test/Modules/inner-struct-redefines-invisible.m (added)
>> > +++ cfe/trunk/test/Modules/inner-struct-redefines-invisible.m Fri Aug
>> 11 05:06:52 2017
>> > @@ -0,0 +1,12 @@
>> > +// RUN: rm -rf %t
>> > +// RUN: %clang_cc1 -fsyntax-only -I%S/Inputs -fmodules
>> -fimplicit-module-maps -fmodules-cache-path=%t -verify %s
>> > +// expected-no-diagnostics
>> > +
>> > +@import innerstructredef.one;
>> > +
>> > +struct Outer {
>> > +// Should set lexical context when parsing 'Inner' here, otherwise
>> there's a crash:
>> > +struct Inner {
>> > + int x;
>> > +} field;
>> > +};
>> >
>> >
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>>
>> --
>> Bruno Cardoso Lopes
>> http://www.brunocardoso.cc
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.l
Re: r310853 - [rename] Introduce symbol occurrences
It's an NFC, thus untested.
On 14 August 2017 at 17:19, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Mon Aug 14 09:19:24 2017
> New Revision: 310853
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310853&view=rev
> Log:
> [rename] Introduce symbol occurrences
>
> Symbol occurrences store the results of local rename and will also be used
> for
> the global, indexed rename results. Their kind is used to determine
> whether they
> should be renamed automatically or not. They can be converted to a set of
> AtomicChanges as well.
>
> Differential Revision: https://reviews.llvm.org/D36156
>
> Added:
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h
> cfe/trunk/lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
> Modified:
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/USRLocFinder.h
> cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
> cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
> cfe/trunk/lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
>
> Modified: cfe/trunk/include/clang/Tooling/Refactoring/Rename/
> RenamingAction.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/RenamingAction.h?rev=
> 310853&r1=310852&r2=310853&view=diff
>
> ==
> --- cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> (original)
> +++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> Mon Aug 14 09:19:24 2017
> @@ -16,6 +16,9 @@
> #define LLVM_CLANG_TOOLING_REFACTOR_RENAME_RENAMING_ACTION_H
>
> #include "clang/Tooling/Refactoring.h"
> +#include "clang/Tooling/Refactoring/AtomicChange.h"
> +#include "clang/Tooling/Refactoring/Rename/SymbolOccurrences.h"
> +#include "llvm/Support/Error.h"
>
> namespace clang {
> class ASTConsumer;
> @@ -42,6 +45,13 @@ private:
>bool PrintLocations;
> };
>
> +/// Returns source replacements that correspond to the rename of the given
> +/// symbol occurrences.
> +llvm::Expected>
> +createRenameReplacements(const SymbolOccurrences &Occurrences,
> + const SourceManager &SM,
> + ArrayRef NewNameStrings);
> +
> /// Rename all symbols identified by the given USRs.
> class QualifiedRenamingAction {
> public:
>
> Added: cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/SymbolName.h?rev=310853&view=auto
>
> ==
> --- cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> (added)
> +++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h Mon
> Aug 14 09:19:24 2017
> @@ -0,0 +1,49 @@
> +//===--- SymbolName.h - Clang refactoring library
> -===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===--
> ===//
> +
> +#ifndef LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
> +#define LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
> +
> +#include "clang/Basic/LLVM.h"
> +#include "llvm/ADT/ArrayRef.h"
> +#include "llvm/ADT/SmallVector.h"
> +#include "llvm/ADT/StringRef.h"
> +
> +namespace clang {
> +namespace tooling {
> +
> +/// A name of a symbol.
> +///
> +/// Symbol's name can be composed of multiple strings. For example,
> Objective-C
> +/// methods can contain multiple argument lables:
> +///
> +/// \code
> +/// - (void) myMethodNamePiece: (int)x anotherNamePieces:(int)y;
> +/// // ^~ string 0 ~ ^~ string 1 ~
> +/// \endcode
> +class SymbolName {
> +public:
> + SymbolName(StringRef Name) {
> +// While empty symbol names are valid (Objective-C selectors can have
> empty
> +// name pieces), occurrences Objective-C selectors are created using
> an
> +// array of strings instead of just one string.
> +assert(!Name.empty() && "Invalid symbol name!");
> +this->Name.push_back(Name.str());
> + }
> +
> + ArrayRef getNamePieces() const { return Name; }
> +
> +private:
> + llvm::SmallVector Name;
> +};
> +
> +} // end namespace tooling
> +} // end namespace clang
> +
> +#endif // LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
>
> Added: cfe/trunk/include/clang/Tooling/Refactoring/Rename/
> SymbolOccurrences.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/SymbolOccurrences.h?rev=310853&view=auto
>
> ==
> --- cfe/trunk/include/clang/T
Re: r311443 - [ObjC] Check written attributes only when synthesizing ambiguous property
Hi Hans,
Can you please merge this into LLVM 5? It fixes a rather serious
Objective-C bug that I introduced just a couple of weeks before the branch.
Cheers,
Alex
On 22 August 2017 at 11:38, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Tue Aug 22 03:38:07 2017
> New Revision: 311443
>
> URL: http://llvm.org/viewvc/llvm-project?rev=311443&view=rev
> Log:
> [ObjC] Check written attributes only when synthesizing ambiguous property
>
> This commit fixes a bug introduced in r307903. The attribute ambiguity
> checker
> that was introduced in r307903 checked all property attributes, which
> caused
> errors for source-compatible properties, like:
>
> @property (nonatomic, readonly) NSObject *prop;
> @property (nonatomic, readwrite) NSObject *prop;
>
> because the readwrite property would get implicit 'strong' attribute. The
> ambiguity checker should be concerned about explicitly specified attributes
> only.
>
> rdar://33748089
>
> Modified:
> cfe/trunk/lib/Sema/SemaObjCProperty.cpp
> cfe/trunk/test/SemaObjC/arc-property-decl-attrs.m
>
> Modified: cfe/trunk/lib/Sema/SemaObjCProperty.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaO
> bjCProperty.cpp?rev=311443&r1=311442&r2=311443&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaObjCProperty.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaObjCProperty.cpp Tue Aug 22 03:38:07 2017
> @@ -872,7 +872,7 @@ SelectPropertyForSynthesisFromProtocols(
>}
>
>QualType RHSType = S.Context.getCanonicalType(Property->getType());
> - unsigned OriginalAttributes = Property->getPropertyAttributes();
> + unsigned OriginalAttributes = Property->getPropertyAttribute
> sAsWritten();
>enum MismatchKind {
> IncompatibleType = 0,
> HasNoExpectedAttribute,
> @@ -890,7 +890,7 @@ SelectPropertyForSynthesisFromProtocols(
>SmallVector Mismatches;
>for (ObjCPropertyDecl *Prop : Properties) {
> // Verify the property attributes.
> -unsigned Attr = Prop->getPropertyAttributes();
> +unsigned Attr = Prop->getPropertyAttributesAsWritten();
> if (Attr != OriginalAttributes) {
>auto Diag = [&](bool OriginalHasAttribute, StringRef AttributeName)
> {
> MismatchKind Kind = OriginalHasAttribute ? HasNoExpectedAttribute
>
> Modified: cfe/trunk/test/SemaObjC/arc-property-decl-attrs.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/
> arc-property-decl-attrs.m?rev=311443&r1=311442&r2=311443&view=diff
>
> ==
> --- cfe/trunk/test/SemaObjC/arc-property-decl-attrs.m (original)
> +++ cfe/trunk/test/SemaObjC/arc-property-decl-attrs.m Tue Aug 22 03:38:07
> 2017
> @@ -225,3 +225,30 @@ __attribute__((objc_root_class))
> @implementation TypeVsSetter
> @synthesize prop; // expected-note {{property synthesized here}}
> @end
> +
> +@protocol AutoStrongProp
> +
> +@property (nonatomic, readonly) NSObject *prop;
> +
> +@end
> +
> +@protocol AutoStrongProp_Internal
> +
> +// This property gets the 'strong' attribute automatically.
> +@property (nonatomic, readwrite) NSObject *prop;
> +
> +@end
> +
> +@interface SynthesizeWithImplicitStrongNoError : NSObject
>
> +@end
> +
> +@interface SynthesizeWithImplicitStrongNoError ()
>
> +
> +@end
> +
> +@implementation SynthesizeWithImplicitStrongNoError
> +
> +// no error, 'strong' is implicit in the 'readwrite' property.
> +@synthesize prop = _prop;
> +
> +@end
>
>
> ___
> 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: r284549 - DR1330: instantiate exception-specifications when "needed". We previously did
Hi Richard,
It looks like this commit caused PR34298 (https://bugs.llvm.org/show_bu
g.cgi?id=34298). Now Clang fails to compile a libc++ std::function member
variable with an incomplete return type. Libstdc++ works though, so I
assume that the right way to fix this is to change libc++?
Cheers,
Alex
On 19 October 2016 at 00:39, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Tue Oct 18 18:39:12 2016
> New Revision: 284549
>
> URL: http://llvm.org/viewvc/llvm-project?rev=284549&view=rev
> Log:
> DR1330: instantiate exception-specifications when "needed". We previously
> did
> not instantiate exception specifications of functions if they were only
> used in
> unevaluated contexts (other than 'noexcept' expressions).
>
> In C++17 onwards, this becomes essential since the exception specification
> is
> now part of the function's type.
>
> Note that this means that constructs like the following no longer work:
>
> struct A {
> static T f() noexcept(...);
> decltype(f()) *p;
> };
>
> ... because the decltype expression now needs the exception specification
> of
> 'f', which has not yet been parsed.
>
> Modified:
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaOverload.cpp
> cfe/trunk/test/CXX/drs/dr13xx.cpp
> cfe/trunk/test/SemaCXX/constant-expression-cxx1z.cpp
> cfe/trunk/test/SemaCXX/cxx0x-defaulted-functions.cpp
> cfe/trunk/test/SemaCXX/libstdcxx_pair_swap_hack.cpp
> cfe/trunk/test/SemaTemplate/instantiate-exception-spec-cxx11.cpp
> cfe/trunk/www/cxx_dr_status.html
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaExpr.cpp?rev=284549&r1=284548&r2=284549&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Tue Oct 18 18:39:12 2016
> @@ -2889,6 +2889,14 @@ ExprResult Sema::BuildDeclarationNameExp
>
>{
> QualType type = VD->getType();
> +if (auto *FPT = type->getAs()) {
> + // C++ [except.spec]p17:
> + // An exception-specification is considered to be needed when:
> + // - in an expression, the function is the unique lookup result or
> + // the selected member of a set of overloaded functions.
> + ResolveExceptionSpec(Loc, FPT);
> + type = VD->getType();
> +}
> ExprValueKind valueKind = VK_RValue;
>
> switch (D->getKind()) {
> @@ -13138,6 +13146,19 @@ void Sema::MarkFunctionReferenced(Source
> Func->getMemberSpecializationInfo()))
> checkSpecializationVisibility(Loc, Func);
>
> + // C++14 [except.spec]p17:
> + // An exception-specification is considered to be needed when:
> + // - the function is odr-used or, if it appears in an unevaluated
> operand,
> + // would be odr-used if the expression were potentially-evaluated;
> + //
> + // Note, we do this even if MightBeOdrUse is false. That indicates that
> the
> + // function is a pure virtual function we're calling, and in that case
> the
> + // function was selected by overload resolution and we need to resolve
> its
> + // exception specification for a different reason.
> + const FunctionProtoType *FPT = Func->getType()->getAs<
> FunctionProtoType>();
> + if (FPT && isUnresolvedExceptionSpec(FPT->getExceptionSpecType()))
> +ResolveExceptionSpec(Loc, FPT);
> +
>// If we don't need to mark the function as used, and we don't need to
>// try to provide a definition, there's nothing more to do.
>if ((Func->isUsed(/*CheckUsedAttr=*/false) || !OdrUse) &&
> @@ -13196,12 +13217,6 @@ void Sema::MarkFunctionReferenced(Source
>// FIXME: Is this really right?
>if (CurContext == Func) return;
>
> - // Resolve the exception specification for any function which is
> - // used: CodeGen will need it.
> - const FunctionProtoType *FPT = Func->getType()->getAs<
> FunctionProtoType>();
> - if (FPT && isUnresolvedExceptionSpec(FPT->getExceptionSpecType()))
> -ResolveExceptionSpec(Loc, FPT);
> -
>// Implicit instantiation of function templates and member functions of
>// class templates.
>if (Func->isImplicitlyInstantiable()) {
>
> Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaOverload.cpp?rev=284549&r1=284548&r2=284549&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue Oct 18 18:39:12 2016
> @@ -13166,6 +13166,13 @@ Expr *Sema::FixOverloadedFunctionReferen
> UnOp->getOperatorLoc());
>}
>
> + // C++ [except.spec]p17:
> + // An exception-specification is considered to be needed when:
> + // - in an expression the function is the unique lookup result or the
> + // selected member of a set of overl
Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it
Hi Richard,
I posted a patch that partially reverts your commit:
https://reviews.llvm.org/D72411. Unfortunately I can't revert it fully.
Thanks,
Alex
On Mon, 11 Nov 2019 at 15:30, Alex L wrote:
> Here's a reduced test case.
>
> ```
> // OPTIONS: -x objective-c -std=gnu99 -fobjc-arc -emit-llvm
> @interface Foo
> @end
>
> Foo *foo() {
> static Foo *f = ((void*)0;
> return f;
> }
> // CHECK-NOT: cxa_guard
> ```
>
> AFAIK clang should not emit C++ guard variables in non-C++ code. Is that
> correct?
>
> On Mon, 11 Nov 2019 at 14:16, Alex L wrote:
>
>> Hi Richard,
>>
>> I have a question about this commit. It looks like it started emitting
>> `cxa_guard_acquire/release` calls in Objective-C code, for globals with
>> constant initializers, causing link failures for things that don't link
>> with libc++abi. Was that intentional? I'm still working on a reduced
>> test-case that I can post.
>>
>> Thanks,
>> Alex
>>
>> On Sat, 28 Sep 2019 at 22:06, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Sat Sep 28 22:08:46 2019
>>> New Revision: 373159
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=373159&view=rev
>>> Log:
>>> For P0784R7: compute whether a variable has constant destruction if it
>>> has a constexpr destructor.
>>>
>>> For constexpr variables, reject if the variable does not have constant
>>> destruction. In all cases, do not emit runtime calls to the destructor
>>> for variables with constant destruction.
>>>
>>> Added:
>>> cfe/trunk/test/CXX/expr/expr.const/p6-2a.cpp
>>> cfe/trunk/test/CodeGenCXX/non-const-init-cxx2a.cpp
>>> Modified:
>>> cfe/trunk/include/clang/AST/Decl.h
>>> cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
>>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>> cfe/trunk/lib/AST/ASTContext.cpp
>>> cfe/trunk/lib/AST/Decl.cpp
>>> cfe/trunk/lib/AST/ExprConstant.cpp
>>> cfe/trunk/lib/AST/Interp/Interp.cpp
>>> cfe/trunk/lib/AST/TextNodeDumper.cpp
>>> cfe/trunk/lib/CodeGen/CGCall.cpp
>>> cfe/trunk/lib/CodeGen/CGClass.cpp
>>> cfe/trunk/lib/CodeGen/CGDecl.cpp
>>> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>>> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>>> cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p9.cpp
>>> cfe/trunk/test/CodeGenCXX/attr-no-destroy-d54344.cpp
>>> cfe/trunk/test/CodeGenCXX/const-init-cxx2a.cpp
>>> cfe/trunk/test/CodeGenCXX/no_destroy.cpp
>>>
>>> Modified: cfe/trunk/include/clang/AST/Decl.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=373159&r1=373158&r2=373159&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/AST/Decl.h (original)
>>> +++ cfe/trunk/include/clang/AST/Decl.h Sat Sep 28 22:08:46 2019
>>> @@ -808,12 +808,19 @@ struct EvaluatedStmt {
>>>/// valid if CheckedICE is true.
>>>bool IsICE : 1;
>>>
>>> + /// Whether this variable is known to have constant destruction. That
>>> is,
>>> + /// whether running the destructor on the initial value is a
>>> side-effect
>>> + /// (and doesn't inspect any state that might have changed during
>>> program
>>> + /// execution). This is currently only computed if the destructor is
>>> + /// non-trivial.
>>> + bool HasConstantDestruction : 1;
>>> +
>>>Stmt *Value;
>>>APValue Evaluated;
>>>
>>> - EvaluatedStmt() : WasEvaluated(false), IsEvaluating(false),
>>> CheckedICE(false),
>>> -CheckingICE(false), IsICE(false) {}
>>> -
>>> + EvaluatedStmt()
>>> + : WasEvaluated(false), IsEvaluating(false), CheckedICE(false),
>>> +CheckingICE(false), IsICE(false), HasConstantDestruction(false)
>>> {}
>>> };
>>>
>>> /// Represents a variable declaration or definition.
>>> @@ -1267,6 +1274,14 @@ public:
>>>/// to untyped APValue if the value could not be evaluated.
>>>APValue *getEvaluatedValue() const;
>>>
>>> + /// Evaluate the destruction of this variable to determine if it
>>> constitutes
>>> + /// constant destruction.
>>> + ///
>>> + /// \pre isInitICE()
>>> + /// \return \c true if this variable has constant destruction, \c
>>> false if
>>> + /// not.
>>> + bool evaluateDestruction(SmallVectorImpl &Notes)
>>> const;
>>> +
>>>/// Determines whether it is already known whether the
>>>/// initializer is an integral constant expression or not.
>>>bool isInitKnownICE() const;
>>> @@ -1505,9 +1520,14 @@ public:
>>>// has no definition within this source file.
>>>bool isKnownToBeDefined() const;
>>>
>>> - /// Do we need to emit an exit-time destructor for this variable?
>>> + /// Is destruction of this variable entirely suppressed? If so, the
>>> variable
>>> + /// need not have a usable
Re: [clang] 0e3a487 - PR12350: Handle remaining cases permitted by CWG DR 244.
Hi Rchard,
Some of our code started triggering the warning you added in this code, but
I'm not sure if the warning is actually valid or not in this case:
https://godbolt.org/z/9fxs3K
namespace geo {
template
class optional {
optional() { }
~optional();
};
}
template
geo::optional::~optional() // Triggers ISO C++ requires the name after
'::~' to be found in the same scope as the name before '::~'
{
}
Could you confirm whether or not this warning is valid for our code?
Thanks,
Alex
On Thu, 13 Feb 2020 at 00:52, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Thanks, yes, fixed in llvmorg-11-init-3043-gc1394afb8df.
>
> On Thu, 13 Feb 2020 at 02:58, Kostya Serebryany via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Could this have caused a new ubsan failure?
>>
>> clang/lib/AST/NestedNameSpecifier.cpp:485:23: runtime error: null pointer
>> passed as argument 2, which is declared to never be null
>>
>>
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/38698/steps/check-clang%20ubsan/logs/stdio
>>
>> On Fri, Feb 7, 2020 at 6:41 PM Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> Author: Richard Smith
>>> Date: 2020-02-07T18:40:41-08:00
>>> New Revision: 0e3a48778408b505946e465abf5c77a2ddd4918c
>>>
>>> URL:
>>> https://github.com/llvm/llvm-project/commit/0e3a48778408b505946e465abf5c77a2ddd4918c
>>> DIFF:
>>> https://github.com/llvm/llvm-project/commit/0e3a48778408b505946e465abf5c77a2ddd4918c.diff
>>>
>>> LOG: PR12350: Handle remaining cases permitted by CWG DR 244.
>>>
>>> Also add extension warnings for the cases that are disallowed by the
>>> current rules for destructor name lookup, refactor and simplify the
>>> lookup code, and improve the diagnostic quality when lookup fails.
>>>
>>> The special case we previously supported for converting
>>> p->N::S::~S() from naming a class template into naming a
>>> specialization thereof is subsumed by a more general rule here (which is
>>> also consistent with Clang's historical behavior and that of other
>>> compilers): if we can't find a suitable S in N, also look in N::S.
>>>
>>> The extension warnings are off by default, except for a warning when
>>> lookup for p->N::S::~T() looks for T in scope instead of in N (or N::S).
>>> That seems sufficiently heinous to warn on by default, especially since
>>> we can't support it for a dependent nested-name-specifier.
>>>
>>> Added:
>>>
>>>
>>> Modified:
>>> clang/include/clang/Basic/DiagnosticGroups.td
>>> clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> clang/lib/AST/NestedNameSpecifier.cpp
>>> clang/lib/Sema/DeclSpec.cpp
>>> clang/lib/Sema/SemaExprCXX.cpp
>>> clang/test/CXX/class/class.mem/p13.cpp
>>> clang/test/CXX/drs/dr2xx.cpp
>>> clang/test/CXX/drs/dr3xx.cpp
>>> clang/test/FixIt/fixit.cpp
>>> clang/test/Parser/cxx-decl.cpp
>>> clang/test/SemaCXX/constructor.cpp
>>> clang/test/SemaCXX/destructor.cpp
>>> clang/test/SemaCXX/pseudo-destructors.cpp
>>>
>>> Removed:
>>>
>>>
>>>
>>>
>>>
>>> diff --git a/clang/include/clang/Basic/DiagnosticGroups.td
>>> b/clang/include/clang/Basic/DiagnosticGroups.td
>>> index a2bc29986a07..8c54723cdbab 100644
>>> --- a/clang/include/clang/Basic/DiagnosticGroups.td
>>> +++ b/clang/include/clang/Basic/DiagnosticGroups.td
>>> @@ -192,6 +192,7 @@ def CXX2aDesignator : DiagGroup<"c++2a-designator">;
>>> // designators (including the warning controlled by -Wc++2a-designator).
>>> def C99Designator : DiagGroup<"c99-designator", [CXX2aDesignator]>;
>>> def GNUDesignator : DiagGroup<"gnu-designator">;
>>> +def DtorName : DiagGroup<"dtor-name">;
>>>
>>> def DynamicExceptionSpec
>>> : DiagGroup<"dynamic-exception-spec",
>>> [DeprecatedDynamicExceptionSpec]>;
>>>
>>> diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> b/clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> index 9de60d3a8d27..82861f0d5d72 100644
>>> --- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> +++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> @@ -1911,17 +1911,33 @@ def err_destructor_with_params :
>>> Error<"destructor cannot have any parameters">;
>>> def err_destructor_variadic : Error<"destructor cannot be variadic">;
>>> def err_destructor_typedef_name : Error<
>>>"destructor cannot be declared using a %select{typedef|type alias}1
>>> %0 of the class name">;
>>> +def err_undeclared_destructor_name : Error<
>>> + "undeclared identifier %0 in destructor name">;
>>> def err_destructor_name : Error<
>>>"expected the class name after '~' to name the enclosing class">;
>>> -def err_destructor_class_name : Error<
>>> - "expected the class name after '~' to name a destructor">;
>>> -def err_ident_in_dtor_not_a_type : Error<
>>> +def err_destructor_name_nontype : Error<
>>> + "identifier %0 after '~' in destructor name does not name a type">;
>>>
Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it
Hi Richard,
I have a question about this commit. It looks like it started emitting
`cxa_guard_acquire/release` calls in Objective-C code, for globals with
constant initializers, causing link failures for things that don't link
with libc++abi. Was that intentional? I'm still working on a reduced
test-case that I can post.
Thanks,
Alex
On Sat, 28 Sep 2019 at 22:06, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Sat Sep 28 22:08:46 2019
> New Revision: 373159
>
> URL: http://llvm.org/viewvc/llvm-project?rev=373159&view=rev
> Log:
> For P0784R7: compute whether a variable has constant destruction if it
> has a constexpr destructor.
>
> For constexpr variables, reject if the variable does not have constant
> destruction. In all cases, do not emit runtime calls to the destructor
> for variables with constant destruction.
>
> Added:
> cfe/trunk/test/CXX/expr/expr.const/p6-2a.cpp
> cfe/trunk/test/CodeGenCXX/non-const-init-cxx2a.cpp
> Modified:
> cfe/trunk/include/clang/AST/Decl.h
> cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/AST/ASTContext.cpp
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/AST/ExprConstant.cpp
> cfe/trunk/lib/AST/Interp/Interp.cpp
> cfe/trunk/lib/AST/TextNodeDumper.cpp
> cfe/trunk/lib/CodeGen/CGCall.cpp
> cfe/trunk/lib/CodeGen/CGClass.cpp
> cfe/trunk/lib/CodeGen/CGDecl.cpp
> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
> cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p9.cpp
> cfe/trunk/test/CodeGenCXX/attr-no-destroy-d54344.cpp
> cfe/trunk/test/CodeGenCXX/const-init-cxx2a.cpp
> cfe/trunk/test/CodeGenCXX/no_destroy.cpp
>
> Modified: cfe/trunk/include/clang/AST/Decl.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=373159&r1=373158&r2=373159&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/Decl.h (original)
> +++ cfe/trunk/include/clang/AST/Decl.h Sat Sep 28 22:08:46 2019
> @@ -808,12 +808,19 @@ struct EvaluatedStmt {
>/// valid if CheckedICE is true.
>bool IsICE : 1;
>
> + /// Whether this variable is known to have constant destruction. That
> is,
> + /// whether running the destructor on the initial value is a side-effect
> + /// (and doesn't inspect any state that might have changed during
> program
> + /// execution). This is currently only computed if the destructor is
> + /// non-trivial.
> + bool HasConstantDestruction : 1;
> +
>Stmt *Value;
>APValue Evaluated;
>
> - EvaluatedStmt() : WasEvaluated(false), IsEvaluating(false),
> CheckedICE(false),
> -CheckingICE(false), IsICE(false) {}
> -
> + EvaluatedStmt()
> + : WasEvaluated(false), IsEvaluating(false), CheckedICE(false),
> +CheckingICE(false), IsICE(false), HasConstantDestruction(false) {}
> };
>
> /// Represents a variable declaration or definition.
> @@ -1267,6 +1274,14 @@ public:
>/// to untyped APValue if the value could not be evaluated.
>APValue *getEvaluatedValue() const;
>
> + /// Evaluate the destruction of this variable to determine if it
> constitutes
> + /// constant destruction.
> + ///
> + /// \pre isInitICE()
> + /// \return \c true if this variable has constant destruction, \c false
> if
> + /// not.
> + bool evaluateDestruction(SmallVectorImpl &Notes)
> const;
> +
>/// Determines whether it is already known whether the
>/// initializer is an integral constant expression or not.
>bool isInitKnownICE() const;
> @@ -1505,9 +1520,14 @@ public:
>// has no definition within this source file.
>bool isKnownToBeDefined() const;
>
> - /// Do we need to emit an exit-time destructor for this variable?
> + /// Is destruction of this variable entirely suppressed? If so, the
> variable
> + /// need not have a usable destructor at all.
>bool isNoDestroy(const ASTContext &) const;
>
> + /// Do we need to emit an exit-time destructor for this variable, and
> if so,
> + /// what kind?
> + QualType::DestructionKind needsDestruction(const ASTContext &Ctx) const;
> +
>// Implement isa/cast/dyncast/etc.
>static bool classof(const Decl *D) { return classofKind(D->getKind()); }
>static bool classofKind(Kind K) { return K >= firstVar && K <= lastVar;
> }
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td?rev=373159&r1=373158&r2=373159&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td (
Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it
Here's a reduced test case.
```
// OPTIONS: -x objective-c -std=gnu99 -fobjc-arc -emit-llvm
@interface Foo
@end
Foo *foo() {
static Foo *f = ((void*)0;
return f;
}
// CHECK-NOT: cxa_guard
```
AFAIK clang should not emit C++ guard variables in non-C++ code. Is that
correct?
On Mon, 11 Nov 2019 at 14:16, Alex L wrote:
> Hi Richard,
>
> I have a question about this commit. It looks like it started emitting
> `cxa_guard_acquire/release` calls in Objective-C code, for globals with
> constant initializers, causing link failures for things that don't link
> with libc++abi. Was that intentional? I'm still working on a reduced
> test-case that I can post.
>
> Thanks,
> Alex
>
> On Sat, 28 Sep 2019 at 22:06, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Sat Sep 28 22:08:46 2019
>> New Revision: 373159
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=373159&view=rev
>> Log:
>> For P0784R7: compute whether a variable has constant destruction if it
>> has a constexpr destructor.
>>
>> For constexpr variables, reject if the variable does not have constant
>> destruction. In all cases, do not emit runtime calls to the destructor
>> for variables with constant destruction.
>>
>> Added:
>> cfe/trunk/test/CXX/expr/expr.const/p6-2a.cpp
>> cfe/trunk/test/CodeGenCXX/non-const-init-cxx2a.cpp
>> Modified:
>> cfe/trunk/include/clang/AST/Decl.h
>> cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/lib/AST/ASTContext.cpp
>> cfe/trunk/lib/AST/Decl.cpp
>> cfe/trunk/lib/AST/ExprConstant.cpp
>> cfe/trunk/lib/AST/Interp/Interp.cpp
>> cfe/trunk/lib/AST/TextNodeDumper.cpp
>> cfe/trunk/lib/CodeGen/CGCall.cpp
>> cfe/trunk/lib/CodeGen/CGClass.cpp
>> cfe/trunk/lib/CodeGen/CGDecl.cpp
>> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>> cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p9.cpp
>> cfe/trunk/test/CodeGenCXX/attr-no-destroy-d54344.cpp
>> cfe/trunk/test/CodeGenCXX/const-init-cxx2a.cpp
>> cfe/trunk/test/CodeGenCXX/no_destroy.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/Decl.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=373159&r1=373158&r2=373159&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/Decl.h (original)
>> +++ cfe/trunk/include/clang/AST/Decl.h Sat Sep 28 22:08:46 2019
>> @@ -808,12 +808,19 @@ struct EvaluatedStmt {
>>/// valid if CheckedICE is true.
>>bool IsICE : 1;
>>
>> + /// Whether this variable is known to have constant destruction. That
>> is,
>> + /// whether running the destructor on the initial value is a
>> side-effect
>> + /// (and doesn't inspect any state that might have changed during
>> program
>> + /// execution). This is currently only computed if the destructor is
>> + /// non-trivial.
>> + bool HasConstantDestruction : 1;
>> +
>>Stmt *Value;
>>APValue Evaluated;
>>
>> - EvaluatedStmt() : WasEvaluated(false), IsEvaluating(false),
>> CheckedICE(false),
>> -CheckingICE(false), IsICE(false) {}
>> -
>> + EvaluatedStmt()
>> + : WasEvaluated(false), IsEvaluating(false), CheckedICE(false),
>> +CheckingICE(false), IsICE(false), HasConstantDestruction(false)
>> {}
>> };
>>
>> /// Represents a variable declaration or definition.
>> @@ -1267,6 +1274,14 @@ public:
>>/// to untyped APValue if the value could not be evaluated.
>>APValue *getEvaluatedValue() const;
>>
>> + /// Evaluate the destruction of this variable to determine if it
>> constitutes
>> + /// constant destruction.
>> + ///
>> + /// \pre isInitICE()
>> + /// \return \c true if this variable has constant destruction, \c
>> false if
>> + /// not.
>> + bool evaluateDestruction(SmallVectorImpl &Notes)
>> const;
>> +
>>/// Determines whether it is already known whether the
>>/// initializer is an integral constant expression or not.
>>bool isInitKnownICE() const;
>> @@ -1505,9 +1520,14 @@ public:
>>// has no definition within this source file.
>>bool isKnownToBeDefined() const;
>>
>> - /// Do we need to emit an exit-time destructor for this variable?
>> + /// Is destruction of this variable entirely suppressed? If so, the
>> variable
>> + /// need not have a usable destructor at all.
>>bool isNoDestroy(const ASTContext &) const;
>>
>> + /// Do we need to emit an exit-time destructor for this variable, and
>> if so,
>> + /// what kind?
>> + QualType::DestructionKind needsDestruction(const ASTContext &Ctx)
>> const;
>> +
>>// Implement isa/cast/dyncast/etc.
>>static bool classof(const Decl *
Re: [clang] 7342912 - [clang][IFS] Driver Pipeline: generate stubs after standard pipeline (3)
Hi Puyan,
This commit caused two Clang failures on Darwin:
Clang :: InterfaceStubs/merge-conflict-test.c
Clang :: InterfaceStubs/object-float.c
Here's the build log from out bot:
http://lab.llvm.org:8080/green/job/clang-stage1-RA/3929/console
Can you please resolve the issue with the tests?
Thanks,
Alex
On Wed, 20 Nov 2019 at 14:16, Puyan Lotfi via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Puyan Lotfi
> Date: 2019-11-20T16:22:50-05:00
> New Revision: 73429126c91c2065c6f6ef29b3eec1b7798502bb
>
> URL:
> https://github.com/llvm/llvm-project/commit/73429126c91c2065c6f6ef29b3eec1b7798502bb
> DIFF:
> https://github.com/llvm/llvm-project/commit/73429126c91c2065c6f6ef29b3eec1b7798502bb.diff
>
> LOG: [clang][IFS] Driver Pipeline: generate stubs after standard pipeline
> (3)
>
> Third Landing Attempt (dropping any linker invocation from clang driver):
>
> Up until now, clang interface stubs has replaced the standard
> PP -> C -> BE -> ASM -> LNK pipeline. With this change, it will happen in
> conjunction with it. So what when you build your code you will get an
> a.out or lib.so as well as an interface stub file.
>
> Example:
>
> clang -shared -o libfoo.so -emit-interface-stubs ...
>
> will generate both a libfoo.so and a libfoo.ifso. The .so file will
> contain the code from the standard compilation pipeline and the .ifso
> file will contain the ELF stub library.
>
> Note: For driver-test.c I've added -S in order to prevent any bot failures
> on
> bots that don't have the proper linker for their native triple. You could
> always
> specify a triple like x86_64-unknown-linux-gnu and on bots like
> x86_64-scei-ps4
> the clang driver would invoke regular ld instead of getting the error
> 'Executable "orbis-ld" doesn't exist!' but on bots like ppc64be and s390x
> you'd
> get an error "/usr/bin/ld: unrecognised emulation mode: elf_x86_64"
>
> Differential Revision: https://reviews.llvm.org/D70274
>
> Added:
> clang/test/InterfaceStubs/driver-test2.c
> clang/test/InterfaceStubs/ppc.cpp
>
> Modified:
> clang/lib/Driver/Driver.cpp
> clang/lib/Driver/ToolChains/InterfaceStubs.cpp
> clang/lib/Driver/Types.cpp
> clang/test/InterfaceStubs/driver-test.c
> clang/test/InterfaceStubs/windows.cpp
>
> Removed:
>
>
>
>
>
> diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
> index cdf4a579f431..83b5db3b2530 100644
> --- a/clang/lib/Driver/Driver.cpp
> +++ b/clang/lib/Driver/Driver.cpp
> @@ -292,10 +292,6 @@ phases::ID Driver::getFinalPhase(const DerivedArgList
> &DAL,
> (PhaseArg = DAL.getLastArg(options::OPT_emit_ast))) {
> FinalPhase = phases::Compile;
>
> - // clang interface stubs
> - } else if ((PhaseArg =
> DAL.getLastArg(options::OPT_emit_interface_stubs))) {
> -FinalPhase = phases::IfsMerge;
> -
>// -S only runs up to the backend.
>} else if ((PhaseArg = DAL.getLastArg(options::OPT_S))) {
> FinalPhase = phases::Backend;
> @@ -3502,6 +3498,68 @@ void Driver::BuildActions(Compilation &C,
> DerivedArgList &Args,
> Actions.push_back(
> C.MakeAction(MergerInputs, types::TY_Image));
>
> + if (Arg *A = Args.getLastArg(options::OPT_emit_interface_stubs)) {
> +llvm::SmallVector PhaseList;
> +if (Args.hasArg(options::OPT_c)) {
> + llvm::SmallVector
> CompilePhaseList;
> + types::getCompilationPhases(types::TY_IFS_CPP, CompilePhaseList);
> + llvm::copy_if(CompilePhaseList, std::back_inserter(PhaseList),
> +[&](phases::ID Phase) { return Phase <=
> phases::Compile; });
> +} else {
> + types::getCompilationPhases(types::TY_IFS_CPP, PhaseList);
> +}
> +
> +ActionList MergerInputs;
> +
> +for (auto &I : Inputs) {
> + types::ID InputType = I.first;
> + const Arg *InputArg = I.second;
> +
> + // Currently clang and the llvm assembler do not support generating
> symbol
> + // stubs from assembly, so we skip the input on asm files. For ifs
> files
> + // we rely on the normal pipeline setup in the pipeline setup code
> above.
> + if (InputType == types::TY_IFS || InputType == types::TY_PP_Asm ||
> + InputType == types::TY_Asm)
> +continue;
> +
> + Action *Current = C.MakeAction(*InputArg, InputType);
> +
> + for (auto Phase : PhaseList) {
> +switch (Phase) {
> +default:
> + llvm_unreachable(
> + "IFS Pipeline can only consist of Compile followed by
> IfsMerge.");
> +case phases::Compile: {
> + // Only IfsMerge (llvm-ifs) can handle .o files by looking for
> ifs
> + // files where the .o file is located. The compile action can
> not
> + // handle this.
> + if (InputType == types::TY_Object)
> +break;
> +
> + Current = C.MakeAction(Current,
> types::TY_IFS_CPP);
> + break;
> +}
> +case phase
Re: Github build status reporting
Hi Galina, Thanks for doing this! I'm curious as to how the buildbot CI communicates with Github, is the buildbot itself capable of performing the Github API requests, or do you have an external tool/script that does that? Thanks, Alex On Mon, 25 Nov 2019 at 12:59, Galina Kistanova via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Hello everyone, > > I have configured buildbot to report build statuses to github. It is > running in a pilot mode. Only the following 4 builders annotate revisions > they build for now: > > * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast > * llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast > * llvm-clang-x86_64-expensive-checks-ubuntu > * llvm-clang-x86_64-win-fast > > Please let me know if you have any questions, concerns, or see any issues. > > Thanks > > Galina > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs
On 3 April 2018 at 14:30, Chandler Carruth wrote: > On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: arphaman >> Date: Tue Apr 3 13:50:05 2018 >> New Revision: 329110 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=329110&view=rev >> Log: >> [driver][darwin] Do not infer -simulator environment for non-simulator >> SDKs >> > > I know you added a REQUIRES line to these tests, but I think there is a > much better way: > > >> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original) >> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr 3 13:50:05 2018 >> @@ -51,12 +51,21 @@ >> // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0" >> // CHECK-IPHONE: ld >> // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0" >> +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \ >> > > Instead of just running %clang, actually pass the `-target` you want to it > like we do in the below invocation and the other invocations in this file. > > We shouldn't lose driver testing on other systems as long as you can > specify the desired target. > Hi Chandler! Thanks for pointing this out! We actually can't use -target here because when -target is specified, Darwin's driver won't infer the triple's environment from the SDKROOT. So this test covers the path in the driver that won't be taken when -target is specified. You've made a good point about losing testing though. I can split out this test into the original file (with -target use) and the new tests which can't use -target and are Darwin specific to ensure we won't loose the existing coverage. I will commit a follow-up commit that does this. Cheers, Alex > > >> +// RUN: | FileCheck --check-prefix=CHECK-IPHONE-X86 %s >> +// CHECK-IPHONE-X86: clang >> +// CHECK-IPHONE-X86: "-cc1" >> +// CHECK-IPHONE-X86: -apple-ios8.0.0" >> +// CHECK-IPHONE-X86: ld >> +// CHECK-IPHONE-X86: "-iphoneos_version_min" "8.0.0" >> // >> // >> // RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk >> // RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk >> // RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -target >> x86_64-apple-darwin %s -### 2>&1 \ >> // RUN: | FileCheck --check-prefix=CHECK-SIMULATOR %s >> +// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -arch x86_64 >> %s -### 2>&1 \ >> +// RUN: | FileCheck --check-prefix=CHECK-SIMULATOR %s >> // >> // CHECK-SIMULATOR: clang >> // CHECK-SIMULATOR: "-cc1" >> @@ -74,3 +83,49 @@ >> // CHECK-MACOSX: "-triple" "x86_64-apple-macosx10.10.0" >> // CHECK-MACOSX: ld >> // CHECK-MACOSX: "-macosx_version_min" "10.10.0" >> + >> +// RUN: rm -rf %t/SDKs/WatchOS3.0.sdk >> +// RUN: mkdir -p %t/SDKs/WatchOS3.0.sdk >> +// RUN: env SDKROOT=%t/SDKs/WatchOS3.0.sdk %clang %s -### 2>&1 \ >> +// RUN: | FileCheck --check-prefix=CHECK-WATCH %s >> +// >> +// CHECK-WATCH: clang >> +// CHECK-WATCH: "-cc1" >> +// CHECK-WATCH: -apple-watchos3.0.0" >> +// CHECK-WATCH: ld >> +// CHECK-WATCH: "-watchos_version_min" "3.0.0" >> +// >> +// >> +// RUN: rm -rf %t/SDKs/WatchSimulator3.0.sdk >> +// RUN: mkdir -p %t/SDKs/WatchSimulator3.0.sdk >> +// RUN: env SDKROOT=%t/SDKs/WatchSimulator3.0.sdk %clang %s -### 2>&1 \ >> +// RUN: | FileCheck --check-prefix=CHECK-WATCH-SIMULATOR %s >> +// >> +// CHECK-WATCH-SIMULATOR: clang >> +// CHECK-WATCH-SIMULATOR: "-cc1" >> +// CHECK-WATCH-SIMULATOR: -apple-watchos3.0.0-simulator" >> +// CHECK-WATCH-SIMULATOR: ld >> +// CHECK-WATCH-SIMULATOR: "-watchos_simulator_version_min" "3.0.0" >> + >> +// RUN: rm -rf %t/SDKs/AppleTVOS10.0.sdk >> +// RUN: mkdir -p %t/SDKs/AppleTVOS10.0.sdk >> +// RUN: env SDKROOT=%t/SDKs/AppleTVOS10.0.sdk %clang %s -### 2>&1 \ >> +// RUN: | FileCheck --check-prefix=CHECK-TV %s >> +// >> +// CHECK-TV: clang >> +// CHECK-TV: "-cc1" >> +// CHECK-TV: -apple-tvos10.0.0" >> +// CHECK-TV: ld >> +// CHECK-TV: "-tvos_version_min" "10.0.0" >> +// >> +// >> +// RUN: rm -rf %t/SDKs/AppleTVSimulator10.0.sdk >> +// RUN: mkdir -p %t/SDKs/AppleTVSimulator10.0.sdk >> +// RUN: env SDKROOT=%t/SDKs/AppleTVSimulator10.0.sdk %clang %s -### >> 2>&1 \ >> +// RUN: | FileCheck --check-prefix=CHECK-TV-SIMULATOR %s >> +// >> +// CHECK-TV-SIMULATOR: clang >> +// CHECK-TV-SIMULATOR: "-cc1" >> +// CHECK-TV-SIMULATOR: -apple-tvos10.0.0-simulator" >> +// CHECK-TV-SIMULATOR: ld >> +// CHECK-TV-SIMULATOR: "-tvos_simulator_version_min" "10.0.0" >> >> >> ___ >> 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] r318327 - [clangd] Try to unbreak tests on PS4 by targeting PC explicitly
This doesn't seem like a good permanent solution (as Paul pointed out -std
will change in the future). Will you be able to avoid this in the future?
On 15 November 2017 at 11:38, Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: sammccall
> Date: Wed Nov 15 11:38:09 2017
> New Revision: 318327
>
> URL: http://llvm.org/viewvc/llvm-project?rev=318327&view=rev
> Log:
> [clangd] Try to unbreak tests on PS4 by targeting PC explicitly
>
> Modified:
> clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp
>
> Modified: clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/
> GlobalCompilationDatabase.cpp?rev=318327&r1=318326&r2=318327&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp
> (original)
> +++ clang-tools-extra/trunk/clangd/GlobalCompilationDatabase.cpp Wed Nov
> 15 11:38:09 2017
> @@ -31,7 +31,11 @@ static void addExtraFlags(tooling::Compi
> }
>
> tooling::CompileCommand getDefaultCompileCommand(PathRef File) {
> - std::vector CommandLine{"clang", "-fsyntax-only",
> File.str()};
> + // We don't specify --std because we want to infer it from the filename.
> + // We force PC because PS4 will change --std from under us.
> + // FIXME: there must be a more principled way to do this!
> + std::vector CommandLine{
> + "clang", "-fsyntax-only", "-triple=unknown-pc-unknown", File.str()};
>return tooling::CompileCommand(llvm::sys::path::parent_path(File),
> llvm::sys::path::filename(File),
> CommandLine,
> /*Output=*/"");
>
>
> ___
> 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] Add missing Decl::Kind for -print-decl-contexts
Thanks for working on this patch! I'm sorry to say but I had an earlier
patch in review that fixes this issue (https://reviews.llvm.org/D26964). I
think my patch covers all of the decl kinds that are fixed by this patch. I
plan on committing my patch today.
Alex
On 29 December 2016 at 23:35, Fangrui Song via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> ---
> lib/Frontend/ASTConsumers.cpp | 37 -
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/lib/Frontend/ASTConsumers.cpp b/lib/Frontend/ASTConsumers.cpp
> index bd2ee06d16..987b8ca398 100644
> --- a/lib/Frontend/ASTConsumers.cpp
> +++ b/lib/Frontend/ASTConsumers.cpp
> @@ -405,6 +405,22 @@ void DeclContextPrinter::PrintDeclContext(const
> DeclContext* DC,
>PrintDeclContext(DC, Indentation+2);
>break;
> }
> +case Decl::AccessSpec: {
> + Out << "\n";
> + break;
> +}
> +case Decl::ClassTemplate: {
> + Out << " " << *cast(I) << '\n';
> + break;
> +}
> +case Decl::ClassTemplateSpecialization: {
> + Out << " " << *cast<
> ClassTemplateSpecializationDecl>(I) << '\n';
> + break;
> +}
> +case Decl::ClassTemplatePartialSpecialization: {
> + Out << " " << *cast<
> ClassTemplatePartialSpecializationDecl>(I) << '\n';
> + break;
> +}
> case Decl::IndirectField: {
>IndirectFieldDecl* IFD = cast(I);
>Out << " " << *IFD << '\n';
> @@ -420,6 +436,10 @@ void DeclContextPrinter::PrintDeclContext(const
> DeclContext* DC,
>Out << " " << *FD << '\n';
>break;
> }
> +case Decl::Friend: {
> + Out << "\n";
> + break;
> +}
> case Decl::Typedef:
> case Decl::TypeAlias: {
>TypedefNameDecl* TD = cast(I);
> @@ -460,6 +480,14 @@ void DeclContextPrinter::PrintDeclContext(const
> DeclContext* DC,
>Out << "\n";
>break;
> }
> +case Decl::Using: {
> + Out << " " << *cast(I) << '\n';
> + break;
> +}
> +case Decl::UsingShadow: {
> + Out << " " << *cast(I) << '\n';
> + break;
> +}
> case Decl::UsingDirective: {
>Out << "\n";
>break;
> @@ -469,15 +497,14 @@ void DeclContextPrinter::PrintDeclContext(const
> DeclContext* DC,
>Out << " " << *NAD << '\n';
>break;
> }
> -case Decl::ClassTemplate: {
> - ClassTemplateDecl *CTD = cast(I);
> - Out << " " << *CTD << '\n';
> - break;
> -}
> case Decl::OMPThreadPrivate: {
>Out << " " << '"' << I << "\"\n";
>break;
> }
> +case Decl::VarTemplate: {
> + Out << " " << *cast(I) << '\n';
> + break;
> +}
> default:
>Out << "DeclKind: " << DK << '"' << I << "\"\n";
>llvm_unreachable("decl unhandled");
> --
> 2.11.0
>
> ___
> 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: SemaAccess bug (protected members of derived)
Hi,
Can you please add a suitable test-case? Clang's code-completion tests are
normally in test/CodeCompletion or test/Index.
Cheers,
Alex
On 21 March 2017 at 12:05, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> There are a number of users of the clang static analyser back-end for
> intelligent code completion. Irony-Mode for emacs, for example. For a while
> people have been reporting an issue with not getting completions for
> protected members of parent classes and I believe this patch solves the
> bug: simply that the arguments to IsDerivedFromInclusive were the wrong way
> around.
>
>
>
> URL: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Sema
>
> Relative URL: ^/cfe/trunk/lib/Sema
>
>
>
> Index: SemaAccess.cpp
>
> ===
>
> --- SemaAccess.cpp (revision 297956)
>
> +++ SemaAccess.cpp (working copy)
>
> @@ -823,7 +823,7 @@
>
> continue;
>
>}
>
> - switch (IsDerivedFromInclusive(InstanceContext, ECRecord)) {
>
> + switch (IsDerivedFromInclusive(ECRecord, InstanceContext)) {
>
>case AR_accessible: return AR_accessible;
>
>case AR_inaccessible: continue;
>
>case AR_dependent: OnFailure = AR_dependent; continue;
>
>
>
> Thank you.
>
> ___
> 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: FW: SemaAccess bug (protected members of derived)
Thanks, can you please attach a diff that includes both the code change and
the new test?
On 21 March 2017 at 14:18, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Sending to mailing list.
>
>
>
> *From:* Dixon Ryan (ETAS/ERS-PD2)
> *Sent:* 21 March 2017 14:18
> *To:* 'Alex L'
> *Subject:* RE: SemaAccess bug (protected members of derived)
>
>
>
> Hello, sorry this is the first time I have done this.
>
>
>
> The test case is attached. It should fail without the patch and then
> should pass with the patch.
>
>
>
>
>
> class cl
>
> {
>
> public:
>
>void myPublic(int x){ }
>
> protected:
>
>void myProtected(int y){ }
>
> };
>
>
>
> class clChild : public cl
>
> {
>
>void myPrivate(int z)
>
>{
>
> this->
>
> // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:13:13 %s
> -o - | FileCheck -check-prefix=CHECK-CC1 %s
>
> // CHECK: COMPLETION: myProtected : [#void#][#cl::#]myProtected(<#int
> y#>)
>
>}
>
> };
>
>
>
>
>
> *From:* Alex L [mailto:arpha...@gmail.com ]
> *Sent:* 21 March 2017 12:17
> *To:* Dixon Ryan (ETAS/ERS-PD2)
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: SemaAccess bug (protected members of derived)
>
>
>
> Hi,
>
>
>
> Can you please add a suitable test-case? Clang's code-completion tests are
> normally in test/CodeCompletion or test/Index.
>
>
>
> Cheers,
>
> Alex
>
>
>
> On 21 March 2017 at 12:05, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> There are a number of users of the clang static analyser back-end for
> intelligent code completion. Irony-Mode for emacs, for example. For a while
> people have been reporting an issue with not getting completions for
> protected members of parent classes and I believe this patch solves the
> bug: simply that the arguments to IsDerivedFromInclusive were the wrong way
> around.
>
>
>
> URL: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Sema
>
> Relative URL: ^/cfe/trunk/lib/Sema
>
>
>
> Index: SemaAccess.cpp
>
> ===
>
> --- SemaAccess.cpp (revision 297956)
>
> +++ SemaAccess.cpp (working copy)
>
> @@ -823,7 +823,7 @@
>
> continue;
>
>}
>
> - switch (IsDerivedFromInclusive(InstanceContext, ECRecord)) {
>
> + switch (IsDerivedFromInclusive(ECRecord, InstanceContext)) {
>
>case AR_accessible: return AR_accessible;
>
>case AR_inaccessible: continue;
>
>case AR_dependent: OnFailure = AR_dependent; continue;
>
>
>
> Thank you.
>
>
> ___
> 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: FW: SemaAccess bug (protected members of derived)
Thanks,
It looks like your solution isn't quite right as it causes Clang to accept
invalid access to protected members, e.g. as tested by
"test/CXX/class.access/class.protected/p1.cpp".
Do you think there's an alternative solution that you could use?
Alex
On 21 March 2017 at 14:48, Dixon Ryan (ETAS/ERS-PD2)
wrote:
> From path:
>
>
>
> URL: http://llvm.org/svn/llvm-project/cfe/trunk
>
> Relative URL: ^/cfe/trunk
>
>
>
> *From:* Alex L [mailto:arpha...@gmail.com]
> *Sent:* 21 March 2017 14:22
> *To:* Dixon Ryan (ETAS/ERS-PD2)
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: FW: SemaAccess bug (protected members of derived)
>
>
>
> Thanks, can you please attach a diff that includes both the code change
> and the new test?
>
>
>
> On 21 March 2017 at 14:18, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Sending to mailing list.
>
>
>
> *From:* Dixon Ryan (ETAS/ERS-PD2)
> *Sent:* 21 March 2017 14:18
> *To:* 'Alex L'
> *Subject:* RE: SemaAccess bug (protected members of derived)
>
>
>
> Hello, sorry this is the first time I have done this.
>
>
>
> The test case is attached. It should fail without the patch and then
> should pass with the patch.
>
>
>
>
>
> class cl
>
> {
>
> public:
>
>void myPublic(int x){ }
>
> protected:
>
>void myProtected(int y){ }
>
> };
>
>
>
> class clChild : public cl
>
> {
>
>void myPrivate(int z)
>
>{
>
> this->
>
> // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:13:13 %s
> -o - | FileCheck -check-prefix=CHECK-CC1 %s
>
> // CHECK: COMPLETION: myProtected : [#void#][#cl::#]myProtected(<#int
> y#>)
>
>}
>
> };
>
>
>
>
>
> *From:* Alex L [mailto:arpha...@gmail.com ]
> *Sent:* 21 March 2017 12:17
> *To:* Dixon Ryan (ETAS/ERS-PD2)
> *Cc:* cfe-commits@lists.llvm.org
> *Subject:* Re: SemaAccess bug (protected members of derived)
>
>
>
> Hi,
>
>
>
> Can you please add a suitable test-case? Clang's code-completion tests are
> normally in test/CodeCompletion or test/Index.
>
>
>
> Cheers,
>
> Alex
>
>
>
> On 21 March 2017 at 12:05, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> There are a number of users of the clang static analyser back-end for
> intelligent code completion. Irony-Mode for emacs, for example. For a while
> people have been reporting an issue with not getting completions for
> protected members of parent classes and I believe this patch solves the
> bug: simply that the arguments to IsDerivedFromInclusive were the wrong way
> around.
>
>
>
> URL: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Sema
>
> Relative URL: ^/cfe/trunk/lib/Sema
>
>
>
> Index: SemaAccess.cpp
>
> ===
>
> --- SemaAccess.cpp (revision 297956)
>
> +++ SemaAccess.cpp (working copy)
>
> @@ -823,7 +823,7 @@
>
> continue;
>
>}
>
> - switch (IsDerivedFromInclusive(InstanceContext, ECRecord)) {
>
> + switch (IsDerivedFromInclusive(ECRecord, InstanceContext)) {
>
>case AR_accessible: return AR_accessible;
>
>case AR_inaccessible: continue;
>
>case AR_dependent: OnFailure = AR_dependent; continue;
>
>
>
> Thank you.
>
>
> ___
> 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: [PATCH] D30009: Add support for '#pragma clang attribute'
On 5 April 2017 at 13:38, Duncan Exon Smith wrote: > > > > On Apr 5, 2017, at 05:13, Aaron Ballman via Phabricator < > revi...@reviews.llvm.org> wrote: > > > > aaron.ballman added inline comments. > > > > > > > > Comment at: lib/Sema/SemaAttr.cpp:578 > > +return; > > + Diag(PragmaAttributeStack.back().Loc, diag::warn_pragm_attribute_no_ > pop_eof); > > +} > > > > arphaman wrote: > >> aaron.ballman wrote: > >>> Perhaps adding a FixIt here would be a kindness? > >> Where would the fix-it point to? I think only the user will know the > location at which they meant to insert `#pragma clang attribute pop`. > > Given that it's a warning rather than an error, and our recovery > mechanism is to effectively pop the pragma at the end of the TU, I was > thinking it could be added at the end of the TU. However, you are correct > that it's probably not where the programmer needs it, > > What about at the end of the file the push is in? This is likely to be > used in header files, and it's probably unintentional if it extends past > the end of the file of the push. > Then we'd have to take into account preprocessor directives, as we'd obviously want to insert it before the '#endif'. Or if the user used `#pragma once` then the end of the file could probably work. IMHO the improvement can be done as a follow-up that improves this and other pragmas like #pragma pack. > I think we should consider the same thing for #pragma pack (although > that's a little off-topic). > > > so a FixIt likely isn't appropriate. Does that suggest the warning > should be an error instead? > > Maybe it should be an error, but I still think a fixit would be nice if we > can find a spot. > > > > > > > Repository: > > rL LLVM > > > > https://reviews.llvm.org/D30009 > > > > > > > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r299226 - [Modules][PCH] Serialize #pragma pack
Thanks Duncan!
On 15 April 2017 at 01:25, Duncan P. N. Exon Smith
wrote:
> FYI, I reverted the modules side of this in r300380. For details, see the
> commit message. TL;DR: this didn't actually make modules builds closer to
> matching non-modules builds, thanks to how submodules work; on the
> contrary, it made them diverge.
>
> > On 2017-Mar-31, at 08:36, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Author: arphaman
> > Date: Fri Mar 31 10:36:21 2017
> > New Revision: 299226
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=299226&view=rev
> > Log:
> > [Modules][PCH] Serialize #pragma pack
> >
> > This patch serializes the state of #pragma pack. It preserves the state
> of the
> > pragma from a PCH/from modules in a file that uses that PCH/those
> modules.
> >
>
> > rdar://21359084
> >
> > Differential Revision: https://reviews.llvm.org/D31241
> >
> > Added:
> >cfe/trunk/test/Modules/Inputs/pragma_pack_push.h
> >cfe/trunk/test/Modules/Inputs/pragma_pack_reset_push.h
> >cfe/trunk/test/Modules/Inputs/pragma_pack_set.h
> >cfe/trunk/test/Modules/pragma-pack.c
> >cfe/trunk/test/PCH/pragma-pack.c
> > Modified:
> >cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> >cfe/trunk/include/clang/Serialization/ASTReader.h
> >cfe/trunk/include/clang/Serialization/ASTWriter.h
> >cfe/trunk/lib/Sema/SemaAttr.cpp
> >cfe/trunk/lib/Serialization/ASTReader.cpp
> >cfe/trunk/lib/Serialization/ASTWriter.cpp
> >cfe/trunk/test/Modules/Inputs/module.map
> >
> > Modified: cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Serialization/ASTBitCodes.h?rev=299226&r1=299225&r2=299226&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Serialization/ASTBitCodes.h (original)
> > +++ cfe/trunk/include/clang/Serialization/ASTBitCodes.h Fri Mar 31
> 10:36:21 2017
> > @@ -604,6 +604,9 @@ namespace clang {
> > OPENCL_EXTENSION_DECLS = 59,
> >
> > MODULAR_CODEGEN_DECLS = 60,
> > +
> > + /// \brief Record code for \#pragma pack options.
> > + PACK_PRAGMA_OPTIONS = 61,
> > };
> >
> > /// \brief Record types used within a source manager block.
> >
> > Modified: cfe/trunk/include/clang/Serialization/ASTReader.h
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Serialization/ASTReader.h?rev=299226&r1=299225&r2=299226&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Serialization/ASTReader.h (original)
> > +++ cfe/trunk/include/clang/Serialization/ASTReader.h Fri Mar 31
> 10:36:21 2017
> > @@ -811,6 +811,17 @@ private:
> > int PragmaMSPointersToMembersState = -1;
> > SourceLocation PointersToMembersPragmaLocation;
> >
> > + /// \brief The pragma pack state.
> > + Optional PragmaPackCurrentValue;
> > + SourceLocation PragmaPackCurrentLocation;
> > + struct PragmaPackStackEntry {
> > +unsigned Value;
> > +SourceLocation Location;
> > +StringRef SlotLabel;
> > + };
> > + llvm::SmallVector PragmaPackStack;
> > + llvm::SmallVector PragmaPackStrings;
> > +
> > /// \brief The OpenCL extension settings.
> > OpenCLOptions OpenCLExtensions;
> >
> >
> > Modified: cfe/trunk/include/clang/Serialization/ASTWriter.h
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Serialization/ASTWriter.h?rev=299226&r1=299225&r2=299226&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/Serialization/ASTWriter.h (original)
> > +++ cfe/trunk/include/clang/Serialization/ASTWriter.h Fri Mar 31
> 10:36:21 2017
> > @@ -485,6 +485,7 @@ private:
> > void WriteOptimizePragmaOptions(Sema &SemaRef);
> > void WriteMSStructPragmaOptions(Sema &SemaRef);
> > void WriteMSPointersToMembersPragmaOptions(Sema &SemaRef);
> > + void WritePackPragmaOptions(Sema &SemaRef);
> > void WriteModuleFileExtension(Sema &SemaRef,
> > ModuleFileExtensionWriter &Writer);
> >
> >
> > Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaAttr.cpp?rev=299226&r1=299225&r2=299226&view=diff
> >
> ==
> > --- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
> > +++ cfe/trunk/lib/Sema/SemaAttr.cpp Fri Mar 31 10:36:21 2017
> > @@ -215,6 +215,7 @@ void Sema::PragmaStack::Act(S
> >ValueType Value) {
> > if (Action == PSK_Reset) {
> > CurrentValue = DefaultValue;
> > +CurrentPragmaLocation = PragmaLocation;
> > return;
> > }
> > if (Action & PSK_Push)
> >
> > Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/
> Serialization/ASTReader.cpp?rev=299226&r1=2992
Re: r300555 - Driver: Better detection of mingw-gcc
I think you've got the wrong Phabricator link in the commit log.
On 18 April 2017 at 15:27, Martell Malone via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: martell
> Date: Tue Apr 18 09:27:36 2017
> New Revision: 300555
>
> URL: http://llvm.org/viewvc/llvm-project?rev=300555&view=rev
> Log:
> Driver: Better detection of mingw-gcc
>
> Stop blindly searching for "gcc.exe" on windows.
> Stop assuming "/usr" on unix, fixes cross compiling.
>
> Reviewers: mati865, yaron.keren
>
> Subscribers: ismail, rnk
>
> Differential revision: https://reviews.llvm.org/D15005
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
> cfe/trunk/lib/Driver/ToolChains/MinGW.h
>
> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/
> ToolChains/MinGW.cpp?rev=300555&r1=300554&r2=300555&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MinGW.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.cpp Tue Apr 18 09:27:36 2017
> @@ -285,28 +285,30 @@ void toolchains::MinGW::findGccLibDir()
>}
> }
>
> +llvm::ErrorOr toolchains::MinGW::findGcc() {
> + llvm::SmallVector, 2> Gccs;
> + Gccs.emplace_back(getTriple().getArchName());
> + Gccs[0] += "-w64-mingw32-gcc";
> + Gccs.emplace_back("mingw32-gcc");
> + // Please do not add "gcc" here
> + for (StringRef CandidateGcc : Gccs)
> +if (llvm::ErrorOr GPPName = llvm::sys::findProgramByName(
> CandidateGcc))
> + return GPPName;
> + return make_error_code(std::errc::no_such_file_or_directory);
> +}
> +
> toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple &Triple,
> const ArgList &Args)
> : ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args) {
>getProgramPaths().push_back(getDriver().getInstalledDir());
>
> -// In Windows there aren't any standard install locations, we search
> -// for gcc on the PATH. In Linux the base is always /usr.
> -#ifdef LLVM_ON_WIN32
>if (getDriver().SysRoot.size())
> Base = getDriver().SysRoot;
> - else if (llvm::ErrorOr GPPName =
> - llvm::sys::findProgramByName("gcc"))
> + else if (llvm::ErrorOr GPPName = findGcc())
> Base = llvm::sys::path::parent_path(
> llvm::sys::path::parent_path(GPPName.get()));
>else
> Base = llvm::sys::path::parent_path(getDriver().getInstalledDir());
> -#else
> - if (getDriver().SysRoot.size())
> -Base = getDriver().SysRoot;
> - else
> -Base = "/usr";
> -#endif
>
>Base += llvm::sys::path::get_separator();
>findGccLibDir();
>
> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/
> ToolChains/MinGW.h?rev=300555&r1=300554&r2=300555&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MinGW.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.h Tue Apr 18 09:27:36 2017
> @@ -93,6 +93,7 @@ private:
>mutable std::unique_ptr Preprocessor;
>mutable std::unique_ptr Compiler;
>void findGccLibDir();
> + llvm::ErrorOr findGcc();
> };
>
> } // end namespace toolchains
>
>
> ___
> 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: r300555 - Driver: Better detection of mingw-gcc
No problem, thanks for the quick update!
On 18 April 2017 at 15:56, Martell Malone wrote:
> Yes I do :)
> I updated https://reviews.llvm.org/D15005 with a comment incase anyone
> goes there.
> I also updated https://reviews.llvm.org/D15006 (the correct link) to
> point to the commit revision.
>
> Thanks for pointing that out Alex
>
> On Tue, Apr 18, 2017 at 3:49 PM, Alex L wrote:
>
>> I think you've got the wrong Phabricator link in the commit log.
>>
>> On 18 April 2017 at 15:27, Martell Malone via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: martell
>>> Date: Tue Apr 18 09:27:36 2017
>>> New Revision: 300555
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=300555&view=rev
>>> Log:
>>> Driver: Better detection of mingw-gcc
>>>
>>> Stop blindly searching for "gcc.exe" on windows.
>>> Stop assuming "/usr" on unix, fixes cross compiling.
>>>
>>> Reviewers: mati865, yaron.keren
>>>
>>> Subscribers: ismail, rnk
>>>
>>> Differential revision: https://reviews.llvm.org/D15005
>>>
>>> Modified:
>>> cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
>>> cfe/trunk/lib/Driver/ToolChains/MinGW.h
>>>
>>> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Too
>>> lChains/MinGW.cpp?rev=300555&r1=300554&r2=300555&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Driver/ToolChains/MinGW.cpp (original)
>>> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.cpp Tue Apr 18 09:27:36 2017
>>> @@ -285,28 +285,30 @@ void toolchains::MinGW::findGccLibDir()
>>>}
>>> }
>>>
>>> +llvm::ErrorOr toolchains::MinGW::findGcc() {
>>> + llvm::SmallVector, 2> Gccs;
>>> + Gccs.emplace_back(getTriple().getArchName());
>>> + Gccs[0] += "-w64-mingw32-gcc";
>>> + Gccs.emplace_back("mingw32-gcc");
>>> + // Please do not add "gcc" here
>>> + for (StringRef CandidateGcc : Gccs)
>>> +if (llvm::ErrorOr GPPName =
>>> llvm::sys::findProgramByName(CandidateGcc))
>>> + return GPPName;
>>> + return make_error_code(std::errc::no_such_file_or_directory);
>>> +}
>>> +
>>> toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple &Triple,
>>> const ArgList &Args)
>>> : ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args) {
>>>getProgramPaths().push_back(getDriver().getInstalledDir());
>>>
>>> -// In Windows there aren't any standard install locations, we search
>>> -// for gcc on the PATH. In Linux the base is always /usr.
>>> -#ifdef LLVM_ON_WIN32
>>>if (getDriver().SysRoot.size())
>>> Base = getDriver().SysRoot;
>>> - else if (llvm::ErrorOr GPPName =
>>> - llvm::sys::findProgramByName("gcc"))
>>> + else if (llvm::ErrorOr GPPName = findGcc())
>>> Base = llvm::sys::path::parent_path(
>>> llvm::sys::path::parent_path(GPPName.get()));
>>>else
>>> Base = llvm::sys::path::parent_path(getDriver().getInstalledDir());
>>> -#else
>>> - if (getDriver().SysRoot.size())
>>> -Base = getDriver().SysRoot;
>>> - else
>>> -Base = "/usr";
>>> -#endif
>>>
>>>Base += llvm::sys::path::get_separator();
>>>findGccLibDir();
>>>
>>> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.h
>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Too
>>> lChains/MinGW.h?rev=300555&r1=300554&r2=300555&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Driver/ToolChains/MinGW.h (original)
>>> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.h Tue Apr 18 09:27:36 2017
>>> @@ -93,6 +93,7 @@ private:
>>>mutable std::unique_ptr Preprocessor;
>>>mutable std::unique_ptr Compiler;
>>>void findGccLibDir();
>>> + llvm::ErrorOr findGcc();
>>> };
>>>
>>> } // end namespace toolchains
>>>
>>>
>>> ___
>>> 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: r292497 - [Sema] Fix PR28181 by avoiding calling BuildOverloadedBinOp in C mode
Hi Hans,
Would it be possible to merge this for 4.0?
Cheers,
Alex
On 19 January 2017 at 17:17, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Thu Jan 19 11:17:57 2017
> New Revision: 292497
>
> URL: http://llvm.org/viewvc/llvm-project?rev=292497&view=rev
> Log:
> [Sema] Fix PR28181 by avoiding calling BuildOverloadedBinOp in C mode
>
> rdar://28532840
>
> Differential Revision: https://reviews.llvm.org/D25213
>
> Added:
> cfe/trunk/test/Sema/PR28181.c
> 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/SemaE
> xpr.cpp?rev=292497&r1=292496&r2=292497&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Thu Jan 19 11:17:57 2017
> @@ -11505,7 +11505,7 @@ ExprResult Sema::BuildBinOp(Scope *S, So
>return checkPseudoObjectAssignment(S, OpLoc, Opc, LHSExpr, RHSExpr);
>
> // Don't resolve overloads if the other type is overloadable.
> -if (pty->getKind() == BuiltinType::Overload) {
> +if (getLangOpts().CPlusPlus && pty->getKind() ==
> BuiltinType::Overload) {
>// We can't actually test that if we still have a placeholder,
>// though. Fortunately, none of the exceptions we see in that
>// code below are valid when the LHS is an overload set. Note
> @@ -11530,17 +11530,16 @@ ExprResult Sema::BuildBinOp(Scope *S, So
> // An overload in the RHS can potentially be resolved by the type
> // being assigned to.
> if (Opc == BO_Assign && pty->getKind() == BuiltinType::Overload) {
> - if (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent())
> -return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr,
> RHSExpr);
> -
> - if (LHSExpr->getType()->isOverloadableType())
> + if (getLangOpts().CPlusPlus &&
> + (LHSExpr->isTypeDependent() || RHSExpr->isTypeDependent() ||
> + LHSExpr->getType()->isOverloadableType()))
> return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr,
> RHSExpr);
>
>return CreateBuiltinBinOp(OpLoc, Opc, LHSExpr, RHSExpr);
> }
>
> // Don't resolve overloads if the other type is overloadable.
> -if (pty->getKind() == BuiltinType::Overload &&
> +if (getLangOpts().CPlusPlus && pty->getKind() ==
> BuiltinType::Overload &&
> LHSExpr->getType()->isOverloadableType())
>return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
>
>
> Added: cfe/trunk/test/Sema/PR28181.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/PR28
> 181.c?rev=292497&view=auto
>
> ==
> --- cfe/trunk/test/Sema/PR28181.c (added)
> +++ cfe/trunk/test/Sema/PR28181.c Thu Jan 19 11:17:57 2017
> @@ -0,0 +1,13 @@
> +// RUN: %clang_cc1 -fsyntax-only -verify %s
> +
> +struct spinlock_t {
> + int lock;
> +} audit_skb_queue;
> +
> +void fn1() {
> + audit_skb_queue = (lock); // expected-error {{use of undeclared
> identifier 'lock'; did you mean 'long'?}}
> +} // expected-error@-1 {{assigning to 'struct
> spinlock_t' from incompatible type ''}}
> +
> +void fn2() {
> + audit_skb_queue + (lock); // expected-error {{use of undeclared
> identifier 'lock'; did you mean 'long'?}}
> +} // expected-error@-1 {{reference to
> overloaded function could not be resolved; did you mean to call it?}}
>
>
> ___
> 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: r293343 - [ubsan] Sanity-check shift amounts before truncation (fixes PR27271)
Hi Vedant,
This commit has caused a compiler crash in our stage 2 green dragon
ASAN+Ubsan bot (
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_build/). I have
reverted it in r293475. The following example reproduces the crash with
-fsanitize=undefined :
typedef unsigned long long uint64_t;
typedef signed long long int64_t;
uint64_t foo(int64_t x, unsigned i) {
return x << i;
}
Alex
On 27 January 2017 at 23:02, Vedant Kumar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: vedantk
> Date: Fri Jan 27 17:02:44 2017
> New Revision: 293343
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293343&view=rev
> Log:
> [ubsan] Sanity-check shift amounts before truncation (fixes PR27271)
>
> Ubsan does not report UB shifts in some cases where the shift exponent
> needs to be truncated to match the type of the shift base. We perform a
> range check on the truncated shift amount, leading to false negatives.
>
> Fix the issue (PR27271) by performing the range check on the original
> shift amount.
>
> Differential Revision: https://reviews.llvm.org/D29234
>
> Added:
> cfe/trunk/test/CodeGen/ubsan-shift.c
> Modified:
> cfe/trunk/lib/CodeGen/CGExprScalar.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGExprScalar.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CGExprScalar.cpp?rev=293343&r1=293342&r2=293343&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGExprScalar.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExprScalar.cpp Fri Jan 27 17:02:44 2017
> @@ -2751,8 +2751,8 @@ Value *ScalarExprEmitter::EmitShl(const
> isa(Ops.LHS->getType())) {
> CodeGenFunction::SanitizerScope SanScope(&CGF);
> SmallVector, 2> Checks;
> -llvm::Value *WidthMinusOne = GetWidthMinusOneValue(Ops.LHS, RHS);
> -llvm::Value *ValidExponent = Builder.CreateICmpULE(RHS,
> WidthMinusOne);
> +llvm::Value *WidthMinusOne = GetWidthMinusOneValue(Ops.LHS, Ops.RHS);
> +llvm::Value *ValidExponent = Builder.CreateICmpULE(Ops.RHS,
> WidthMinusOne);
>
> if (SanitizeExponent) {
>Checks.push_back(
>
> Added: cfe/trunk/test/CodeGen/ubsan-shift.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> CodeGen/ubsan-shift.c?rev=293343&view=auto
>
> ==
> --- cfe/trunk/test/CodeGen/ubsan-shift.c (added)
> +++ cfe/trunk/test/CodeGen/ubsan-shift.c Fri Jan 27 17:02:44 2017
> @@ -0,0 +1,29 @@
> +// RUN: %clang_cc1 -triple=x86_64-apple-darwin -fsanitize=shift-exponent
> -emit-llvm %s -o - | FileCheck %s
> +
> +// CHECK-LABEL: define i32 @f1
> +int f1(int c, int shamt) {
> +// CHECK: icmp ule i32 %{{.*}}, 31, !nosanitize
> +// CHECK: icmp ule i32 %{{.*}}, 31, !nosanitize
> + return 1 << (c << shamt);
> +}
> +
> +// CHECK-LABEL: define i32 @f2
> +int f2(long c, int shamt) {
> +// CHECK: icmp ule i32 %{{.*}}, 63, !nosanitize
> +// CHECK: icmp ule i64 %{{.*}}, 31, !nosanitize
> + return 1 << (c << shamt);
> +}
> +
> +// CHECK-LABEL: define i32 @f3
> +unsigned f3(unsigned c, int shamt) {
> +// CHECK: icmp ule i32 %{{.*}}, 31, !nosanitize
> +// CHECK: icmp ule i32 %{{.*}}, 31, !nosanitize
> + return 1U << (c << shamt);
> +}
> +
> +// CHECK-LABEL: define i32 @f4
> +unsigned f4(unsigned long c, int shamt) {
> +// CHECK: icmp ule i32 %{{.*}}, 63, !nosanitize
> +// CHECK: icmp ule i64 %{{.*}}, 31, !nosanitize
> + return 1U << (c << shamt);
> +}
>
>
> ___
> 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: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.
Hi Benjamin,
This commit has caused a linking in our stage 2 modules buildbot at
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/.
Specifically, after this commit 'clang-reorder-fields' gets the following
linking error:
FAILED: bin/clang-reorder-fields
: &&
/Users/buildslave/jenkins/sharedspace/clang-stage2-cmake-modulesRDA@2/host-compiler/bin/clang++
-fPIC -fvisibility-inlines-hidden -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 -Werror=date-time -std=c++11
-fmodules
-fmodules-cache-path=/Users/buildslave/jenkins/sharedspace/clang-stage2-cmake-modulesRDA@2/clang-build/module.cache
-fcxx-modules -gmodules -fcolor-diagnostics -fno-common
-Woverloaded-virtual -Wno-nested-anon-types -O2 -g -DNDEBUG
-Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-dead_strip
tools/clang/tools/extra/clang-reorder-fields/tool/CMakeFiles/clang-reorder-fields.dir/ClangReorderFields.cpp.o
-o bin/clang-reorder-fields lib/libLLVMSupport.a lib/libclangBasic.a
lib/libclangFrontend.a lib/libclangReorderFields.a lib/libclangRewrite.a
lib/libclangTooling.a lib/libclangToolingCore.a lib/libclangIndex.a
lib/libclangFrontend.a lib/libclangParse.a lib/libLLVMMCParser.a
lib/libclangSerialization.a lib/libclangSema.a lib/libclangEdit.a
lib/libclangAnalysis.a lib/libLLVMBitReader.a lib/libLLVMProfileData.a
lib/libclangDriver.a lib/libLLVMOption.a lib/libclangASTMatchers.a
lib/libclangFormat.a lib/libclangToolingCore.a lib/libclangRewrite.a
lib/libclangAST.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a
lib/libLLVMMC.a lib/libLLVMSupport.a -lcurses -lz -lm lib/libLLVMDemangle.a
-Wl,-rpath,@loader_path/../lib && :
Undefined symbols for architecture x86_64:
"clang::ast_matchers::recordDecl", referenced from:
clang::reorder_fields::(anonymous
namespace)::ReorderingConsumer::HandleTranslationUnit(clang::ASTContext&)
in libclangReorderFields.a(ReorderFieldsAction.cpp.o)
ld: symbol(s) not found for architecture x86_64
This might be a bug/regression in clang and modules since in my opinion the
link should succeed. I've reverted your commit in r293759 while we are
investigating.
Thanks,
Alex
On 30 January 2017 at 18:20, Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: d0k
> Date: Mon Jan 30 12:20:00 2017
> New Revision: 293518
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293518&view=rev
> Log:
> [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.
>
> This dramatically reduces the size of the global constructors we emit
> for those variables in debug mode.
>
> Modified:
> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/ASTMatchers/ASTMatchersInternal.h?rev=293518&r1=293517&r2=293518&
> view=diff
>
> ==
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Jan 30
> 12:20:00 2017
> @@ -1459,7 +1459,7 @@ class VariadicDynCastAllOfMatcher
> : public VariadicFunction, Matcher,
>makeDynCastAllOfComposite TargetT>> {
> public:
> - VariadicDynCastAllOfMatcher() {}
> + constexpr VariadicDynCastAllOfMatcher() {}
> };
>
> /// \brief A \c VariadicAllOfMatcher object is a variadic functor that
> takes
> @@ -1477,7 +1477,7 @@ class VariadicAllOfMatcher
> : public VariadicFunction, Matcher,
>makeAllOfComposite> {
> public:
> - VariadicAllOfMatcher() {}
> + constexpr VariadicAllOfMatcher() {}
> };
>
> /// \brief Matches nodes of type \c TLoc for which the inner
> @@ -1598,7 +1598,7 @@ public:
>
>struct Func
>: public VariadicFunction, &Self::create>
> {
> -Func() {}
> +constexpr Func() {}
>};
>
> 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: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.
I've narrowed the problem down to the difference in the linkage type for
"clang::ast_matchers::recordDecl" between the module and non-module build:
Module:
@_ZN5clang12ast_matchersL10recordDeclE = external global
%"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.847",
align 1
Non-module:
@_ZN5clang12ast_matchersL10recordDeclE = internal constant
%"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.916"
undef, align 1, !dbg !7
On 1 February 2017 at 11:03, Alex L wrote:
> Hi Benjamin,
>
> This commit has caused a linking in our stage 2 modules buildbot at
> http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/.
> Specifically, after this commit 'clang-reorder-fields' gets the following
> linking error:
>
> FAILED: bin/clang-reorder-fields
> : && /Users/buildslave/jenkins/sharedspace/clang-stage2-cmake-modulesRDA@2
> /host-compiler/bin/clang++ -fPIC -fvisibility-inlines-hidden -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 -Werror=date-time -std=c++11 -fmodules
> -fmodules-cache-path=/Users/buildslave/jenkins/sharedspace/clang-stage2-
> cmake-modulesRDA@2/clang-build/module.cache -fcxx-modules -gmodules
> -fcolor-diagnostics -fno-common -Woverloaded-virtual -Wno-nested-anon-types
> -O2 -g -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> -Wl,-dead_strip tools/clang/tools/extra/clang-reorder-fields/tool/
> CMakeFiles/clang-reorder-fields.dir/ClangReorderFields.cpp.o -o
> bin/clang-reorder-fields lib/libLLVMSupport.a lib/libclangBasic.a
> lib/libclangFrontend.a lib/libclangReorderFields.a lib/libclangRewrite.a
> lib/libclangTooling.a lib/libclangToolingCore.a lib/libclangIndex.a
> lib/libclangFrontend.a lib/libclangParse.a lib/libLLVMMCParser.a
> lib/libclangSerialization.a lib/libclangSema.a lib/libclangEdit.a
> lib/libclangAnalysis.a lib/libLLVMBitReader.a lib/libLLVMProfileData.a
> lib/libclangDriver.a lib/libLLVMOption.a lib/libclangASTMatchers.a
> lib/libclangFormat.a lib/libclangToolingCore.a lib/libclangRewrite.a
> lib/libclangAST.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a
> lib/libLLVMMC.a lib/libLLVMSupport.a -lcurses -lz -lm lib/libLLVMDemangle.a
> -Wl,-rpath,@loader_path/../lib && :
> Undefined symbols for architecture x86_64:
> "clang::ast_matchers::recordDecl", referenced from:
> clang::reorder_fields::(anonymous namespace)::ReorderingConsumer::
> HandleTranslationUnit(clang::ASTContext&) in libclangReorderFields.a(
> ReorderFieldsAction.cpp.o)
> ld: symbol(s) not found for architecture x86_64
>
> This might be a bug/regression in clang and modules since in my opinion
> the link should succeed. I've reverted your commit in r293759 while we are
> investigating.
>
> Thanks,
> Alex
>
>
> On 30 January 2017 at 18:20, Benjamin Kramer via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: d0k
>> Date: Mon Jan 30 12:20:00 2017
>> New Revision: 293518
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=293518&view=rev
>> Log:
>> [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.
>>
>> This dramatically reduces the size of the global constructors we emit
>> for those variables in debug mode.
>>
>> Modified:
>> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>>
>> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> ASTMatchers/ASTMatchersInternal.h?rev=293518&r1=293517&r2=
>> 293518&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
>> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Jan 30
>> 12:20:00 2017
>> @@ -1459,7 +1459,7 @@ class VariadicDynCastAllOfMatcher
>> : public VariadicFunction,
>> Matcher,
>>makeDynCastAllOfComposite> TargetT>> {
>> public:
>> - VariadicDynCastAllOfMatcher() {}
>> + constexpr VariadicDynCastAllOfMatcher() {}
>> };
>>
>> /// \brief A \c VariadicAllOfMatcher object is a variadic functor
>> that takes
>> @@ -1477,7 +1477,7 @@ class VariadicAllOfMatcher
>> : public VariadicFunction, Matcher,
>>makeAllOfComposite> {
>> public:
>> - VariadicAllOfMatcher() {}
>> + constexpr VariadicAllOfMatcher() {}
>> };
>>
>> /// \brief Matches nodes of type \c TLoc for which the inner
>> @@ -1598,7 +1598,7 @@ public:
>>
>>struct Func
>>: public VariadicFunction,
>> &Self::create> {
>> -Func() {}
>> +constexpr Func() {}
>>};
>>
>> private:
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
___
Re: r293787 - [CodeGen][ObjC] Avoid asserting on block pointer types in
Hi Hans,
Would it be possible to merge this for 4.0?
Cheers,
Alex
On 1 February 2017 at 17:37, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Wed Feb 1 11:37:28 2017
> New Revision: 293787
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293787&view=rev
> Log:
> [CodeGen][ObjC] Avoid asserting on block pointer types in
> isPointerZeroInitializable
>
> rdar://30111891
>
> Added:
> cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CodeGenTypes.cpp?rev=293787&r1=293786&r2=293787&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenTypes.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenTypes.cpp Wed Feb 1 11:37:28 2017
> @@ -738,7 +738,7 @@ CodeGenTypes::getCGRecordLayout(const Re
> }
>
> bool CodeGenTypes::isPointerZeroInitializable(QualType T) {
> - assert (T->isAnyPointerType() && "Invalid type");
> + assert((T->isAnyPointerType() || T->isBlockPointerType()) && "Invalid
> type");
>return isZeroInitializable(T);
> }
>
>
> Added: cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> CodeGenObjC/block-ptr-type-crash.m?rev=293787&view=auto
>
> ==
> --- cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m (added)
> +++ cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m Wed Feb 1 11:37:28
> 2017
> @@ -0,0 +1,28 @@
> +// RUN: %clang_cc1 -Wno-objc-root-class -fblocks -o /dev/null -triple
> x86_64-- -emit-llvm %s
> +// REQUIRES: asserts
> +// Verify there is no assertion.
> +
> +// rdar://30111891
> +
> +typedef unsigned long long uint64_t;
> +typedef enum AnEnum : uint64_t AnEnum;
> +enum AnEnum: uint64_t {
> +AnEnumA
> +};
> +
> +typedef void (^BlockType)();
> +@interface MyClass
> +@end
> +@implementation MyClass
> +- (void)_doStuff {
> + struct {
> +int identifier;
> +AnEnum type;
> +BlockType handler;
> + } var = {
> +"hello",
> +AnEnumA,
> +((void *)0)
> + };
> +}
> +@end
>
>
> ___
> 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: r293787 - [CodeGen][ObjC] Avoid asserting on block pointer types in
Thanks!
On 1 February 2017 at 18:57, Hans Wennborg wrote:
> OK. Merged in r293797.
>
> Thanks,
> Hans
>
> On Wed, Feb 1, 2017 at 9:50 AM, Alex L wrote:
> > Hi Hans,
> >
> > Would it be possible to merge this for 4.0?
> >
> > Cheers,
> > Alex
> >
> > On 1 February 2017 at 17:37, Alex Lorenz via cfe-commits
> > wrote:
> >>
> >> Author: arphaman
> >> Date: Wed Feb 1 11:37:28 2017
> >> New Revision: 293787
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=293787&view=rev
> >> Log:
> >> [CodeGen][ObjC] Avoid asserting on block pointer types in
> >> isPointerZeroInitializable
> >>
> >> rdar://30111891
> >>
> >> Added:
> >> cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m
> >> Modified:
> >> cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
> >>
> >> Modified: cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CodeGenTypes.cpp?rev=293787&r1=293786&r2=293787&view=diff
> >>
> >>
> ==
> >> --- cfe/trunk/lib/CodeGen/CodeGenTypes.cpp (original)
> >> +++ cfe/trunk/lib/CodeGen/CodeGenTypes.cpp Wed Feb 1 11:37:28 2017
> >> @@ -738,7 +738,7 @@ CodeGenTypes::getCGRecordLayout(const Re
> >> }
> >>
> >> bool CodeGenTypes::isPointerZeroInitializable(QualType T) {
> >> - assert (T->isAnyPointerType() && "Invalid type");
> >> + assert((T->isAnyPointerType() || T->isBlockPointerType()) && "Invalid
> >> type");
> >>return isZeroInitializable(T);
> >> }
> >>
> >>
> >> Added: cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> CodeGenObjC/block-ptr-type-crash.m?rev=293787&view=auto
> >>
> >>
> ==
> >> --- cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m (added)
> >> +++ cfe/trunk/test/CodeGenObjC/block-ptr-type-crash.m Wed Feb 1
> 11:37:28
> >> 2017
> >> @@ -0,0 +1,28 @@
> >> +// RUN: %clang_cc1 -Wno-objc-root-class -fblocks -o /dev/null -triple
> >> x86_64-- -emit-llvm %s
> >> +// REQUIRES: asserts
> >> +// Verify there is no assertion.
> >> +
> >> +// rdar://30111891
> >> +
> >> +typedef unsigned long long uint64_t;
> >> +typedef enum AnEnum : uint64_t AnEnum;
> >> +enum AnEnum: uint64_t {
> >> +AnEnumA
> >> +};
> >> +
> >> +typedef void (^BlockType)();
> >> +@interface MyClass
> >> +@end
> >> +@implementation MyClass
> >> +- (void)_doStuff {
> >> + struct {
> >> +int identifier;
> >> +AnEnum type;
> >> +BlockType handler;
> >> + } var = {
> >> +"hello",
> >> +AnEnumA,
> >> +((void *)0)
> >> + };
> >> +}
> >> +@end
> >>
> >>
> >> ___
> >> 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: r294008 - [Sema][ObjC++] Typo correction should handle ivars and properties
Hi Hans,
Is there any chance we can merge this for 4.0? It fixed a nasty bug where
clang didn't catch invalid ObjC++ code during semantic analysis which led
to invalid object files or crashes in CodeGen.
Cheers,
Alex
On 3 February 2017 at 14:22, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Fri Feb 3 08:22:33 2017
> New Revision: 294008
>
> URL: http://llvm.org/viewvc/llvm-project?rev=294008&view=rev
> Log:
> [Sema][ObjC++] Typo correction should handle ivars and properties
>
> After r260016 and r260017 disabled typo correction for ivars and properties
> clang didn't report errors about unresolved identifier in the base of ivar
> and
> property ref expressions. This meant that clang invoked CodeGen on invalid
> AST
> which then caused a crash.
>
> This commit re-enables typo correction for ivars and properites, and fixes
> the
> PR25113 & PR26486 (that were originally fixed in r260017 and r260016) in a
> different manner by transforming the Objective-C ivar reference expression
> with
> 'IsFreeIvar' preserved.
>
> rdar://30310772
>
> Modified:
> cfe/trunk/lib/Sema/SemaExprCXX.cpp
> cfe/trunk/lib/Sema/TreeTransform.h
> cfe/trunk/test/SemaObjCXX/typo-correction.mm
>
> Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaExprCXX.cpp?rev=294008&r1=294007&r2=294008&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Fri Feb 3 08:22:33 2017
> @@ -7250,14 +7250,6 @@ public:
>
>ExprResult TransformBlockExpr(BlockExpr *E) { return Owned(E); }
>
> - ExprResult TransformObjCPropertyRefExpr(ObjCPropertyRefExpr *E) {
> -return Owned(E);
> - }
> -
> - ExprResult TransformObjCIvarRefExpr(ObjCIvarRefExpr *E) {
> -return Owned(E);
> - }
> -
>ExprResult Transform(Expr *E) {
> ExprResult Res;
> while (true) {
>
> Modified: cfe/trunk/lib/Sema/TreeTransform.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> TreeTransform.h?rev=294008&r1=294007&r2=294008&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/TreeTransform.h (original)
> +++ cfe/trunk/lib/Sema/TreeTransform.h Fri Feb 3 08:22:33 2017
> @@ -2982,16 +2982,17 @@ public:
>ExprResult RebuildObjCIvarRefExpr(Expr *BaseArg, ObjCIvarDecl *Ivar,
>SourceLocation IvarLoc,
>bool IsArrow, bool IsFreeIvar) {
> -// FIXME: We lose track of the IsFreeIvar bit.
> CXXScopeSpec SS;
> DeclarationNameInfo NameInfo(Ivar->getDeclName(), IvarLoc);
> -return getSema().BuildMemberReferenceExpr(BaseArg,
> BaseArg->getType(),
> - /*FIXME:*/IvarLoc, IsArrow,
> - SS, SourceLocation(),
> - /*FirstQualifierInScope=*/
> nullptr,
> - NameInfo,
> - /*TemplateArgs=*/nullptr,
> - /*S=*/nullptr);
> +ExprResult Result = getSema().BuildMemberReferenceExpr(
> +BaseArg, BaseArg->getType(),
> +/*FIXME:*/ IvarLoc, IsArrow, SS, SourceLocation(),
> +/*FirstQualifierInScope=*/nullptr, NameInfo,
> +/*TemplateArgs=*/nullptr,
> +/*S=*/nullptr);
> +if (IsFreeIvar && Result.isUsable())
> + cast(Result.get())->setIsFreeIvar(IsFreeIvar);
> +return Result;
>}
>
>/// \brief Build a new Objective-C property reference expression.
>
> Modified: cfe/trunk/test/SemaObjCXX/typo-correction.mm
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> SemaObjCXX/typo-correction.mm?rev=294008&r1=294007&r2=294008&view=diff
>
> ==
> --- cfe/trunk/test/SemaObjCXX/typo-correction.mm (original)
> +++ cfe/trunk/test/SemaObjCXX/typo-correction.mm Fri Feb 3 08:22:33 2017
> @@ -21,3 +21,18 @@ public:
>self.m_prop2 = new ClassB(m_prop1); // expected-error {{use of
> undeclared identifier 'm_prop1'; did you mean '_m_prop1'?}}
> }
> @end
> +
> +// rdar://30310772
> +
> +@interface InvalidNameInIvarAndPropertyBase
> +{
> +@public
> + float _a;
> +}
> +@property float _b;
> +@end
> +
> +void invalidNameInIvarAndPropertyBase() {
> + float a = ((InvalidNameInIvarAndPropertyBase*)node)->_a; //
> expected-error {{use of undeclared identifier 'node'}}
> + float b = ((InvalidNameInIvarAndPropertyBase*)node)._b; //
> expected-error {{use of undeclared identifier 'node'}}
> +}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
Re: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.
Adrian has filed PR 31860 at https://llvm.org/bugs/show_bug.cgi?id=31860 . On 3 February 2017 at 23:10, Duncan P. N. Exon Smith wrote: > Note that this also failed on Linux: > http://lab.llvm.org:8011/builders/clang-x86_64-linux- > selfhost-modules/builds/2728 > > This looks like a modules compiler bug, as opposed to a problem in the > commit itself. Alex, can you file a PR for this? > > > On 2017-Feb-01, at 07:35, Alex L via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > > > I've narrowed the problem down to the difference in the linkage type for > "clang::ast_matchers::recordDecl" between the module and non-module build: > > > > Module: > > @_ZN5clang12ast_matchersL10recordDeclE = external global > %"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.847", > align 1 > > > > Non-module: > > @_ZN5clang12ast_matchersL10recordDeclE = internal constant > %"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.916" > undef, align 1, !dbg !7 > > > > On 1 February 2017 at 11:03, Alex L wrote: > > Hi Benjamin, > > > > This commit has caused a linking in our stage 2 modules buildbot at > http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/. > Specifically, after this commit 'clang-reorder-fields' gets the following > linking error: > > > > FAILED: bin/clang-reorder-fields > > : && /Users/buildslave/jenkins/sharedspace/clang-stage2- > cmake-modulesRDA@2/host-compiler/bin/clang++ -fPIC > -fvisibility-inlines-hidden -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 -Werror=date-time -std=c++11 -fmodules > -fmodules-cache-path=/Users/buildslave/jenkins/sharedspace/clang-stage2- > cmake-modulesRDA@2/clang-build/module.cache -fcxx-modules -gmodules > -fcolor-diagnostics -fno-common -Woverloaded-virtual -Wno-nested-anon-types > -O2 -g -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names > -Wl,-dead_strip tools/clang/tools/extra/clang-reorder-fields/tool/ > CMakeFiles/clang-reorder-fields.dir/ClangReorderFields.cpp.o -o > bin/clang-reorder-fields lib/libLLVMSupport.a lib/libclangBasic.a > lib/libclangFrontend.a lib/libclangReorderFields.a lib/libclangRewrite.a > lib/libclangTooling.a lib/libclangToolingCore.a lib/libclangIndex.a > lib/libclangFrontend.a lib/libclangParse.a lib/libLLVMMCParser.a > lib/libclangSerialization.a lib/libclangSema.a lib/libclangEdit.a > lib/libclangAnalysis.a lib/libLLVMBitReader.a lib/libLLVMProfileData.a > lib/libclangDriver.a lib/libLLVMOption.a lib/libclangASTMatchers.a > lib/libclangFormat.a lib/libclangToolingCore.a lib/libclangRewrite.a > lib/libclangAST.a lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a > lib/libLLVMMC.a lib/libLLVMSupport.a -lcurses -lz -lm lib/libLLVMDemangle.a > -Wl,-rpath,@loader_path/../lib && : > > Undefined symbols for architecture x86_64: > > "clang::ast_matchers::recordDecl", referenced from: > > clang::reorder_fields::(anonymous namespace)::ReorderingConsumer:: > HandleTranslationUnit(clang::ASTContext&) in libclangReorderFields.a( > ReorderFieldsAction.cpp.o) > > ld: symbol(s) not found for architecture x86_64 > > > > This might be a bug/regression in clang and modules since in my opinion > the link should succeed. I've reverted your commit in r293759 while we are > investigating. > > > > Thanks, > > Alex > > > > > > On 30 January 2017 at 18:20, Benjamin Kramer via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > Author: d0k > > Date: Mon Jan 30 12:20:00 2017 > > New Revision: 293518 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=293518&view=rev > > Log: > > [ASTMatchers] Sprinkle some constexpr on the global matcher constructors. > > > > This dramatically reduces the size of the global constructors we emit > > for those variables in debug mode. > > > > Modified: > > cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h > > > > Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h > > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/ > clang/ASTMatchers/ASTMatchersInternal.h?rev=293518&r1=293517&r2=293518& > view=diff > > > == > > --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original) > > +++ cfe/trunk/include/clang/AS
Re: r294008 - [Sema][ObjC++] Typo correction should handle ivars and properties
Thanks!
On 3 February 2017 at 22:34, Hans Wennborg wrote:
> Thanks! r294059.
>
> On Fri, Feb 3, 2017 at 2:29 PM, Richard Smith
> wrote:
> > It looks like the only cases it should have any real impact on are those
> > where we would previously miscompile/crash, so this seems OK to me to
> merge
> > to Clang 4.
> >
> >
> > On 3 February 2017 at 13:45, Hans Wennborg wrote:
> >>
> >> IIUC, this isn't strictly fixing a regression from 3.9, but it looks
> >> like a pretty small diff.
> >>
> >> Richard, what do you think?
> >>
> >> On Fri, Feb 3, 2017 at 6:37 AM, Alex L wrote:
> >> > Hi Hans,
> >> >
> >> > Is there any chance we can merge this for 4.0? It fixed a nasty bug
> >> > where
> >> > clang didn't catch invalid ObjC++ code during semantic analysis which
> >> > led to
> >> > invalid object files or crashes in CodeGen.
> >> >
> >> > Cheers,
> >> > Alex
> >> >
> >> > On 3 February 2017 at 14:22, Alex Lorenz via cfe-commits
> >> > wrote:
> >> >>
> >> >> Author: arphaman
> >> >> Date: Fri Feb 3 08:22:33 2017
> >> >> New Revision: 294008
> >> >>
> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=294008&view=rev
> >> >> Log:
> >> >> [Sema][ObjC++] Typo correction should handle ivars and properties
> >> >>
> >> >> After r260016 and r260017 disabled typo correction for ivars and
> >> >> properties
> >> >> clang didn't report errors about unresolved identifier in the base of
> >> >> ivar
> >> >> and
> >> >> property ref expressions. This meant that clang invoked CodeGen on
> >> >> invalid
> >> >> AST
> >> >> which then caused a crash.
> >> >>
> >> >> This commit re-enables typo correction for ivars and properites, and
> >> >> fixes
> >> >> the
> >> >> PR25113 & PR26486 (that were originally fixed in r260017 and r260016)
> >> >> in a
> >> >> different manner by transforming the Objective-C ivar reference
> >> >> expression
> >> >> with
> >> >> 'IsFreeIvar' preserved.
> >> >>
> >> >> rdar://30310772
> >> >>
> >> >> Modified:
> >> >> cfe/trunk/lib/Sema/SemaExprCXX.cpp
> >> >> cfe/trunk/lib/Sema/TreeTransform.h
> >> >> cfe/trunk/test/SemaObjCXX/typo-correction.mm
> >> >>
> >> >> Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
> >> >> URL:
> >> >>
> >> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaExprCXX.cpp?rev=294008&r1=294007&r2=294008&view=diff
> >> >>
> >> >>
> >> >>
> ==
> >> >> --- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
> >> >> +++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Fri Feb 3 08:22:33 2017
> >> >> @@ -7250,14 +7250,6 @@ public:
> >> >>
> >> >>ExprResult TransformBlockExpr(BlockExpr *E) { return Owned(E); }
> >> >>
> >> >> - ExprResult TransformObjCPropertyRefExpr(ObjCPropertyRefExpr *E) {
> >> >> -return Owned(E);
> >> >> - }
> >> >> -
> >> >> - ExprResult TransformObjCIvarRefExpr(ObjCIvarRefExpr *E) {
> >> >> -return Owned(E);
> >> >> - }
> >> >> -
> >> >>ExprResult Transform(Expr *E) {
> >> >> ExprResult Res;
> >> >> while (true) {
> >> >>
> >> >> Modified: cfe/trunk/lib/Sema/TreeTransform.h
> >> >> URL:
> >> >>
> >> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> TreeTransform.h?rev=294008&r1=294007&r2=294008&view=diff
> >> >>
> >> >>
> >> >>
> ==
> >> >> --- cfe/trunk/lib/Sema/TreeTransform.h (original)
> >> >> +++ cfe/trunk/lib/Sema/TreeTransform.h Fri Feb 3 08:22:33 2017
> >> >> @@ -2982,16 +2982,17 @@ public:
> >> >>ExprResult RebuildObjCIvarRefExpr(Expr *BaseArg, ObjCIvarDecl
> *Ivar,
> >> >>SourceLocation IvarLoc,
> >> >>bool IsArrow, bool
> >> >> IsFreeIvar)
> >> >> {
> >> >> -// FIXME: We lose track of the IsFreeIvar bit.
> >> >> CXXScopeSpec SS;
> >> >> DeclarationNameInfo NameInfo(Ivar->getDeclName(), IvarLoc);
> >> >> -return getSema().BuildMemberReferenceExpr(BaseArg,
> >> >> BaseArg->getType(),
> >> >> - /*FIXME:*/IvarLoc,
> >> >> IsArrow,
> >> >> - SS, SourceLocation(),
> >> >> -
> >> >> /*FirstQualifierInScope=*/nullptr,
> >> >> - NameInfo,
> >> >> -
> >> >> /*TemplateArgs=*/nullptr,
> >> >> - /*S=*/nullptr);
> >> >> +ExprResult Result = getSema().BuildMemberReferenceExpr(
> >> >> +BaseArg, BaseArg->getType(),
> >> >> +/*FIXME:*/ IvarLoc, IsArrow, SS, SourceLocation(),
> >> >> +/*FirstQualifierInScope=*/nullptr, NameInfo,
> >> >> +/*TemplateArgs=*/nullptr,
> >> >> +/*S=*/nullptr);
> >> >> +if (IsFreeIvar && Result.isUsable())
> >> >> + cast(Result.get())->setIsFreeIvar(
> IsFreeIvar);
> >> >> +return Result;
> >> >>}
> >> >>
> >> >>/// \brief Build a new Objective-C property reference expression.
> >> >>
>
Re: r306844 - Attempt to fix the linkage error caused by r306840 on the mingw-RA-on-linux bot
It worked! On 30 June 2017 at 18:15, Alex Lorenz via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: arphaman > Date: Fri Jun 30 10:15:48 2017 > New Revision: 306844 > > URL: http://llvm.org/viewvc/llvm-project?rev=306844&view=rev > Log: > Attempt to fix the linkage error caused by r306840 on the > mingw-RA-on-linux bot > > Modified: > cfe/trunk/tools/clang-rename/CMakeLists.txt > > Modified: cfe/trunk/tools/clang-rename/CMakeLists.txt > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang- > rename/CMakeLists.txt?rev=306844&r1=306843&r2=306844&view=diff > > == > --- cfe/trunk/tools/clang-rename/CMakeLists.txt (original) > +++ cfe/trunk/tools/clang-rename/CMakeLists.txt Fri Jun 30 10:15:48 2017 > @@ -1,3 +1,8 @@ > +set(LLVM_LINK_COMPONENTS > + Option > + Support > + ) > + > add_clang_executable(clang-rename ClangRename.cpp) > > target_link_libraries(clang-rename > > > ___ > 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: r308441 - Recommit r308327: Add a warning for missing '#pragma pack (pop)'
Thanks, I'll take a look.
On 19 July 2017 at 13:31, Hans Wennborg wrote:
> On Wed, Jul 19, 2017 at 2:26 PM, Hans Wennborg wrote:
> > On Wed, Jul 19, 2017 at 1:30 PM, Alex Lorenz via cfe-commits
> > wrote:
> >> Author: arphaman
> >> Date: Wed Jul 19 04:30:41 2017
> >> New Revision: 308441
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=308441&view=rev
> >> Log:
> >> Recommit r308327: Add a warning for missing '#pragma pack (pop)'
> >> and suspicious uses of '#pragma pack' in included files
> >>
> >> This commit adds a new -Wpragma-pack warning. It warns in the following
> cases:
> >>
> >> - When a translation unit is missing terminating #pragma pack (pop)
> directives.
> >> - When entering an included file if the current alignment value as
> determined
> >> by '#pragma pack' directives is different from the default alignment
> value.
> >> - When leaving an included file that changed the state of the current
> alignment
> >> value.
> >>
> >> rdar://10184173
> >>
> >> Differential Revision: https://reviews.llvm.org/D35484
> >
> > This buildbot is unhappy:
> > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/2963
> >
> > From the build log:
> >
> > [ 67%] Building CXX object
> > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o
> > In file included from
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/lib/ProfileData/Coverage/CoverageMappingWriter.cpp:15:
> > In file included from
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/include/llvm/ProfileData/Coverage/CoverageMappingWriter.h:20:
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h:517:10:
> > error: non-default #pragma pack value might change the alignment of
> > struct or union members in the included file [-Werror,-Wpragma-pack]
> > #include "llvm/ProfileData/InstrProfData.inc"
> > ^
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h:513:1:
> > note: previous '#pragma pack' directive that modifies alignment is
> > here
> > LLVM_PACKED_START
> > ^
> > /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/
> llvm/include/llvm/Support/Compiler.h:349:28:
> > note: expanded from macro 'LLVM_PACKED_START'
> > # define LLVM_PACKED_START _Pragma("pack(push, 1)")
> >^
> > :14:2: note: expanded from here
> > pack(push, 1)
> > ^
>
> I've reverted in r308455 in the meantime.
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r308722 - Fixed failing assert in code completion.
Hans, can you please merge this to the LLVM 5.0 branch?
AFAIK It's a recent regression that should get fixed in LLVM 5.0.
Cheers,
Alex
On 21 July 2017 at 10:24, Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ibiryukov
> Date: Fri Jul 21 02:24:00 2017
> New Revision: 308722
>
> URL: http://llvm.org/viewvc/llvm-project?rev=308722&view=rev
> Log:
> Fixed failing assert in code completion.
>
> Summary:
> The code was accessing uninstantiated default argument.
> This resulted in failing assertion at ParmVarDecl::getDefaultArg().
>
> Reviewers: erikjv, klimek, bkramer, krasimir
>
> Reviewed By: krasimir
>
> Subscribers: cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D35682
>
> Added:
> cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp
> Modified:
> cfe/trunk/lib/Sema/SemaCodeComplete.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaCodeComplete.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaC
> odeComplete.cpp?rev=308722&r1=308721&r2=308722&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaCodeComplete.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaCodeComplete.cpp Fri Jul 21 02:24:00 2017
> @@ -2401,10 +2401,7 @@ formatBlockPlaceholder(const PrintingPol
> static std::string GetDefaultValueString(const ParmVarDecl *Param,
> const SourceManager &SM,
> const LangOptions &LangOpts) {
> - const Expr *defaultArg = Param->getDefaultArg();
> - if (!defaultArg)
> -return "";
> - const SourceRange SrcRange = defaultArg->getSourceRange();
> + const SourceRange SrcRange = Param->getDefaultArgRange();
>CharSourceRange CharSrcRange = CharSourceRange::getTokenRange
> (SrcRange);
>bool Invalid = CharSrcRange.isInvalid();
>if (Invalid)
>
> Added: cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeCompl
> etion/uninstantiated_params.cpp?rev=308722&view=auto
>
> ==
> --- cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp (added)
> +++ cfe/trunk/test/CodeCompletion/uninstantiated_params.cpp Fri Jul 21
> 02:24:00 2017
> @@ -0,0 +1,13 @@
> +template
> +struct unique_ptr {
> + typedef T* pointer;
> +
> + void reset(pointer ptr = pointer());
> +};
> +
> +void test() {
> + unique_ptr x;
> + x.
> + // RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:10:5 %s -o - |
> FileCheck -check-prefix=CHECK-CC1 %s
> + // CHECK-CC1: [#void#]reset({#<#unique_ptr::pointer ptr =
> pointer()#>#})
> +}
>
>
> ___
> 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: r309106 - Recommit r308327 2nd time: Add a warning for missing
On 26 July 2017 at 22:32, Hans Wennborg wrote: > On Wed, Jul 26, 2017 at 11:27 AM, Hans Wennborg wrote: > > On Wed, Jul 26, 2017 at 5:20 AM, Alex Lorenz via cfe-commits > > wrote: > >> Author: arphaman > >> Date: Wed Jul 26 05:20:57 2017 > >> New Revision: 309106 > >> > >> URL: http://llvm.org/viewvc/llvm-project?rev=309106&view=rev > >> Log: > >> Recommit r308327 2nd time: Add a warning for missing > >> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included > files > >> > >> The first recommit (r308441) caused a "non-default #pragma pack value > might > >> change the alignment of struct or union members in the included file" > warning > >> in LLVM itself. This recommit tweaks the added warning to avoid > warnings for > >> #includes that don't have any records that are affected by the > non-default > >> alignment. This tweak avoids the previously emitted warning in LLVM. > >> > >> Original message: > >> > >> This commit adds a new -Wpragma-pack warning. It warns in the following > cases: > >> > >> - When a translation unit is missing terminating #pragma pack (pop) > directives. > >> - When entering an included file if the current alignment value as > determined > >> by '#pragma pack' directives is different from the default alignment > value. > >> - When leaving an included file that changed the state of the current > alignment > >> value. > >> > >> rdar://10184173 > >> > >> Differential Revision: https://reviews.llvm.org/D35484 > > > > We have code in Chromium that does exactly this: > > > > gles2_cmd_format.h does #pragma pack(push, 4) and then #includes a > > file with some generated structs, with the intention that the pragma > > applies to them. > > > > What's the best way to pacify the warning in this case? > > > > (We're tracking this in > > https://bugs.chromium.org/p/chromium/issues/detail?id=749197) > > I agree that cases 1) and 3) from your patch description make sense to > warn for, but I'm not sure that's the case for 2). Do you have > examples where this catches any bugs? In our case #pragma packing an > included file is intentional, and I suspect it might be a bit of a > pattern. > I see, thanks for your input. 2) is generally designed for times when #pragma pack pop was accidentally used too late (after some #includes that unintentionally receive the alignment). I can see how some projects use this pattern heavily, and I don't think there's a good way to pacify this warning in that case. I think that for us it would be reasonable to turn 2) off by default, and allow users to enable it explicitly using a stronger flag (something like -Wpragma-pack-suspicious-include?). I think that I will leave 2) out of this commit, recommit it without 2) and then commit 2) as a non-default warning that uses a separate flag. > Wouldn't cases 1) and 3) catch most situations where this happens > unintentionally? E.g. when one #includes a file that forgets to > #pragma pop, and then includes a new file afterwards? > > I've reverted in r309186 in the meantime. > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r316268 - [Sema] Fixes for enum handling for tautological comparison diagnostics
Hi Roman,
This commit has caused a regression in LLVM 6 which now triggers
-Wsign-compare for typeof(enum) and typeof(enumConstant). I filed
https://bugs.llvm.org/show_bug.cgi?id=36008. Could you please take a look
at it?
Thanks,
Alex
On 21 October 2017 at 09:44, Roman Lebedev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: lebedevri
> Date: Sat Oct 21 09:44:03 2017
> New Revision: 316268
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316268&view=rev
> Log:
> [Sema] Fixes for enum handling for tautological comparison diagnostics
>
> Summary:
> As Mattias Eriksson has reported in PR35009, in C, for enums, the
> underlying type should
> be used when checking for the tautological comparison, unlike C++, where
> the enumerator
> values define the value range. So if not in CPlusPlus mode, use the enum
> underlying type.
>
> Also, i have discovered a problem (a crash) when evaluating
> tautological-ness of the following comparison:
> ```
> enum A { A_a = 0 };
> if (a < 0) // expected-warning {{comparison of unsigned enum expression <
> 0 is always false}}
> return 0;
> ```
> This affects both the C and C++, but after the first fix, only C++ code
> was affected.
> That was also fixed, while preserving (i think?) the proper diagnostic
> output.
>
> And while there, attempt to enhance the test coverage.
> Yes, some tests got moved around, sorry about that :)
>
> Fixes PR35009
>
> Reviewers: aaron.ballman, rsmith, rjmccall
>
> Reviewed By: aaron.ballman
>
> Subscribers: Rakete, efriedma, materi, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D39122
>
> Added:
> cfe/trunk/test/Sema/outof-range-enum-constant-compare.c
> cfe/trunk/test/Sema/tautological-constant-enum-compare.c
> Modified:
> cfe/trunk/lib/Sema/SemaChecking.cpp
> cfe/trunk/test/Sema/tautological-unsigned-enum-zero-compare.c
> cfe/trunk/test/Sema/tautological-unsigned-enum-zero-compare.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaChecking.cpp?rev=316268&r1=316267&r2=316268&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaChecking.cpp Sat Oct 21 09:44:03 2017
> @@ -8181,8 +8181,12 @@ struct IntRange {
> if (const AtomicType *AT = dyn_cast(T))
>T = AT->getValueType().getTypePtr();
>
> -// For enum types, use the known bit width of the enumerators.
> -if (const EnumType *ET = dyn_cast(T)) {
> +if (!C.getLangOpts().CPlusPlus) {
> + // For enum types in C code, use the underlying datatype.
> + if (const EnumType *ET = dyn_cast(T))
> +T = ET->getDecl()->getIntegerType().getDesugaredType(C).
> getTypePtr();
> +} else if (const EnumType *ET = dyn_cast(T)) {
> + // For enum types in C++, use the known bit width of the
> enumerators.
>EnumDecl *Enum = ET->getDecl();
>// In C++11, enums without definitions can have an explicitly
> specified
>// underlying type. Use this type to compute the range.
> @@ -8584,8 +8588,10 @@ bool isNonBooleanUnsignedValue(Expr *E)
> }
>
> enum class LimitType {
> - Max, // e.g. 32767 for short
> - Min // e.g. -32768 for short
> + Max = 1U << 0U, // e.g. 32767 for short
> + Min = 1U << 1U, // e.g. -32768 for short
> + Both = Max | Min // When the value is both the Min and the Max limit at
> the
> + // same time; e.g. in C++, A::a in enum A { a = 0 };
> };
>
> /// Checks whether Expr 'Constant' may be the
> @@ -8608,6 +8614,10 @@ llvm::Optional IsTypeLimit(Se
>
>IntRange OtherRange = IntRange::forValueOfType(S.Context, OtherT);
>
> + // Special-case for C++ for enum with one enumerator with value of 0.
> + if (OtherRange.Width == 0)
> +return Value == 0 ? LimitType::Both : llvm::Optional();
> +
>if (llvm::APSInt::isSameValue(
>llvm::APSInt::getMaxValue(OtherRange.Width,
> OtherT->isUnsignedIntegerType()),
> @@ -8620,7 +8630,7 @@ llvm::Optional IsTypeLimit(Se
>Value))
> return LimitType::Min;
>
> - return llvm::Optional();
> + return llvm::None;
> }
>
> bool HasEnumType(Expr *E) {
> @@ -8655,9 +8665,12 @@ bool CheckTautologicalComparison(Sema &S
>
>bool ConstIsLowerBound = (Op == BO_LT || Op == BO_LE) ^ RhsConstant;
>bool ResultWhenConstEqualsOther = (Op == BO_LE || Op == BO_GE);
> - bool ResultWhenConstNeOther =
> - ConstIsLowerBound ^ (ValueType == LimitType::Max);
> - if (ResultWhenConstEqualsOther != ResultWhenConstNeOther)
> + if (ValueType != LimitType::Both) {
> +bool ResultWhenConstNeOther =
> +ConstIsLowerBound ^ (ValueType == LimitType::Max);
> +if (ResultWhenConstEqualsOther != ResultWhenConstNeOther)
> + return false; // The comparison is not tautological.
> + } else if (ResultWhenConstEqualsOther == ConstIsLowerBound)
>
Re: [libcxx] r287435 - Fix stdint/cstdint modules
Hello Eric,
I think that this commit (r287435) might have broken the green dragon stage
2 ASAN + UBSAN buildbot:
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/2643/
I'm not sure why exactly the tests fail, since ASAN/UBSAN isn't triggering
anything, and it's just a module error. The other bots have passed these
tests successfully. Do you happen to know what might be causing the test
failures?
Thanks,
Alex
On 19 November 2016 at 03:29, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ericwf
> Date: Fri Nov 18 21:29:03 2016
> New Revision: 287435
>
> URL: http://llvm.org/viewvc/llvm-project?rev=287435&view=rev
> Log:
> Fix stdint/cstdint modules
>
> Added:
> libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/cstdint_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/inttypes_h_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/stdint_h_exports.sh.cpp
> Modified:
> libcxx/trunk/include/module.modulemap
>
> Modified: libcxx/trunk/include/module.modulemap
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/
> module.modulemap?rev=287435&r1=287434&r2=287435&view=diff
>
> ==
> --- libcxx/trunk/include/module.modulemap (original)
> +++ libcxx/trunk/include/module.modulemap Fri Nov 18 21:29:03 2016
> @@ -21,47 +21,20 @@ module std [system] {
> module inttypes_h {
>header "inttypes.h"
>export stdint_h
> -/*
> - export_macros
> -PRId8, PRId16, PRId32, PRId64, PRIdFAST8, PRIdFAST16, PRIdFAST32,
> PRIdFAST64, PRIdLEAST8, PRIdLEAST16, PRIdLEAST32, PRIdLEAST64, PRIdMAX,
> PRIdPTR,
> -PRIi8, PRIi16, PRIi32, PRIi64, PRIiFAST8, PRIiFAST16, PRIiFAST32,
> PRIiFAST64, PRIiLEAST8, PRIiLEAST16, PRIiLEAST32, PRIiLEAST64, PRIiMAX,
> PRIiPTR,
> -PRIo8, PRIo16, PRIo32, PRIo64, PRIoFAST8, PRIoFAST16, PRIoFAST32,
> PRIoFAST64, PRIoLEAST8, PRIoLEAST16, PRIoLEAST32, PRIoLEAST64, PRIoMAX,
> PRIoPTR,
> -PRIu8, PRIu16, PRIu32, PRIu64, PRIuFAST8, PRIuFAST16, PRIuFAST32,
> PRIuFAST64, PRIuLEAST8, PRIuLEAST16, PRIuLEAST32, PRIuLEAST64, PRIuMAX,
> PRIuPTR,
> -PRIx8, PRIx16, PRIx32, PRIx64, PRIxFAST8, PRIxFAST16, PRIxFAST32,
> PRIxFAST64, PRIxLEAST8, PRIxLEAST16, PRIxLEAST32, PRIxLEAST64, PRIxMAX,
> PRIxPTR,
> -PRIX8, PRIX16, PRIX32, PRIX64, PRIXFAST8, PRIXFAST16, PRIXFAST32,
> PRIXFAST64, PRIXLEAST8, PRIXLEAST16, PRIXLEAST32, PRIXLEAST64, PRIXMAX,
> PRIXPTR,
> -SCNd8, SCNd16, SCNd32, SCNd64, SCNdFAST8, SCNdFAST16, SCNdFAST32,
> SCNdFAST64, SCNdLEAST8, SCNdLEAST16, SCNdLEAST32, SCNdLEAST64, SCNdMAX,
> SCNdPTR,
> -SCNi8, SCNi16, SCNi32, SCNi64, SCNiFAST8, SCNiFAST16, SCNiFAST32,
> SCNiFAST64, SCNiLEAST8, SCNiLEAST16, SCNiLEAST32, SCNiLEAST64, SCNiMAX,
> SCNiPTR,
> -SCNo8, SCNo16, SCNo32, SCNo64, SCNoFAST8, SCNoFAST16, SCNoFAST32,
> SCNoFAST64, SCNoLEAST8, SCNoLEAST16, SCNoLEAST32, SCNoLEAST64, SCNoMAX,
> SCNoPTR,
> -SCNu8, SCNu16, SCNu32, SCNu64, SCNuFAST8, SCNuFAST16, SCNuFAST32,
> SCNuFAST64, SCNuLEAST8, SCNuLEAST16, SCNuLEAST32, SCNuLEAST64, SCNuMAX,
> SCNuPTR,
> -SCNx8, SCNx16, SCNx32, SCNx64, SCNxFAST8, SCNxFAST16, SCNxFAST32,
> SCNxFAST64, SCNxLEAST8, SCNxLEAST16, SCNxLEAST32, SCNxLEAST64, SCNxMAX,
> SCNxPTR,
> -SCNX8, SCNX16, SCNX32, SCNX64, SCNXFAST8, SCNXFAST16, SCNXFAST32,
> SCNXFAST64, SCNXLEAST8, SCNXLEAST16, SCNXLEAST32, SCNXLEAST64, SCNXMAX,
> SCNXPTR
> -*/
>export *
> }
> // provided by compiler.
> // provided by compiler or C library.
> module locale_h {
>header "locale.h"
> -/*
> - export_macros LC_ALL LC_COLLATE LC_CTYPE LC_MONETARY LC_NUMERIC
> LC_TIME
> -*/
>export *
> }
> module math_h {
>header "math.h"
> -/*
> - export_macros FP_FAST_FMA, FP_FAST_FMAF, FP_FAST_FMAL, FP_ILOGBO,
> FP_ILOGBNAN,
> -FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, FP_ZERO,
> -HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, NAN,
> -MATH_ERRNO, MATH_ERREXCEPT, math_errhandling
> -*/
>export *
> }
> module setjmp_h {
>header "setjmp.h"
> -/*
> - export_macros setjmp
> -*/
>export *
> }
> // FIXME: is missing.
> @@ -72,30 +45,22 @@ module std [system] {
>// 's __need_* macros require textual inclusion.
>textual header "stddef.h"
> }
> -// provided by compiler or C library.
> +module stdint_h {
> + header "stdint.h"
> + export *
> +}
> module stdio_h {
>// 's __need_* macros require textual inclusion.
>textual header "stdio.h"
> -/*
> - export_macros BUFSIZ, EOF, FILENAME_MAX, FOPEN_MAX, L_tmpnam, NULL,
> -SEEK_CUR, SEEK_END, SEEK_SET, TMP_MAX, _IOFBF, _IOLBF,
> -stdin, stdout, stderr
> -*/
>export *
> }
> module stdlib_h {
>
Re: [RFC] Embedded bitcode and related upstream (Part II)
On 30 November 2016 at 15:46, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Hi Steven,
>
> On Fri, Jun 3, 2016 at 2:36 PM, Steven Wu via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi everyone
>>
>> I am still in the process of upstreaming some improvements to the embed
>> bitcode option. If you want more background, you can read the previous RFC (
>> http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html).
>> This is part II of the discussion.
>>
>> Current Status:
>> A basic version of -fembed-bitcode option is upstreamed and functioning.
>> You can use -fembed-bitcode={off, all, bitcode, marker} option to control
>> what gets embedded in the final object file output:
>> off: default, nothing gets embedded.
>> all: optimized bitcode and command line options gets embedded in the
>> object file.
>> bitcode: only optimized bitcode is embedded
>> marker: only put a marker in the object file
>>
>> What needs to be improved:
>> 1. Whitelist for command line options that can be used with bitcode:
>> Current trunk implementation embeds all the cc1 command line options
>> (that includes header include paths, warning flags and other front-end
>> options) in the command line section. That is lot of redundant information.
>> To re-create the object file from the embedded optimized bitcode, most of
>> these options are useless. On the other hand, they can leak information of
>> the source code. One solution will be keeping a list of all the options
>> that can affect code generation but not encoded in the bitcode. I have
>> internally prototyped with disallowing these options explicitly and allowed
>> only the reminder of the options to be embedded (
>> http://reviews.llvm.org/D17394). A better solution might be encoding
>> that information in "Options.td" as specific group.
>>
>> 2. Assembly input handling:
>> This is a workaround to allow source code written in assembly to work
>> with "-fembed-bitcode" options. When compiling assembly source code with
>> "-fembed-bitcode", clang-as creates an empty section "__LLVM, __asm" in the
>> object file. That is just a way to distinguish object files compiled from
>> assembly source from those compiled from higher level source code but
>> forgot to use "-fembed-bitcode" options. Linker can use this section to
>> diagnose if "-fembed-bitcode" is consistently used on all the object files
>> participated in the linking.
>>
>
> It looks like shipping Xcode's clang has this behavior, but open-source
> clang still doesn't. Can you contribute it? It's very useful to us if
> open-source clang has the same features as the clang shipping in Xcode.
> (That last sentence is true in general, not just for this specific feature.)
>
Just FYI, Steven is away on vacation for a month. I think he should be back
in January.
>
>
>>
>> 3. Bitcode symbol hiding:
>> There was some concerns for leaking source code information when using
>> bitcode feature. One approach to avoid the leak is to add a pass which
>> renames all the globals and metadata strings. The also keeps a reverse map
>> in case the original name needs to be recovered. The final bitcode should
>> contain no more symbols or debug info than a stripped binary. To make sure
>> modified bitcode can still be linked correctly, the renaming need to be
>> consistent across all bitcode participated in the linking and everything
>> that is external of the linkage unit need to be preserved. This means the
>> pass can only be run during the linking and requires some LTO api.
>>
>> 4. Debug info strip to line-tables pass:
>> As the name suggested, this pass strip down the full debug info to
>> line-tables only. This is also one of the steps we took to prevent the leak
>> of source code information in bitcode.
>>
>> Please let me know what do you think about the pieces above or if you
>> have any concerns about the methodology. I will put up patches for review
>> soon.
>>
>> Thanks
>>
>> Steven
>>
>> ___
>> 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: r288689 - Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec
Hi Vitaly, I noticed that you posted this patch up for review at https://reviews.llvm.org/D27422, but then committed it instantly without waiting for approval (and you did the same for r288685 as well). Is there any particular reason why you did this? I think that you should've waited for approval before committing. This patch is pretty small, and so it looks to me like it could have been reviewed after it was committed, but patches that get post-commit reviews shouldn't get explicit review requests like this one did. Alex On 5 December 2016 at 19:25, Vitaly Buka via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: vitalybuka > Date: Mon Dec 5 13:25:00 2016 > New Revision: 288689 > > URL: http://llvm.org/viewvc/llvm-project?rev=288689&view=rev > Log: > Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec > > Summary: > Similar to r288685. > getExceptionSpec returned structure with pointers to temporarily object > created > by computeImplicitExceptionSpec. > > Reviewers: rsmith > > Subscribers: aizatsky, cfe-commits > > Differential Revision: https://reviews.llvm.org/D27422 > > Modified: > cfe/trunk/lib/Sema/SemaDeclCXX.cpp > > Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/ > SemaDeclCXX.cpp?rev=288689&r1=288688&r2=288689&view=diff > > == > --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original) > +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Dec 5 13:25:00 2016 > @@ -6299,8 +6299,8 @@ void Sema::CheckExplicitlyDefaultedMembe >CallingConv CC = Context.getDefaultCallingConvention(/* > IsVariadic=*/false, > > /*IsCXXMethod=*/true); >FunctionProtoType::ExtProtoInfo EPI(CC); > - EPI.ExceptionSpec = computeImplicitExceptionSpec(*this, > MD->getLocation(), MD) > - .getExceptionSpec(); > + auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD); > + EPI.ExceptionSpec = IES.getExceptionSpec(); >const FunctionProtoType *ImplicitType = cast( > Context.getFunctionType(Context.VoidTy, None, EPI)); > > > > ___ > 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: r288689 - Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec
On 6 December 2016 at 19:39, Vitaly Buka wrote: > Hi Alex, > > > > On Tue, Dec 6, 2016 at 11:14 AM Alex L wrote: > > Hi Vitaly, > > I noticed that you posted this patch up for review at > https://reviews.llvm.org/D27422, but then committed it instantly without > waiting for approval (and you did the same for r288685 as well). Is there > any particular reason why you did this? I think that you should've waited > for approval before committing. > > > We had broken build bots, so seem like this trivial change is better than > reverting patches. > No.3 of http://llvm.org/docs/DeveloperPolicy.html#code-reviews allows > after commit review for changes like this. > Thanks for the clarification. Yes, the developer policy states that you can commit small changes and get them reviewed after committing, so a commit like this would've been perfect for a post-commit review. However, it also says that "Specifically, once a patch is sent out for review, it needs an explicit “looks good” before it is submitted". Please avoid submitting patches for review if you know that you will commit them without waiting for approval in the future. > > > This patch is pretty small, and so it looks to me like it could have been > reviewed after it was committed, but patches that get post-commit reviews > shouldn't get explicit review requests like this one did. > > > Sorry, probably I did the same few time before. I can't find exact details > in the policy, but I assumed that was a reasonable approach. > So what is the process for after commit review? > People usually read the commit logs and check which commits need post-commit reviews, and then look at them. There's no need for an explicit review request for commits like this. > > > > Alex > > On 5 December 2016 at 19:25, Vitaly Buka via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > > Author: vitalybuka > Date: Mon Dec 5 13:25:00 2016 > New Revision: 288689 > > URL: http://llvm.org/viewvc/llvm-project?rev=288689&view=rev > Log: > Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec > > Summary: > Similar to r288685. > getExceptionSpec returned structure with pointers to temporarily object > created > by computeImplicitExceptionSpec. > > Reviewers: rsmith > > Subscribers: aizatsky, cfe-commits > > Differential Revision: https://reviews.llvm.org/D27422 > > Modified: > cfe/trunk/lib/Sema/SemaDeclCXX.cpp > > Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/ > SemaDeclCXX.cpp?rev=288689&r1=288688&r2=288689&view=diff > > == > --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original) > +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Dec 5 13:25:00 2016 > @@ -6299,8 +6299,8 @@ void Sema::CheckExplicitlyDefaultedMembe >CallingConv CC = Context.getDefaultCallingConvention(/* > IsVariadic=*/false, > > /*IsCXXMethod=*/true); >FunctionProtoType::ExtProtoInfo EPI(CC); > - EPI.ExceptionSpec = computeImplicitExceptionSpec(*this, > MD->getLocation(), MD) > - .getExceptionSpec(); > + auto IES = computeImplicitExceptionSpec(*this, MD->getLocation(), MD); > + EPI.ExceptionSpec = IES.getExceptionSpec(); >const FunctionProtoType *ImplicitType = cast( > Context.getFunctionType(Context.VoidTy, None, EPI)); > > > > ___ > 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] [libclang] Check for a record declaration before a template specialization.
Hi,
On 21 April 2017 at 12:55, Emilio Cobos Álvarez via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> This allows us to get the default template parameters too.
>
> This patch was submitted also as https://reviews.llvm.org/D31732, but I
> see no
> reference to it in cfe-commits or llvm-commits, so I guess it got lost?
>
You have to add cfe-commits as subscribers to the Phabricator patch,
otherwise it won't show up in the mailing list. I would recommend you to
close the old one revision and create a new one on Phabricator, this way
we'll get the entire patch history on cfe-commits.
Alex
>
> This fixes bug 32539.
>
> Signed-off-by: Emilio Cobos Álvarez
> ---
> clang/test/Index/print-type.cpp | 8 +++-
> clang/tools/libclang/CXType.cpp | 6 +++---
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/clang/test/Index/print-type.cpp
> b/clang/test/Index/print-type.cpp
> index 108ba53c80b..ff150f7dd61 100644
> --- a/clang/test/Index/print-type.cpp
> +++ b/clang/test/Index/print-type.cpp
> @@ -71,6 +71,11 @@ struct Specialization;
> Specialization& > templRefParam;
> auto autoTemplRefParam = templRefParam;
>
> +template
> +struct DefaultedTypeExample {};
> +
> +typedef DefaultedTypeExample DefaultedTypeAlias;
> +
> // RUN: c-index-test -test-print-type %s -std=c++14 | FileCheck %s
> // CHECK: Namespace=outer:1:11 (Definition) [type=] [typekind=Invalid]
> [isPOD=0]
> // CHECK: ClassTemplate=Foo:4:8 (Definition) [type=] [typekind=Invalid]
> [isPOD=0]
> @@ -115,7 +120,7 @@ auto autoTemplRefParam = templRefParam;
> // CHECK: TemplateRef=Baz:9:8 [type=] [typekind=Invalid] [isPOD=0]
> // CHECK: IntegerLiteral= [type=int] [typekind=Int] [isPOD=1]
> // CHECK: TemplateRef=Foo:4:8 [type=] [typekind=Invalid] [isPOD=0]
> -// CHECK: FieldDecl=qux:29:38 (Definition) [type=Qux Foo, outer::inner::Bar::FooType>] [typekind=Unexposed]
> [templateargs/4= [type=int] [typekind=Int] [type=char *] [typekind=Pointer]
> [type=Foo] [typekind=Unexposed] [type=outer::inner::Bar::FooType]
> [typekind=Typedef]] [canonicaltype=outer::Qux,
> int>] [canonicaltypekind=Record] [canonicaltemplateargs/4= [type=int]
> [typekind=Int] [type=char *] [typekind=Pointer] [type=outer::Foo]
> [typekind=Record] [type=int] [typekind=Int]] [isPOD=1]
> +// CHECK: FieldDecl=qux:29:38 (Definition) [type=Qux Foo, outer::inner::Bar::FooType>] [typekind=Unexposed]
> [templateargs/4= [type=int] [typekind=Int] [type=char *] [typekind=Pointer]
> [type=outer::Foo] [typekind=Record] [type=int] [typekind=Int]]
> [canonicaltype=outer::Qux, int>]
> [canonicaltypekind=Record] [canonicaltemplateargs/4= [type=int]
> [typekind=Int] [type=char *] [typekind=Pointer] [type=outer::Foo]
> [typekind=Record] [type=int] [typekind=Int]] [isPOD=1]
> // CHECK: TemplateRef=Qux:12:8 [type=] [typekind=Invalid] [isPOD=0]
> // CHECK: TemplateRef=Foo:4:8 [type=] [typekind=Invalid] [isPOD=0]
> // CHECK: FunctionTemplate=tbar:36:3 [type=T (int)]
> [typekind=FunctionProto] [canonicaltype=type-parameter-0-0 (int)]
> [canonicaltypekind=FunctionProto] [resulttype=T]
> [resulttypekind=Unexposed] [isPOD=0]
> @@ -177,3 +182,4 @@ auto autoTemplRefParam = templRefParam;
> // CHECK: VarDecl=autoTemplRefParam:72:6 (Definition)
> [type=Specialization &>] [typekind=Auto]
> [templateargs/1= [type=Specialization &] [typekind=LValueReference]]
> [canonicaltype=Specialization &>]
> [canonicaltypekind=Record] [canonicaltemplateargs/1=
> [type=Specialization &] [typekind=LValueReference]] [isPOD=1]
> // CHECK: UnexposedExpr=templRefParam:71:40 [type=const
> Specialization &>] [typekind=Unexposed] const
> [templateargs/1= [type=Specialization &] [typekind=LValueReference]]
> [canonicaltype=const Specialization &>]
> [canonicaltypekind=Record] [canonicaltemplateargs/1=
> [type=Specialization &] [typekind=LValueReference]] [isPOD=1]
> // CHECK: DeclRefExpr=templRefParam:71:40
> [type=Specialization
> &>] [typekind=Unexposed] [templateargs/1= [type=Specialization &]
> [typekind=LValueReference]] [canonicaltype=Specialization
> &>] [canonicaltypekind=Record] [canonicaltemplateargs/1=
> [type=Specialization &] [typekind=LValueReference]] [isPOD=1]
> +// CHECK: TypedefDecl=DefaultedTypeAlias:77:35 (Definition)
> [type=DefaultedTypeAlias] [typekind=Typedef] [templateargs/2= [type=int]
> [typekind=Int] [type=int] [typekind=Int]]
> [canonicaltype=DefaultedTypeExample int>] [canonicaltypekind=Record] [canonicaltemplateargs/2= [type=int]
> [typekind=Int] [type=int] [typekind=Int]] [isPOD=0]
> diff --git a/clang/tools/libclang/CXType.cpp
> b/clang/tools/libclang/CXType.cpp
> index 16e993e2ac0..fce7ef2c0d8 100644
> --- a/clang/tools/libclang/CXType.cpp
> +++ b/clang/tools/libclang/CXType.cpp
> @@ -147,9 +147,6 @@ static inline CXTranslationUnit GetTU(CXType CT) {
> static Optional>
> GetTemplateArguments(QualType Type) {
>assert(!Type.isNull());
> - if (const auto *Specialization = Type->getAs<
> TemplateSpecializationType>())
> -return Specialization->template_arguments(
Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.
Hi Richard, This commit has caused an infinite loop in one of our internal libclang based tooling tests. It keeps repeating the following frames: frame #33528: 0x000109db2edf libclang.dylib`clang::DiagnosticsEngine::ReportDelayed(this=0x00011c002c00) at Diagnostic.cpp:149 frame #33529: 0x000109db5a36 libclang.dylib`clang::DiagnosticsEngine::EmitCurrentDiagnostic(this=0x00011c002c00, Force=false) at Diagnostic.cpp:428 frame #33530: 0x00010a33f93c libclang.dylib`clang::DiagnosticBuilder::Emit(this=0x78d4bfd8) at Diagnostic.h:1013 frame #33531: 0x00010a33f8e5 libclang.dylib`clang::DiagnosticBuilder::~DiagnosticBuilder(this=0x78d4bfd8) at Diagnostic.h:1036 frame #33532: 0x00010a335015 libclang.dylib`clang::DiagnosticBuilder::~DiagnosticBuilder(this=0x78d4bfd8) at Diagnostic.h:1035 It doesn't really look like a regression though, it seems that this has just uncovered a bug in Clang: DiagnosticsEngine::ReportDelayed is clearing DelayedDiagID *after* reporting the issue which causes the infinite recursion, when it should clear it before. Is that right? I will commit a fix for this now. Alex On 3 May 2017 at 01:28, Richard Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: rsmith > Date: Tue May 2 19:28:49 2017 > New Revision: 301992 > > URL: http://llvm.org/viewvc/llvm-project?rev=301992&view=rev > Log: > [modules] Round-trip -Werror flag through explicit module build. > > The intent for an explicit module build is that the diagnostics produced > within > the module are those that were configured when the module was built, not > those > that are enabled within a user of the module. This includes diagnostics > that > don't actually show up until the module is used (for instance, diagnostics > produced during template instantiation and weird cases like -Wpadded). > > We serialized and restored the diagnostic state for individual warning > groups, > but previously did not track the state for flags like -Werror and > -Weverything, > which are implemented as separate bits rather than as part of the > diagnostics > mapping information. > > Modified: > cfe/trunk/include/clang/Basic/Diagnostic.h > cfe/trunk/include/clang/Basic/DiagnosticIDs.h > cfe/trunk/lib/Basic/Diagnostic.cpp > cfe/trunk/lib/Basic/DiagnosticIDs.cpp > cfe/trunk/lib/Serialization/ASTReader.cpp > cfe/trunk/lib/Serialization/ASTWriter.cpp > cfe/trunk/test/Index/keep-going.cpp > cfe/trunk/test/Modules/diag-flags.cpp > cfe/trunk/tools/libclang/CIndex.cpp > cfe/trunk/unittests/Basic/DiagnosticTest.cpp > > Modified: cfe/trunk/include/clang/Basic/Diagnostic.h > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/ > clang/Basic/Diagnostic.h?rev=301992&r1=301991&r2=301992&view=diff > > == > --- cfe/trunk/include/clang/Basic/Diagnostic.h (original) > +++ cfe/trunk/include/clang/Basic/Diagnostic.h Tue May 2 19:28:49 2017 > @@ -178,12 +178,7 @@ public: > > private: >unsigned char AllExtensionsSilenced; // Used by __extension__ > - bool IgnoreAllWarnings;// Ignore all warnings: -w > - bool WarningsAsErrors; // Treat warnings like errors. > - bool EnableAllWarnings;// Enable all warnings. > - bool ErrorsAsFatal;// Treat errors like fatal errors. > - bool FatalsAsError; // Treat fatal errors like errors. > - bool SuppressSystemWarnings; // Suppress warnings in system headers. > + bool SuppressAfterFatalError; // Suppress diagnostics after a fatal > error? >bool SuppressAllDiagnostics; // Suppress all diagnostics. >bool ElideType;// Elide common types of templates. >bool PrintTemplateTree;// Print a tree when comparing templates. > @@ -194,7 +189,6 @@ private: > // 0 -> no limit. >unsigned ConstexprBacktraceLimit; // Cap on depth of constexpr > evaluation > // backtrace stack, 0 -> no limit. > - diag::Severity ExtBehavior; // Map extensions to warnings or > errors? >IntrusiveRefCntPtr Diags; >IntrusiveRefCntPtr DiagOpts; >DiagnosticConsumer *Client; > @@ -216,6 +210,19 @@ private: > llvm::DenseMap DiagMap; > >public: > +// "Global" configuration state that can actually vary between > modules. > +unsigned IgnoreAllWarnings : 1; // Ignore all warnings: -w > +unsigned EnableAllWarnings : 1; // Enable all warnings. > +unsigned WarningsAsErrors : 1; // Treat warnings like errors. > +unsigned ErrorsAsFatal : 1; // Treat errors like fatal > errors. > +unsigned SuppressSystemWarnings : 1; // Suppress warnings in system > headers. > +diag::Severity ExtBehavior : 4; // Map extensions to warnings or > errors? > + > +DiagState() > +: IgnoreAllWarnings(false), EnableAllWarnings(false), > +
