On Fri, Mar 18, 2016 at 6:31 AM, Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: d0k
> Date: Fri Mar 18 08:31:00 2016
> New Revision: 263785
>
> URL: http://llvm.org/viewvc/llvm-project?rev=263785&view=rev
> Log:
> Make LookupResult movable again.
>
This shouldn't'v
On Wed, Mar 16, 2016 at 11:38 AM, don hinton via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> hintonda updated this revision to Diff 50843.
> hintonda added a comment.
>
> Added FIXME comment, and reformated with clang-format.
>
>
> http://reviews.llvm.org/D18123
>
> Files:
> include/clang
Author: dblaikie
Date: Thu Mar 17 13:28:16 2016
New Revision: 263732
URL: http://llvm.org/viewvc/llvm-project?rev=263732&view=rev
Log:
Remove defaulted move ops, the type is zero-cost copyable anyway, so there's no
need for specific move ops
(addresses MSVC build error, since MSVC 2013 can't gen
On Fri, Mar 18, 2016 at 11:08 AM, Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> rnk added a comment.
>
> I'm not sure your example is in scope for -Wshadow, though. Any function
> call that takes a non-const reference to the parameter could modify it.
Sure - my argument is
This revision was automatically updated to reflect the committed changes.
Closed by commit rL263730: Fix implicit copy ctor and copy assignment operator
warnings when… (authored by dblaikie).
Changed prior to commit:
http://reviews.llvm.org/D18123?vs=50930&id=50961#toc
Repository:
rL LLVM
h
dblaikie added a comment.
Not sure I fully understand the issue with the existing diagnostic/change in
wording.
'::' is a nested name specifier, even if it's a degenerate case, I think - so
the old wording doesn't seem wrong, as such (& the new text seems correct in
the other cases too - shoul
On Wed, Mar 16, 2016 at 7:54 AM, don hinton via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> hintonda updated this revision to Diff 50823.
> hintonda added a comment.
>
> Address FIXME now that Sema::LookupInlineAsmField() has been fixed.
>
>
> http://reviews.llvm.org/D18123
>
> Files:
> i
On Wed, Mar 16, 2016 at 10:19 AM, don hinton wrote:
> The current behavior, albeit deprecated, is to implicitly define these.
> Therefore, it would be incorrect not to delete them if the implicit
> versions don't do the right thing.
>
> I'd be happy to add a FIXME, but I doubt they will ever be r
Also might be marginally tidier if Paths was a unique_ptr, then you
wouldn't have to explicitly null it out.
I think this is still a pretty subtle thing to allow move or copy support
for & perhaps best avoided, or split into the query parameters and the
result if we're going to support it.
For ex
On Wed, Mar 16, 2016 at 10:52 AM, don hinton wrote:
> -Werror clean is great.
>
> If you could add -Wdeprecated, then we wouldn't need to delete them -- the
> warning is only issued with -Wdeprecated is passed.
>
Right, that's what I'm saying - add a fixme so that once we turn on the
deprecated
ovable parts - but I can't see any
evidence of that). Added explicit (empty) move ops in r263747
>
> thanks...
> don
>
> On Thu, Mar 17, 2016 at 2:28 PM, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dblaikie
>> Date: Thu
dblaikie added a subscriber: dblaikie.
dblaikie added a comment.
It's not just modifications of shadowed variables that are a problem - one of
the one's I'm concerned we should catch is:
struct foo {
std::unique_ptr p;
foo(std::unique_ptr p) : p(std::move(p)) {
f(*p);
}
};
+Lang, because he was asking me recently about this improvement & thinking
of chipping in
On Fri, Mar 18, 2016 at 10:56 AM, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> dblaikie added a subscriber: dblaikie.
> dblaikie added a comment.
>
> It'
On Tue, Mar 15, 2016 at 11:26 AM, John McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> rjmccall added a comment.
>
> Ignore Dave and fix the problem, please. :)
>
+1, sorry for the race on review.
>
>
> Repository:
> rL LLVM
>
> http://reviews.llvm.org/D18175
>
>
>
> ___
dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.
Looks good - thanks!
Repository:
rL LLVM
http://reviews.llvm.org/D18175
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lis
On Mon, Mar 14, 2016 at 3:30 PM, don hinton wrote:
>
>
> On Mon, Mar 14, 2016 at 6:24 PM, David Blaikie wrote:
>
>>
>>
>> On Mon, Mar 14, 2016 at 3:07 PM, don hinton wrote:
>>
>>> UnresolvedSetImpl isn't even constructible, much less copy
>>> constructible, but it is a public base class to Unre
On Mon, Mar 14, 2016 at 3:07 PM, don hinton wrote:
> UnresolvedSetImpl isn't even constructible, much less copy constructible,
> but it is a public base class to UnresolvedSet, it it is -- at least until
> we turn it off by deleting the copy ctor.
>
> template class UnresolvedSet :
> public
UNresolvedSetImpl isn't copy constructible, so should it really be copy
assignable? (it looks like it only needs to be so because of LookupResult -
so once LookupResult is fixed, UnresolvedSetImpl can go back to the way it
was)
Perhaps we should just wait for the fix for LookupResult copying in
Se
On Mon, Mar 14, 2016 at 8:55 AM, Evgenii Stepanov
wrote:
> On Mon, Mar 14, 2016 at 8:48 AM, Benjamin Kramer
> wrote:
> > On Mon, Mar 14, 2016 at 3:59 PM, David Blaikie
> wrote:
> >> Yeah - how are they relying on them in a non-asserts build anyway?
> (were we
> >> naming certain things regardle
Yeah - how are they relying on them in a non-asserts build anyway? (were we
naming certain things regardless of +/-Asserts? (well, I know we were
naming some things, but mostly down in LLVM, I thought Clang generally used
the IRBuilder & thus didn't name things in non-Asserts builds))
On Mon, Mar
Interesting question going forwards: We usually try to make test cases
+/-Asserts agnostic (not using named values), now that we have a flag for
it, should we not bother with that & just add the command line argument to
enable names when names make testing easier? Or do we think that'll make
tests
On Sat, Mar 12, 2016 at 3:42 PM, don hinton via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> hintonda created this revision.
> hintonda added a reviewer: rjmccall.
> hintonda added a subscriber: cfe-commits.
>
> Fix implicit copy ctor and copy assignment operator warnings
> when -Wdeprecated
On Fri, Mar 11, 2016 at 4:14 PM, Bob Wilson via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> I’m not sure how to interpret that. It says: "Clang must recover from
> errors as if the fix-it had been applied.” I suppose that format-security
> could be an error if you’re building with -Werror,
Not sure if it's worth it, but you might be able to abort the loop if you
ever reach a namespace (or anything that's not a tag decl maybe? Not sure
about function local types)
On Thu, Mar 10, 2016 at 4:09 PM, Adrian Prantl wrote:
>
> On Mar 10, 2016, at 3:21 PM, David Blaikie wrote:
>
> OK, so
OK, so the idea is that when you see that a tag definition, skip it if any
parent is incomplete - because when the parent's definition is complete,
you'll emit all its children anyway?
On Thu, Mar 10, 2016 at 8:19 AM, Adrian Prantl wrote:
>
> > On Mar 9, 2016, at 5:22 PM, David Blaikie wrote:
>
Is this bug only reachable with modules debug info?
Could you describe the nature of the fix (not quite clear to me just by
looking at it)
On Mon, Mar 7, 2016 at 12:58 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: adrian
> Date: Mon Mar 7 14:58:52 2016
> New Re
On Wed, Mar 9, 2016 at 11:58 AM, Alexander Riccio via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> ariccio added a comment.
>
> In http://reviews.llvm.org/D17983#370717, @dblaikie wrote:
>
> > Initializations we never expect to use (eg because we have a covered
> switch
> > that initializes
On Wed, Mar 9, 2016 at 12:06 PM, Alexander Riccio via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> ariccio added a comment.
>
> Oh, and by the way, what's the policy on using `enum class`es instead of C
> style enums? I bet the compiler would have fewer false positives with
> strongly typed
On Mar 9, 2016 8:18 AM, "Teresa Johnson" wrote:
>
>
>
> On Wed, Mar 9, 2016 at 8:13 AM, David Blaikie wrote:
>>
>>
>> On Mar 9, 2016 8:11 AM, "Teresa Johnson via llvm-commits" <
llvm-comm...@lists.llvm.org> wrote:
>> >
>> > tejohnson added a subscriber: tejohnson.
>> > tejohnson added a comment.
On Mar 9, 2016 8:11 AM, "Teresa Johnson via llvm-commits" <
llvm-comm...@lists.llvm.org> wrote:
>
> tejohnson added a subscriber: tejohnson.
> tejohnson added a comment.
>
> Thanks for doing this!
>
> I will fix these 3, which one of my changes would have provoked. It is a
benign case since we do h
I think we had a discussion about this before.
Clang has a few versions of this warning. One version is probably as
aggressive as the warning you are trying to quiet (-Wmaybe-uninitialized)
and we made a deliberate choice not to enable it for the project. I think
we should probably make the same c
dblaikie added a subscriber: dblaikie.
dblaikie added a comment.
I think we had a discussion about this before.
Clang has a few versions of this warning. One version is probably as
aggressive as the warning you are trying to quiet (-Wmaybe-uninitialized)
and we made a deliberate choice not to ena
This revision was automatically updated to reflect the committed changes.
Closed by commit rL262752: PR5941 - improve diagnostic for * vs & confusion
when choosing overload… (authored by dblaikie).
Changed prior to commit:
http://reviews.llvm.org/D16949?vs=49577&id=49856#toc
Repository:
rL L
Author: dblaikie
Date: Fri Mar 4 16:29:11 2016
New Revision: 262752
URL: http://llvm.org/viewvc/llvm-project?rev=262752&view=rev
Log:
PR5941 - improve diagnostic for * vs & confusion when choosing overload
candidate with a parameter of incomplete (ref or pointer) type
Reviewers: dblaikie
Diffe
On Wed, Mar 2, 2016 at 10:36 AM, Benjamin Kramer
wrote:
> In theory yes, in practice that needs a bit of build system tweaking
> to either build clang-tidy into clang or as a shared library. Then it
> can be used like any regular Clang plugin.
>
I haven't looked at this patch in detail - soundds
Would this also be usable as a way to run clang-tidy checks as part of
normal compilation? (some things in clang-tidy aren't there because the FP
is too high to be a hard error on old codebases (but might be viable once a
codebase is able to be cleaned up (like several have been with LLVM)) or
beca
dblaikie accepted this revision.
dblaikie added a reviewer: dblaikie.
dblaikie added a comment.
This revision is now accepted and ready to land.
Looks great - thanks!
http://reviews.llvm.org/D16949
___
cfe-commits mailing list
cfe-commits@lists.llvm
dblaikie added a comment.
Are there not any existing cases that test this diagnostic?
Could you just update some existing cases to cover this? (it looks like, in the
same file, the test case added for PR 6117 could be expanded to test this as
well, perhaps?) It looks like that's the original te
Any way to/would it be worth broadening this with an annotation or some
such (or just a lost for now) of types that maintain references to their
ctor params? (Eg: llvm arrayref, etc)
On Mar 1, 2016 9:19 AM, "Jonathan B Coe via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:
> jbcoe created this
dblaikie added a subscriber: dblaikie.
dblaikie added a comment.
Any way to/would it be worth broadening this with an annotation or some
such (or just a lost for now) of types that maintain references to their
ctor params? (Eg: llvm arrayref, etc)
Repository:
rL LLVM
http://reviews.llvm.org/D
On Mon, Feb 29, 2016 at 8:34 PM, Argyrios Kyrtzidis
wrote:
> This is to reduce stack usage, whether it hits stack overflow or not is
> highly dependent on configuration.
> I've tried forcing smaller stack on the specific test
> (test/Index/index-many-call-ops.cpp) but then it can hit stack overfl
Does this change any behavior? (missing test case?)
On Mon, Feb 29, 2016 at 6:46 PM, Argyrios Kyrtzidis via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: akirtzidis
> Date: Mon Feb 29 20:46:32 2016
> New Revision: 262290
>
> URL: http://llvm.org/viewvc/llvm-project?rev=262290&view=re
On Mon, Feb 29, 2016 at 11:19 AM, Justin Lebar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> > Can you expand on this? The idea is that those implicit deps are in
> addition to regular dependencies, not a replacement.
>
> Sure.
>
> What I was trying to say is, suppose you have two CUDA de
On Tue, Feb 16, 2016 at 10:45 PM, David Blaikie wrote:
>
>
> On Tue, Feb 16, 2016 at 10:01 PM, Ryan Yee via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> ryee88 updated this revision to Diff 48149.
>> ryee88 added a comment.
>>
>> Keeping the number of test files to a minimum makes sens
Seems like this test got flagged as 'slow' by Google's internal
infrastructure - and that makes me wonder about whether it's appropriate to
have in the lit test suite - we really want to keep these tests as fast as
possible.
I think we're generally OK committing iterator invalidation fixes without
On Tue, Feb 23, 2016 at 1:02 PM, Nico Weber wrote:
> On Tue, Feb 23, 2016 at 3:55 PM, David Blaikie wrote:
>
>>
>>
>> On Tue, Feb 23, 2016 at 12:46 PM, Nico Weber wrote:
>>
>>> On Tue, Feb 23, 2016 at 2:44 PM, David Blaikie via cfe-commits
On Tue, Feb 23, 2016 at 12:46 PM, Nico Weber wrote:
> On Tue, Feb 23, 2016 at 2:44 PM, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Feb 23, 2016 at 11:30 AM, Nico Weber via cfe-commits <
>> cfe-commits@lists.llv
On Tue, Feb 23, 2016 at 11:30 AM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: nico
> Date: Tue Feb 23 13:30:43 2016
> New Revision: 261674
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261674&view=rev
> Log:
> Rename Action::begin() to Action::input_begin().
>
> Al
On Tue, Feb 23, 2016 at 2:29 AM, Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: alexfh
> Date: Tue Feb 23 04:29:04 2016
> New Revision: 261626
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261626&view=rev
> Log:
> Fix a -Wunused-variable diagnostic.
>
> Modif
On Fri, Feb 19, 2016 at 11:10 AM, Eugene Zelenko
wrote:
> On Fri, Feb 19, 2016 at 11:06 AM, David Blaikie
> wrote:
> >
> > Could we take this conversation back to the list? (better to discuss
> things
> > with everyone)
> >
> > On Fri, Feb 19, 2016 at 11:02 AM, Eugene Zelenko <
> eugene.zele...@
On Fri, Feb 19, 2016 at 10:38 AM, Eugene Zelenko
wrote:
> On Fri, Feb 19, 2016 at 10:32 AM, David Blaikie
> wrote:
> >
> >
> > On Fri, Feb 19, 2016 at 10:25 AM, Eugene Zelenko via cfe-commits
> > wrote:
> >>
> >> Eugene.Zelenko added a comment.
> >>
> >> Also I agree that testing is good idea,
On Fri, Feb 19, 2016 at 10:25 AM, Eugene Zelenko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Eugene.Zelenko added a comment.
>
> Also I agree that testing is good idea, it doesn't make sense in current
> incarnation which test only vector and set and only with containers' code
> snippet
should probably have test coverage
On Thu, Feb 18, 2016 at 6:46 PM, Eugene Zelenko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Eugene.Zelenko created this revision.
> Eugene.Zelenko added reviewers: alexfh, xazax.hun, aaron.ballman.
> Eugene.Zelenko added a subscriber: cfe-commits.
> E
Thanks all! Which compiler flagged this? Wonder if/why Clang didn't flag it
for me?
On Thu, Feb 18, 2016 at 5:27 AM, Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL261207: Add parent
On Tue, Feb 16, 2016 at 10:01 PM, Ryan Yee via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> ryee88 updated this revision to Diff 48149.
> ryee88 added a comment.
>
> Keeping the number of test files to a minimum makes sense.
>
> Couldn't find an existing test for this diagnostic.
That woul
Is this anything more than the -Wdeprecated warning? (could we split out
the -Wdeprecated warning that deals with the deprecated implicit special
member generation, then just use that warning for this clang-tidy check?)
On Thu, Feb 11, 2016 at 3:16 PM, Jonathan B Coe via cfe-commits <
cfe-commits@
dblaikie added a comment.
Thanks - please commit when ready
http://reviews.llvm.org/D15977
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Since this is just a wording change, presumably the diagnostic is already
tested in an existing file - perhaps you could exetendi that test to cover
this functionality (we try not to add new test files too much - better to
test functionality once/in one place as much as possible (both for ease of
r
On Thu, Feb 11, 2016 at 8:03 AM, Cong Liu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: congliu
> Date: Thu Feb 11 10:03:27 2016
> New Revision: 260532
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260532&view=rev
> Log:
> Merge branch 'arcpatch-D16922'
>
Please be sure to che
dblaikie added a subscriber: dblaikie.
dblaikie added a comment.
Needs test coverage
http://reviews.llvm.org/D16949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
It's best not to commit things without approval once they've been sent for
review (the assumption being that if you asked for review it's because the
change needed review - time doesn't change that fact) - if approval was
given off-list (eg: on IRC) it's best to mention who gave it & where (&
ideal
On Tue, Feb 9, 2016 at 12:07 PM, David Li via llvm-commits <
llvm-comm...@lists.llvm.org> wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL260270: [PGO] Fix issue: explicitly defaulted assignop
> is not profiled (authored by davidxl).
>
In ge
dblaikie added inline comments.
Comment at: cfe/trunk/test/Profile/def-assignop.cpp:27
@@ +26,3 @@
+
+int main() {
+ A a1, a2;
This doesn't need to be main or have an int return. Just make it a void
function (with some generic name) & drop the "return 0" to keep
On Tue, Feb 9, 2016 at 11:41 AM, Xinliang David Li
wrote:
> On Tue, Feb 9, 2016 at 11:30 AM, David Blaikie wrote:
> >
> >
> > On Tue, Feb 9, 2016 at 11:26 AM, Xinliang David Li
> > wrote:
> >>
> >> On Tue, Feb 9, 2016 at 11:14 AM, David Blaikie
> wrote:
> >> >
> >> >
> >> > On Mon, Feb 8, 2016
On Tue, Feb 9, 2016 at 11:26 AM, Xinliang David Li
wrote:
> On Tue, Feb 9, 2016 at 11:14 AM, David Blaikie wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 9:23 PM, Xinliang David Li
> > wrote:
> >>
> >> Wrong in the sense the the coverage result for the default operators
> >> (the line where they are
On Mon, Feb 8, 2016 at 9:23 PM, Xinliang David Li
wrote:
> Wrong in the sense the the coverage result for the default operators
> (the line where they are declared) is marked as if they are not called
> which can be confusing to the user.
>
Presumably a user would have the same problem with impl
Author: dblaikie
Date: Tue Feb 9 12:52:09 2016
New Revision: 260246
URL: http://llvm.org/viewvc/llvm-project?rev=260246&view=rev
Log:
Simplify EnterTokenStream API to make it more robust for memory management
While this won't help fix things like the bug that r260219 addressed, it
seems like goo
On Mon, Feb 8, 2016 at 9:00 PM, Xinliang David Li
wrote:
> On Mon, Feb 8, 2016 at 8:46 PM, David Blaikie wrote:
> >
> > On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li
> > wrote:
> >>
> >> I took a look at the problem. The implicitly defaulted operators
> >> should not be instrumented as spec
On Mon, Feb 8, 2016 at 7:39 PM, Xinliang David Li
wrote:
> I took a look at the problem. The implicitly defaulted operators
> should not be instrumented as specified -- I actually I just added the
> new test case for that (checking profile counter not generated) right
> after my previous reply an
FWIW, I tried to do something like this, perhaps with some other
improvements, a few years ago. Not sure if things have changed for the
better since then, but maybe those old patches may provide some
insight/other improvements/options:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-201409
On Mon, Feb 8, 2016 at 5:05 PM, Xinliang David Li
wrote:
> ha! somehow I kept thinking you are referring to implicit declared ctors.
>
Ah, glad we figured out the disconnect - thanks for bearing with me!
>
> From your test case, it is seems that the implicit copy/move op is
> also broken and i
On Mon, Feb 8, 2016 at 4:31 PM, Xinliang David Li
wrote:
> On Mon, Feb 8, 2016 at 4:05 PM, David Blaikie wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 3:58 PM, Xinliang David Li
> > wrote:
> >>
> >> To be clear, you are suggesting breaking the test into two (one for
> >> copy, and one for move) ? I
On Mon, Feb 8, 2016 at 3:58 PM, Xinliang David Li
wrote:
> To be clear, you are suggesting breaking the test into two (one for
> copy, and one for move) ? I am totally fine with that.
Nah, no need to split the test case - we try to keep the number of test
files down (& group related tests into
On Mon, Feb 8, 2016 at 3:46 PM, Xinliang David Li
wrote:
> On Mon, Feb 8, 2016 at 3:35 PM, David Blaikie wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 3:21 PM, Xinliang David Li
> > wrote:
> >>
> >> On Mon, Feb 8, 2016 at 3:17 PM, David Blaikie
> wrote:
> >> >
> >> >
> >> > On Mon, Feb 8, 2016 at
On Mon, Feb 8, 2016 at 3:21 PM, Xinliang David Li
wrote:
> On Mon, Feb 8, 2016 at 3:17 PM, David Blaikie wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 12:07 PM, Xinliang David Li
> > wrote:
> >>
> >> On Mon, Feb 8, 2016 at 11:39 AM, David Blaikie
> wrote:
> >> >
> >> >
> >> > On Mon, Feb 8, 2016 a
On Mon, Feb 8, 2016 at 12:07 PM, Xinliang David Li
wrote:
> On Mon, Feb 8, 2016 at 11:39 AM, David Blaikie wrote:
> >
> >
> > On Mon, Feb 8, 2016 at 9:25 AM, David Li via llvm-commits
> > wrote:
> >>
> >> davidxl updated this revision to Diff 47217.
> >> davidxl added a comment.
> >>
> >> Simpl
Thanks for fixing this!
On Sun, Feb 7, 2016 at 1:32 PM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: nico
> Date: Sun Feb 7 15:32:17 2016
> New Revision: 260058
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260058&view=rev
> Log:
> Make nozlibcompress.c pass and r
ah, right, sorry about that - gmail didn't render cfe-commits on the to
line in the first email... weird.
Anyway, no need to include llvm-commits on clang-only changes.
On Mon, Feb 8, 2016 at 11:30 AM, Xinliang David Li
wrote:
> Both cfe-commits and llvm-commits are cc'ed.
>
> David
>
> On Mon,
On Mon, Feb 8, 2016 at 9:25 AM, David Li via llvm-commits <
llvm-comm...@lists.llvm.org> wrote:
> davidxl updated this revision to Diff 47217.
> davidxl added a comment.
>
> Simplified test case suggested by Vedant.
>
>
> http://reviews.llvm.org/D16947
>
> Files:
> lib/CodeGen/CGClass.cpp
> te
This looks like a change to clang - could you test it in clang (& review it
on cfe-commits instead of llvm-commits)?
On Sat, Feb 6, 2016 at 11:57 AM, David Li via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> davidxl created this revision.
> davidxl added a reviewer: vsk.
> davidxl added sub
On Mon, Feb 8, 2016 at 11:14 AM, Xinliang David Li via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: davidxl
> Date: Mon Feb 8 13:14:14 2016
> New Revision: 260126
>
> URL: http://llvm.org/viewvc/llvm-project?rev=260126&view=rev
> Log:
> Simplify test cases
>
It's handy to mention t
On Wed, Feb 3, 2016 at 1:40 PM, Aaron Ballman
wrote:
> On Wed, Feb 3, 2016 at 4:13 PM, David Blaikie wrote:
> >
> >
> > On Wed, Feb 3, 2016 at 1:03 PM, Jonathan Coe wrote:
> >>
> >>
> >>
> >> On 3 February 2016 at 18:44, David Blaikie wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Feb 3, 2016 at 10:23
On Wed, Feb 3, 2016 at 1:03 PM, Jonathan Coe wrote:
>
>
> On 3 February 2016 at 18:44, David Blaikie wrote:
>
>>
>>
>> On Wed, Feb 3, 2016 at 10:23 AM, Jonathan Coe wrote:
>>
>>> All the C++ compilers I have tried using (GCC,Clang,MSVC) will generate
>>> assignment operators even if the user de
On Wed, Feb 3, 2016 at 10:23 AM, Jonathan Coe wrote:
> All the C++ compilers I have tried using (GCC,Clang,MSVC) will generate
> assignment operators even if the user defines a copy-constructor. This is
> the behaviour I set out to write a check for.
>
> The cpp core guide lines recommend definin
Is this really that useful of a rule? The language does the right thing for
the most part already (you don't need to explicitly delete them - they're
implicitly deleted if you define any others - except for backcompat with
C++98, but those cases are deprecated & we should probably split out the
war
dblaikie added a comment.
Looks good - though you could do that one further simplification to the test
case, I think. (removing x/if x)
Comment at: test/CodeGenCXX/debug-info-lb.cpp:5
@@ +4,3 @@
+ static int bar = 1;
+ if (x)
+ {
Looks like you could remove
On Tue, Feb 2, 2016 at 11:11 AM, Rafael Espíndola <
cfe-commits@lists.llvm.org> wrote:
> Out of curiosity, what technique were you using to find out if the
> headers were self-contained? Just "clang -c foo.h"?
>
Building LLVM & Clang with C++ modules enabled
>
> Cheers,
> Rafael
>
>
> On 2 Febr
On Sat, Jan 30, 2016 at 9:00 AM, Vassil Vassilev
wrote:
> AFAICT the making a test case independent on STL is the hard part. I think
> it will be always failing due to the relocation of the memory region of the
> underlying SmallVector.
>
Sorry, I think I didn't explain myself well. What I mean
Yeah, it's good to have a reproduction, but I wouldn't actually commit one
- unless you have a checked stl to test against that always fails on
possibly-invalidating sequences of operations, then you'd have a fairly
simple reproduction
On Jan 30, 2016 8:23 AM, "Vassil Vassilev" wrote:
> Sorry.
>
It might be handy to give an overview of the issue in the review (&
certainly in the commit) message rather than only citing the bug number
On Jan 30, 2016 6:49 AM, "Vassil Vassilev via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:
> Attaching a fix to https://llvm.org/bugs/show_bug.cgi?id=262
dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.
Looks good to me. Test case could be simplified a bit further, but feel free to
commit after that.
Comment at: lib/CodeGen/CGDebugInfo.cpp:1479
@@ +1478,3 @@
+void CGDebu
Richard Smith: Is there a reasonable way to get the ')' of an "if ()"
expression in the AST? Is it just a matter of going down and playing games
with source locations/lexing to get the token after the end location of the
condition expression?
On Thu, Jan 28, 2016 at 4:57 PM, Wolfgang Pieb via cfe-
+Adrian for Apple/LLDB perspective
One way to merge the tests would be to add another command line argument
into DwarfDebug (see the way the split-dwarf command line argument is
used), just for testing purposes. The command line argument can override
the value specified in the metadata - so you ca
Test case?
On Thu, Jan 28, 2016 at 1:28 AM, Yury Gribov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ygribov
> Date: Thu Jan 28 03:28:18 2016
> New Revision: 259031
>
> URL: http://llvm.org/viewvc/llvm-project?rev=259031&view=rev
> Log:
> Fix isBeforeInTranslationUnit to not abo
dblaikie added a comment.
Fair question on overloaded operators... Taking the original code:
1: int main() {
2: if (
3: tr()
4: &&
5: tr()
6: )
7: func();
8: if (
9: fa()
10: &&
11: tr()
12: )
13: func();
14: }
& making tr/fa return a user defined type with a
I don't fully understand your explanation. Is your change introducing a
memory leak? (or was the old code causing a double free (if
EnterTokenStream does take ownership of this argument)in addition to
use-after-free?)
On Tue, Jan 26, 2016 at 2:45 AM, Dmitry Polukhin via cfe-commits <
cfe-commits@l
On Mon, Jan 25, 2016 at 6:20 PM, Eugene Zelenko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Eugene.Zelenko created this revision.
> Eugene.Zelenko added reviewers: alexfh, aaron.ballman.
> Eugene.Zelenko added a subscriber: cfe-commits.
> Eugene.Zelenko set the repository for this revis
On Fri, Jan 22, 2016 at 9:43 AM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: adrian
> Date: Fri Jan 22 11:43:43 2016
> New Revision: 258507
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258507&view=rev
> Log:
> Module Debugging: Use a nonzero DWO id for precompi
dblaikie added inline comments.
Comment at: lib/CodeGen/CGDebugInfo.cpp:1479
@@ +1478,3 @@
+void CGDebugInfo::recordDeclarationLexicalScope(const Decl &D) {
+ assert(LexicalBlockMap.find(&D) == LexicalBlockMap.end() &&
+ "D is already mapped to lexical block scope");
On Tue, Jan 19, 2016 at 4:04 PM, Adrian Prantl wrote:
>
> On Jan 19, 2016, at 3:52 PM, David Blaikie wrote:
>
>
>
> On Tue, Jan 19, 2016 at 3:42 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: adrian
>> Date: Tue Jan 19 17:42:53 2016
>> New Revision: 258251
1101 - 1200 of 1427 matches
Mail list logo
