"[&]" for simplicity/clarity.
On Sun, Mar 22, 2020 at 10:44 PM David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: David Blaikie
> Date: 2020-03-22T22:43:44-07:00
> New Revision: 2ec59a0a40f4ec02e6b2dbe5f12261959c191aa9
>
> UR
On Fri, Mar 27, 2020 at 5:16 PM Arthur O'Dwyer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Richard: Okay, filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94376 !
>
> David: You are correct, the bug in function_ref appeared only when
> constructing from `const function_ref&&`. When I
Author: David Blaikie
Date: 2020-04-01T13:21:13-07:00
New Revision: db92719c1d17f5052e7cd1309b0e1e92240f47be
URL:
https://github.com/llvm/llvm-project/commit/db92719c1d17f5052e7cd1309b0e1e92240f47be
DIFF:
https://github.com/llvm/llvm-project/commit/db92719c1d17f5052e7cd1309b0e1e92240f47be.diff
On Wed, Apr 1, 2020 at 1:21 PM David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: David Blaikie
> Date: 2020-04-01T13:21:13-07:00
> New Revision: db92719c1d17f5052e7cd1309b0e1e92240f47be
>
> URL:
> https://github.c
Author: David Blaikie
Date: 2019-11-01T14:56:43-07:00
New Revision: 42465f406bcea5ea06001ccc52ab779120b68e87
URL:
https://github.com/llvm/llvm-project/commit/42465f406bcea5ea06001ccc52ab779120b68e87
DIFF:
https://github.com/llvm/llvm-project/commit/42465f406bcea5ea06001ccc52ab779120b68e87.diff
Author: David Blaikie
Date: 2019-11-01T15:17:51-07:00
New Revision: 098d901bd1be07f60c41450fa4af775b130117b9
URL:
https://github.com/llvm/llvm-project/commit/098d901bd1be07f60c41450fa4af775b130117b9
DIFF:
https://github.com/llvm/llvm-project/commit/098d901bd1be07f60c41450fa4af775b130117b9.diff
Author: David Blaikie
Date: 2019-11-01T15:36:15-07:00
New Revision: 1de2a05701e73f8ef5914c2f6ea2dcbe617ce18b
URL:
https://github.com/llvm/llvm-project/commit/1de2a05701e73f8ef5914c2f6ea2dcbe617ce18b
DIFF:
https://github.com/llvm/llvm-project/commit/1de2a05701e73f8ef5914c2f6ea2dcbe617ce18b.diff
Author: David Blaikie
Date: 2019-11-07T12:05:58-08:00
New Revision: 8d8f9c24407461fadf1730e80ebcf7c767254715
URL:
https://github.com/llvm/llvm-project/commit/8d8f9c24407461fadf1730e80ebcf7c767254715
DIFF:
https://github.com/llvm/llvm-project/commit/8d8f9c24407461fadf1730e80ebcf7c767254715.diff
Which compiler/what sort of warning was this addressing? (it can be
beneficial to leave variables uninitialized if their value isn't intended
to be used - so things like asan can catch bugs where the read of
uninitialized is unintended)
On Sat, Nov 2, 2019 at 11:27 AM Simon Pilgrim via cfe-commits
Hey Ben - if you're still involved with this part of the project - could
you check that this change (to code you committed back in 2014, r215810) is
correct & add a test case if possible?
On Thu, Nov 7, 2019 at 10:39 AM Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author
OK - thanks for the context!
On Mon, Nov 18, 2019 at 5:07 PM Ben Langmuir wrote:
> Nice find.
>
> The change LGTM, and is clearly what I always intended it to do. I was
> confused how this ever worked at all, but I see that (at least in libc++)
> we move the values into place rather than swap t
Author: David Blaikie
Date: 2019-11-22T17:16:35-08:00
New Revision: e956952edec140d2475aa7c8cbe20fbdd3320634
URL:
https://github.com/llvm/llvm-project/commit/e956952edec140d2475aa7c8cbe20fbdd3320634
DIFF:
https://github.com/llvm/llvm-project/commit/e956952edec140d2475aa7c8cbe20fbdd3320634.diff
On Wed, Nov 20, 2019 at 1:08 AM Djordje Todorovic via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Djordje Todorovic
> Date: 2019-11-20T10:08:07+01:00
> New Revision: ce1f95a6e077693f93d8869245f911aff3eb7e4c
>
> URL:
> https://github.com/llvm/llvm-project/commit/ce1f95a6e077693f93d
Please include details about the reason for the revert (links to and quotes
from buildbots are helpful, etc) in the commit message - so others can
follow along more easily (if they're seeing a local regression, they might
be able to check if this revert is likely to address it - if they want to
pic
Author: David Blaikie
Date: 2020-01-16T15:30:50-08:00
New Revision: 65eb74e94b414fcde6bfa810d1c30c7fcb136b77
URL:
https://github.com/llvm/llvm-project/commit/65eb74e94b414fcde6bfa810d1c30c7fcb136b77
DIFF:
https://github.com/llvm/llvm-project/commit/65eb74e94b414fcde6bfa810d1c30c7fcb136b77.diff
Author: dblaikie
Date: Wed Mar 21 15:34:27 2018
New Revision: 328166
URL: http://llvm.org/viewvc/llvm-project?rev=328166&view=rev
Log:
Fix for LLVM change (Transforms/Utils/Local.h -> Analysis/Utils/Local.h)
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
Modified: cfe/trunk/lib/CodeGen/CGCall.cp
In implicit ThinLTO, the object files are only temporary.
Sort of similar to using -gsplit-dwarf when compiling straight to an
executable (without using -c): "clang++ x.cpp y.cpp -o a.out" - where
should the .dwo files go then? If they go where the .o files go, then
they'll be in /tmp/ and get del
The only data we have is that where .o files go, .dwo files go beside them.
How to generalize this to other situations isn't really obvious to me -
even for a.out (do you put all the .dwo files next to a.out? in the same
directory? if the names collide, where then? etc).
Interestingly GCC for "g++
While implementing the warning is great (wonder if there's any codebase
that isn't -Wunused-using clean, that we could use to compare Clang and
GCC's behavior broadly - make sure it's catching the same cases (or
justify/investigate differences)) - and using it to motivate the debug info
is an impro
Author: dblaikie
Date: Fri Mar 23 15:16:59 2018
New Revision: 328380
URL: http://llvm.org/viewvc/llvm-project?rev=328380&view=rev
Log:
Change for an LLVM header file move
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://llvm.org/vie
Historically Clang's policy on warnings was, I think, much more
conservative than it seems to be today. There was a strong desire not to
implement off-by-default warnings, and to have warnings with an
exceptionally low false-positive rate - maybe the user-defined operator
detection was either assum
Author: dblaikie
Date: Wed Mar 28 10:45:10 2018
New Revision: 328718
URL: http://llvm.org/viewvc/llvm-project?rev=328718&view=rev
Log:
Fix for LLVM header changes
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://llvm.org/viewvc/llvm
On Mon, Apr 2, 2018 at 8:05 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:
> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D44883#1054326, @thakis wrote:
>
> > In https://reviews.llvm.org/D44883#1048751, @dblaikie wrote:
> >
> > > Historically Clang's policy on w
Author: dblaikie
Date: Tue Apr 3 11:22:14 2018
New Revision: 329097
URL: http://llvm.org/viewvc/llvm-project?rev=329097&view=rev
Log:
Restrict a test using named file descriptors to using the system shell
Modified:
cfe/trunk/test/Misc/dev-fd-fs.c
Modified: cfe/trunk/test/Misc/dev-fd-fs.c
UR
Best if you can use the SubVersion revision number rather than a git hash
when reverting. There's a utility in the LLVM project to help with this
(llvm/utils/git-svn/git-svnrevert)
On Fri, Apr 6, 2018 at 12:16 PM George Karpenkov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: geor
FWIW - I had some thoughts on this a while back:
https://reviews.llvm.org/D4313
On Mon, Apr 9, 2018 at 4:54 AM Roman Lebedev via Phabricator via
llvm-commits wrote:
> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D43779#1061444, @alexfh wrote:
>
> > In https://reviews.llvm.org/D437
On Tue, Apr 10, 2018 at 7:21 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:
> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D44883#1063003, @thakis wrote:
>
> > This landing made our clang trunk bots do an evaluation of this warning
> :-P It fired 8 times, all fa
It's more the fact that that's /all/ the warning improvement has found so
far. If it was 8 false positives & also found 80 actionable bugs/bad code,
that'd be one thing.
Now, admittedly, maybe it would help find bugs that people usually catch
with a unit test, etc but never make it to checked in c
On Tue, Apr 10, 2018 at 9:25 AM Roman Lebedev wrote:
> Because *so far* it has been running on the existing code, which i guess
> was already pretty warning free, and was run through the static analyzer,
which obviously should catch such issues.
>
Existing code this has been run over isn't nece
Any good ideas on how to evaluate it, then? (in addition to/other than
something like Google where we can track the diagnostic for - a few months?)
On Tue, Apr 10, 2018 at 9:34 AM John McCall wrote:
> Yeah, -Wself-assign in general is about catching a class of live-coding
> errors which is prett
On Tue, Apr 10, 2018 at 9:59 AM John McCall wrote:
> Also, the standard for the static analyzer is not lower than it is for the
> compiler.
>
> The static analyzer tries to catch a much larger class of bugs, but it
> also tries very hard to make all the warnings it emits count. There’s a
> really
On Tue, Apr 10, 2018 at 10:20 AM John McCall wrote:
> Do you think they’re bad precedent?
Somewhat, yes - though -Wparens is perhaps conflating a few cases too. I
think the argument for the -Wparens for precedence is probably pretty good.
But the argument for -Wparens for conditional assignmen
Author: dblaikie
Date: Fri Oct 27 13:40:46 2017
New Revision: 316794
URL: http://llvm.org/viewvc/llvm-project?rev=316794&view=rev
Log:
StaticAnalyzer: Modularize/fix ODR violations making functions inline but
non-static in headers
Also move these out of the llvm namespace & rely on ADL as is
app
Author: dblaikie
Date: Fri Oct 27 13:40:45 2017
New Revision: 316792
URL: http://llvm.org/viewvc/llvm-project?rev=316792&view=rev
Log:
CharInfo.h: Modularize/fix ODR violations by making inline functions in header
not static
Modified:
cfe/trunk/include/clang/Basic/CharInfo.h
Modified: cfe/t
Author: dblaikie
Date: Fri Oct 27 13:40:44 2017
New Revision: 316791
URL: http://llvm.org/viewvc/llvm-project?rev=316791&view=rev
Log:
ASTContext.h: Modularize/fix ODR violations by removing 'static' from inline
functions in headers
Modified:
cfe/trunk/include/clang/AST/ASTContext.h
Modifie
Author: dblaikie
Date: Fri Oct 27 13:40:45 2017
New Revision: 316793
URL: http://llvm.org/viewvc/llvm-project?rev=316793&view=rev
Log:
Sanitizers.h: Modularize/Fix ODR violations by making inline functions
non-static
Modified:
cfe/trunk/include/clang/Basic/Sanitizers.h
Modified: cfe/trunk/i
I realize this was changed in a follow-up commit anyway, but for future
reference: There's no need (& best to avoid - simpler to read, avoids bugs
like this, etc) to conditionalize delete like this. Delete is a no-op on
null pointers anyway, so this dtor should just contain an unconditional
"delete
Could this be a value rather than indirected through a unique_ptr? Simply:
BodyFarm BdyFrm;
& initialized in the ctors init list?
On Tue, Oct 24, 2017 at 4:53 PM George Karpenkov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: george.karpenkov
> Date: Tue Oct 24 16:53:19 2017
>
On Mon, Oct 23, 2017 at 5:01 PM George Karpenkov via Phabricator via
cfe-commits wrote:
> george.karpenkov added a comment.
>
> @dcoughlin the context I was thinking about is that if everyone
> consistently runs `clang-format` (if we want that), then we never would
> have discussion.
> The altern
Author: dblaikie
Date: Thu Nov 2 14:55:40 2017
New Revision: 317274
URL: http://llvm.org/viewvc/llvm-project?rev=317274&view=rev
Log:
Modular Codegen: Don't home/modularize static functions in headers
Consistent with various workarounds in the backwards compatible modules
that allow static funct
Author: dblaikie
Date: Thu Nov 2 15:28:50 2017
New Revision: 317279
URL: http://llvm.org/viewvc/llvm-project?rev=317279&view=rev
Log:
Modular Codegen: Don't home always_inline functions
Since they'll likely (not always - if the address is taken, etc) be
inlined away, even at -O0, separately prov
When you say "symbols table" - what are you referring to?
On Fri, Nov 3, 2017 at 4:20 PM Adrian Prantl via Phabricator <
revi...@reviews.llvm.org> wrote:
> aprantl added a comment.
>
> Can you add a testcase?
>
>
> Repository:
> rL LLVM
>
> https://reviews.llvm.org/D39622
>
>
>
>
__
Ping \/
On Fri, Nov 3, 2017 at 4:22 PM David Blaikie wrote:
> When you say "symbols table" - what are you referring to?
>
> On Fri, Nov 3, 2017 at 4:20 PM Adrian Prantl via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> aprantl added a comment.
>>
>> Can you add a testcase?
>>
>>
>> Repos
On Sun, Nov 12, 2017 at 12:53 PM Anton via Phabricator <
revi...@reviews.llvm.org> wrote:
> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#919579, @aprantl wrote:
>
> > For clarification: what is the "symbols table" you are referring to in
> the description?
>
>
> I meant the data du
Author: dblaikie
Date: Wed Nov 15 08:52:12 2017
New Revision: 318304
URL: http://llvm.org/viewvc/llvm-project?rev=318304&view=rev
Log:
ASTMatchers.h: Fix ODR violations by avoiding internal linkage variables in
headers
Internal linkage variables ODR referenced from inline functions create
ODR vi
Ping on this layering violation. A simple way to demonstrate this is to
move the definition of clang::Type::getTypeClass out of line: This results
in an unresolved symbol due to incorrect/broken dependencies.
Richard? Anyone else? Ideas on how to address this layering violation?
Anastasia: Could
Author: dblaikie
Date: Thu Nov 16 17:07:20 2017
New Revision: 318491
URL: http://llvm.org/viewvc/llvm-project?rev=318491&view=rev
Log:
Update for layering fix in LLVM CodeGen<>Target
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://
Author: dblaikie
Date: Mon Nov 20 17:09:18 2017
New Revision: 318720
URL: http://llvm.org/viewvc/llvm-project?rev=318720&view=rev
Log:
ASTMatchers{,Macros}.h: Add some extra macros to use for decl/def of matchers
Fix ODR violations caused by using internal linkage variables in
non-internal inline
Author: dblaikie
Date: Mon Nov 20 17:09:17 2017
New Revision: 318719
URL: http://llvm.org/viewvc/llvm-project?rev=318719&view=rev
Log:
FormatInternal.h: Add missing includes.
Modified:
cfe/trunk/lib/Format/FormatInternal.h
Modified: cfe/trunk/lib/Format/FormatInternal.h
URL:
http://llvm.org
Author: David Blaikie
Date: 2023-02-28T01:25:22Z
New Revision: d8a1a559f3009a31c517f864156db91d2ae3012c
URL:
https://github.com/llvm/llvm-project/commit/d8a1a559f3009a31c517f864156db91d2ae3012c
DIFF:
https://github.com/llvm/llvm-project/commit/d8a1a559f3009a31c517f864156db91d2ae3012c.diff
LOG:
Author: Chris Cotter
Date: 2023-02-28T01:27:21Z
New Revision: 58ec6e09abe8083709802833572bca931b2d15d9
URL:
https://github.com/llvm/llvm-project/commit/58ec6e09abe8083709802833572bca931b2d15d9
DIFF:
https://github.com/llvm/llvm-project/commit/58ec6e09abe8083709802833572bca931b2d15d9.diff
LOG:
Author: David Blaikie
Date: 2023-04-04T04:45:32Z
New Revision: e9c9db34a9b04706937e9dd764d1d97ca84337b6
URL:
https://github.com/llvm/llvm-project/commit/e9c9db34a9b04706937e9dd764d1d97ca84337b6
DIFF:
https://github.com/llvm/llvm-project/commit/e9c9db34a9b04706937e9dd764d1d97ca84337b6.diff
LOG:
Author: David Blaikie
Date: 2023-04-05T01:06:41Z
New Revision: e5144d9d2dd26a67f576d2f5772b3cf0486245f4
URL:
https://github.com/llvm/llvm-project/commit/e5144d9d2dd26a67f576d2f5772b3cf0486245f4
DIFF:
https://github.com/llvm/llvm-project/commit/e5144d9d2dd26a67f576d2f5772b3cf0486245f4.diff
LOG:
Author: David Blaikie
Date: 2023-05-09T00:13:45Z
New Revision: a8b0c6fa28acced71db33e80bd0b51d00422035b
URL:
https://github.com/llvm/llvm-project/commit/a8b0c6fa28acced71db33e80bd0b51d00422035b
DIFF:
https://github.com/llvm/llvm-project/commit/a8b0c6fa28acced71db33e80bd0b51d00422035b.diff
LOG:
Author: David Blaikie
Date: 2023-05-09T00:40:11Z
New Revision: 793c5b12b9a70e363be40c5da2e26d7151fbbf41
URL:
https://github.com/llvm/llvm-project/commit/793c5b12b9a70e363be40c5da2e26d7151fbbf41
DIFF:
https://github.com/llvm/llvm-project/commit/793c5b12b9a70e363be40c5da2e26d7151fbbf41.diff
LOG:
On Mon, Dec 5, 2022 at 5:27 AM Juan Manuel MARTINEZ CAAMAÑO via
cfe-commits wrote:
>
>
> Author: Juan Manuel MARTINEZ CAAMAÑO
> Date: 2022-12-05T07:27:10-06:00
> New Revision: a446827249bdeb2f27e55a9f4942bd7425ecb0ff
>
> URL:
> https://github.com/llvm/llvm-project/commit/a446827249bdeb2f27e55a9f4
Author: David Blaikie
Date: 2022-12-06T21:11:08Z
New Revision: 3c312e48f325c1b1ee11404ee6cfa08ee00037b0
URL:
https://github.com/llvm/llvm-project/commit/3c312e48f325c1b1ee11404ee6cfa08ee00037b0
DIFF:
https://github.com/llvm/llvm-project/commit/3c312e48f325c1b1ee11404ee6cfa08ee00037b0.diff
LOG:
Author: David Blaikie
Date: 2022-12-06T22:52:47Z
New Revision: 6ab6085c77ef9bcdabf842342f63fba4291791a4
URL:
https://github.com/llvm/llvm-project/commit/6ab6085c77ef9bcdabf842342f63fba4291791a4
DIFF:
https://github.com/llvm/llvm-project/commit/6ab6085c77ef9bcdabf842342f63fba4291791a4.diff
LOG:
Author: David Blaikie
Date: 2022-12-12T22:36:23Z
New Revision: c73876db4f2dfd2c38d5720f62509e57f23b2059
URL:
https://github.com/llvm/llvm-project/commit/c73876db4f2dfd2c38d5720f62509e57f23b2059
DIFF:
https://github.com/llvm/llvm-project/commit/c73876db4f2dfd2c38d5720f62509e57f23b2059.diff
LOG:
Author: David Blaikie
Date: 2022-12-16T23:18:11Z
New Revision: be931f89451b650e081daf875213c19f658caf25
URL:
https://github.com/llvm/llvm-project/commit/be931f89451b650e081daf875213c19f658caf25
DIFF:
https://github.com/llvm/llvm-project/commit/be931f89451b650e081daf875213c19f658caf25.diff
LOG:
Author: David Blaikie
Date: 2022-12-16T23:39:28Z
New Revision: 7a91e00d915c638bfb4864826bc445211e0e41d7
URL:
https://github.com/llvm/llvm-project/commit/7a91e00d915c638bfb4864826bc445211e0e41d7
DIFF:
https://github.com/llvm/llvm-project/commit/7a91e00d915c638bfb4864826bc445211e0e41d7.diff
LOG:
On Thu, Dec 15, 2016 at 2:18 PM Sean Callanan via Phabricator via
cfe-commits wrote:
> spyffe updated this revision to Diff 81661.
> spyffe marked 2 inline comments as done.
> spyffe added a comment.
> Herald added a subscriber: jgosnell.
>
> Applied Vassil and Vedant's comments. I will commit t
Was this change approved by anyone? Generally once it's sent for review,
you should wait until it's approved before committing (the assumption
being, if you sent it for review it's because it needed review)
On Wed, Dec 14, 2016 at 12:49 PM Amjad Aboud via Phabricator via
cfe-commits wrote:
> Thi
Test coverage?
On Tue, Dec 13, 2016 at 2:39 PM Sean Callanan via Phabricator via
cfe-commits wrote:
> spyffe retitled this revision from "Fix the linkage for
> __crashtracer_info__" to "Prepare PrettyStackTrace for LLDB adoption".
> spyffe updated the summary for this revision.
> spyffe updated
Ah, sure - no worries. Good to mention/link to the other change, etc, in
the future. (if the changes on the clang side are trivial enough to not
need review, may not need to send them out for review either - or could
include them as an addendum to the llvm change ("oh, and here's what it
looks like
I don't know much about who owns this sort of code, nor Vassil's
work/responsibility in this area - but if he's OK with it/feels able to
sign off on it, that'd be sufficient/fine by me (& others closer to it can
pipe up if he seems like not the right person to approve).
Thanks!
- Dave
On Mon, Dec
On Mon, Dec 19, 2016 at 9:39 AM Sean Callanan wrote:
> That would require making LLDB crash and collecting the relevant crash log
> data out of the user's own logs. This isn't impossible – but additionally
> the generation of that log is asynchronous and you don't quite know when
> it'll land.
>
Author: dblaikie
Date: Tue Dec 27 16:05:35 2016
New Revision: 290631
URL: http://llvm.org/viewvc/llvm-project?rev=290631&view=rev
Log:
DebugInfo: Don't include size/alignment on class declarations
This seems like it must've been a leftover by accident - no tests were
backing it up & it doesn't ma
Author: dblaikie
Date: Wed Jan 4 16:36:39 2017
New Revision: 291017
URL: http://llvm.org/viewvc/llvm-project?rev=291017&view=rev
Log:
Remove use of intrusive ref count ownership acquisition
The one use of CheckerManager (AnalysisConsumer, calling
createCheckerManager) keeps a strong reference to
Author: dblaikie
Date: Wed Jan 4 16:36:43 2017
New Revision: 291018
URL: http://llvm.org/viewvc/llvm-project?rev=291018&view=rev
Log:
Fix for LLVM Bitcode API change (to use std::shared_ptr)
Modified:
cfe/trunk/lib/Frontend/SerializedDiagnosticPrinter.cpp
cfe/trunk/lib/Frontend/TestModul
Author: dblaikie
Date: Thu Jan 5 11:26:53 2017
New Revision: 291143
URL: http://llvm.org/viewvc/llvm-project?rev=291143&view=rev
Log:
Migrate PathDiagnosticPiece to std::shared_ptr
Simplifies and makes explicit the memory ownership model rather than
implicitly passing/acquiring ownership.
Modif
Author: dblaikie
Date: Thu Jan 5 12:23:18 2017
New Revision: 291150
URL: http://llvm.org/viewvc/llvm-project?rev=291150&view=rev
Log:
Use shared_ptr instead of IntrusiveRefCntPtr for ModuleFileExtension
The intrusiveness wasn't needed here, so this simplifies/clarifies the
ownership model.
Modi
Author: dblaikie
Date: Thu Jan 5 12:45:45 2017
New Revision: 291155
URL: http://llvm.org/viewvc/llvm-project?rev=291155&view=rev
Log:
Simplify ASTReader ctor by using in-class initializers for many member variables
Modified:
cfe/trunk/include/clang/Serialization/ASTWriter.h
cfe/trunk/lib
Author: dblaikie
Date: Thu Jan 5 12:45:43 2017
New Revision: 291154
URL: http://llvm.org/viewvc/llvm-project?rev=291154&view=rev
Log:
Simplify ASTReader ctor by using in-class initializers (NSDMIs to the rest of
you) for many member variables
Modified:
cfe/trunk/include/clang/Serialization/
Author: dblaikie
Date: Thu Jan 5 12:51:54 2017
New Revision: 291156
URL: http://llvm.org/viewvc/llvm-project?rev=291156&view=rev
Log:
Move VariantMatcher's Payload to std::shared_ptr rather than IntrusiveRefCntPtr
Modified:
cfe/trunk/include/clang/ASTMatchers/Dynamic/VariantValue.h
cfe/t
Author: dblaikie
Date: Thu Jan 5 13:11:36 2017
New Revision: 291160
URL: http://llvm.org/viewvc/llvm-project?rev=291160&view=rev
Log:
Move PreprocessorOptions to std::shared_ptr from IntrusiveRefCntPtr
Modified:
cfe/trunk/include/clang/Frontend/CompilerInvocation.h
cfe/trunk/include/clan
Author: dblaikie
Date: Thu Jan 5 13:11:31 2017
New Revision: 291159
URL: http://llvm.org/viewvc/llvm-project?rev=291159&view=rev
Log:
Move FailedModulesSet over to shared_ptr from IntrusiveRefCntPtr
Modified:
cfe/trunk/include/clang/Lex/PreprocessorOptions.h
cfe/trunk/lib/Frontend/Compil
Author: dblaikie
Date: Thu Jan 5 13:48:07 2017
New Revision: 291166
URL: http://llvm.org/viewvc/llvm-project?rev=291166&view=rev
Log:
Move Preprocessor over to std::shared_ptr rather than IntrusiveRefCntPtr
Modified:
cfe/trunk/include/clang/Frontend/ASTUnit.h
cfe/trunk/include/clang/Fron
Author: dblaikie
Date: Thu Jan 5 13:48:10 2017
New Revision: 291167
URL: http://llvm.org/viewvc/llvm-project?rev=291167&view=rev
Log:
Move SerializedDiagnosticPrinter's SharedState to std::shared_ptr rather than
IntrusiveRefCntPtr
Modified:
cfe/trunk/lib/Frontend/SerializedDiagnosticPrinter
Author: dblaikie
Date: Thu Jan 5 16:19:11 2017
New Revision: 291184
URL: http://llvm.org/viewvc/llvm-project?rev=291184&view=rev
Log:
IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and
CodeCompleteConsumer
Modified:
cfe/trunk/include/clang/Frontend/ASTUnit.h
cfe/trunk/
Author: dblaikie
Date: Thu Jan 5 16:36:44 2017
New Revision: 291185
URL: http://llvm.org/viewvc/llvm-project?rev=291185&view=rev
Log:
Fix examples for recent shared_ptrification
Modified:
cfe/trunk/examples/clang-interpreter/main.cpp
Modified: cfe/trunk/examples/clang-interpreter/main.cpp
U
Author: dblaikie
Date: Thu Jan 5 16:44:07 2017
New Revision: 291186
URL: http://llvm.org/viewvc/llvm-project?rev=291186&view=rev
Log:
Fix for shared_ptrification in Clang
Modified:
clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
clang-tools-extra/trunk/include-fixer/IncludeFixer.h
Author: dblaikie
Date: Thu Jan 5 19:04:46 2017
New Revision: 291202
URL: http://llvm.org/viewvc/llvm-project?rev=291202&view=rev
Log:
shared_ptrify (from InclusiveRefCntPtr) HeaderSearchOptions
Modified:
cfe/trunk/include/clang/Frontend/ASTUnit.h
cfe/trunk/include/clang/Frontend/Compiler
Author: dblaikie
Date: Thu Jan 5 19:09:06 2017
New Revision: 291203
URL: http://llvm.org/viewvc/llvm-project?rev=291203&view=rev
Log:
Fixes for Clang API change
Modified:
clang-tools-extra/trunk/modularize/ModularizeUtilities.cpp
clang-tools-extra/trunk/modularize/ModularizeUtilities.h
Author: dblaikie
Date: Fri Jan 6 11:47:10 2017
New Revision: 291249
URL: http://llvm.org/viewvc/llvm-project?rev=291249&view=rev
Log:
Revert "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and
CodeCompleteConsumer"
Caused a memory leak reported by asan. Reverting while I inves
Author: dblaikie
Date: Fri Jan 6 11:47:19 2017
New Revision: 291251
URL: http://llvm.org/viewvc/llvm-project?rev=291251&view=rev
Log:
Revert "Fix for shared_ptrification in Clang"
The original commit caused an asan-detected memory leak in Clang.
Reverting while I investigate.
This reverts commi
Author: dblaikie
Date: Fri Jan 6 11:50:34 2017
New Revision: 291252
URL: http://llvm.org/viewvc/llvm-project?rev=291252&view=rev
Log:
Revert "Fix examples for recent shared_ptrification"
(should've rolled in to this revert of the CompilerInstance change in
the first place... anyway)
This revert
Author: dblaikie
Date: Fri Jan 6 13:49:09 2017
New Revision: 291272
URL: http://llvm.org/viewvc/llvm-project?rev=291272&view=rev
Log:
Reapply "Fix for shared_ptrification in Clang"
Aleksey Shlyapnikov pointed out the memory leak I'd introduced, so
recommitted the clang change with a fix for that
Author: dblaikie
Date: Fri Jan 6 13:49:01 2017
New Revision: 291270
URL: http://llvm.org/viewvc/llvm-project?rev=291270&view=rev
Log:
Reapply "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and
CodeCompleteConsumer"
Aleksey Shlypanikov pointed out my mistake in migrating an ex
On Fri, Jan 6, 2017 at 12:16 PM Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ericwf
> Date: Fri Jan 6 14:05:40 2017
> New Revision: 291275
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291275&view=rev
> Log:
> [libc++] Cleanup and document <__threading_support>
Thanks!
On Fri, Jan 6, 2017 at 3:26 PM Eric Fiselier wrote:
> Should be fixed in r291298. Sorry for the breakage.
>
> /Eric
>
> On Fri, Jan 6, 2017 at 4:18 PM, Eric Fiselier wrote:
>
> Hi David,
>
> Thanks for the information. Looking into it now.
>
> /Eric
>
> On Fri, Jan 6, 2017 at 4:02 PM, D
Alternatively could make the bool ctor a template with some SFINAE to
restrict it to only parameters of type bool - thus blocking all conversions
there, if they're particularly problematic.
On Wed, Jan 4, 2017 at 5:32 PM George Burgess IV via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Aut
I started the llvm-dev thread for the instruction location tradeoffs
(removing the location from instructions to improve profiling support -
possibly at the cost of other debug info consumers).
The motivation for this flag is different - for added functionality that's
generally (imho/based on conv
dblaikie added inline comments.
Comment at: lib/AST/DeclBase.cpp:1810-1812
@@ +1809,5 @@
+ void VisitNamedDecl(const NamedDecl *D) {
+if (IdentifierInfo *II = D->getIdentifier()) {
+ ID.AddString(II->getName());
+}
+Inherited::VisitNamedDecl(D);
dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.
Consider renaming and/or generalizing the handlers.
Also, in a follow-up or preliminary commit, could you remove all the DerefFun
stuff. Move the definition of CGdereference (if they remai
Author: dblaikie
Date: Mon Aug 22 12:49:50 2016
New Revision: 279444
URL: http://llvm.org/viewvc/llvm-project?rev=279444&view=rev
Log:
Remove redundant test
test/CodeGenCXX/debug-info-zero-length-arrays.cpp tests this
functionality more comprehensively
Removed:
cfe/trunk/test/CodeGenCXX/debu
Author: dblaikie
Date: Mon Aug 22 12:49:56 2016
New Revision: 279445
URL: http://llvm.org/viewvc/llvm-project?rev=279445&view=rev
Log:
PR29086: DebugInfo: Improve support for fixed array dimensions in variable
length arrays
Added:
cfe/trunk/test/CodeGenCXX/debug-info-vla.cpp
Modified:
cf
dblaikie added a comment.
Not all of these already had NodeRef implemented - that implies that some
algorithms weren't using NodeRef before this change, or that these traits are
unused? I thought the plan was to migrate each algorithm then just do a strict
cleanup. Did that not pan out/some oth
dblaikie added a comment.
In https://reviews.llvm.org/D23730#522501, @timshen wrote:
> In https://reviews.llvm.org/D23730#522396, @dblaikie wrote:
>
> > Not all of these already had NodeRef implemented - that implies that some
> > algorithms weren't using NodeRef before this change, or that thes
dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.
Or it isn't approved (was mixing up reviews) - but now it is...
https://reviews.llvm.org/D23730
___
cfe-commits mailing list
cfe-commits@list
601 - 700 of 1480 matches
Mail list logo
