Reid - is this intended fallout? (seems plausible, but just checking)
Is MinGW a good analogy for any of this work? (does it produce DWARF? Does
it use the Windows ABI? Does it emit Calling Convention attributes?)
On Thu, Jun 9, 2016 at 3:06 AM, NAKAMURA Takumi via cfe-commits <
cfe-commits@lists
Excuse the necromancy, but do you know if this change (or other work you
did in this area) completely eclipsed LLVM's use of inferred alignment via
the llvm struct's alignment for byval arguments?
I ask because this was something I was going to need to fix for the
typeless pointer work & I have so
That was certainly one of the counterarguments (& global variables also use
a type rather than a size). I've not really settled on which way to
go/haven't given it lots of thought. I may loop back around to the original
thread when it comes to that.
On Fri, Jun 10, 2016 at 2:18 PM, James Y Knight
As for the original change proposed: My guiding principle would be "do
whatever std::vector does". (& that's what I did when implementing GDB
pretty printers for SmallVector/SmallString/ArrayRef, etc... )
An aside: We generally don't do time limited reviews like this. Either
something needs review
On Mon, Jun 13, 2016 at 8:55 AM, Michael Spertus wrote:
> Hi David,
> While I understand the initial reasoning. I have found that this is like a
> hundred times better for working on Clang in practice and can't imagine
> working without it. The point is that many Clang data structures contain
> S
On Wed, Jun 15, 2016 at 10:59 AM, Reid Kleckner wrote:
> On Thu, Jun 9, 2016 at 8:59 AM, David Blaikie wrote:
>
>> Reid - is this intended fallout? (seems plausible, but just checking)
>>
>> Is MinGW a good analogy for any of this work? (does it produce DWARF?
>> Does it use the Windows ABI? Doe
dblaikie accepted this revision.
dblaikie added a comment.
Sure, looks good - thanks. Will discuss the broader test issues
later/separately.
http://reviews.llvm.org/D19754
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.or
I can't remember the rules - but wouldn't this produce UB on a signed char
platform in the case where Ch is negative? (or is that just unspecified?
implementation defined?)
On Wed, Jun 15, 2016 at 7:30 PM, George Burgess IV via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: gbiv
> Dat
ah, rightio - thanks for the reminder!
On Thu, Jun 16, 2016 at 10:44 AM, George Burgess IV <
george.burgess...@gmail.com> wrote:
> I don't think so -- 4.7p2 says "If the destination type is unsigned, the
> resulting value is the least unsigned integer congruent to the source
> integer (modulo 2 n
Yeah - is this necessary for CodeView? (does something break, or do you
just get simple names where you'd prefer full mangled or qualified names)
It was chosen pretty deliberately to do it this way (use unqualified names)
for gmlt to keep size down. Have you got numbers for the size delta for
Code
This may cause problems for DWARF type unit consistency...
Under what conditions do nested types appear in the member list? (my simple
test case on a fresh clang didn't seem to produce anything about the nested
type: struct outer { struct inner { int i; }; int j; }; outer o; )
On Wed, Jul 6, 2016
Ah, I see why I might not've seen the result - it was reverted & I didn't
spot the revert in a quick search for r274628 (because it was quoted as
rL because Phab is weird and likes to put an "L" in there).
On Thu, Jul 7, 2016 at 4:03 PM, David Blaikie wrote:
> This may cause problems for DWA
On Wed, Jul 6, 2016 at 2:07 PM, David Majnemer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: majnemer
> Date: Wed Jul 6 16:07:53 2016
> New Revision: 274677
>
> URL: http://llvm.org/viewvc/llvm-project?rev=274677&view=rev
> Log:
> [CodeGen, DebugInfo] Use hasLocalLinkage instead
On Thu, Jul 7, 2016 at 4:22 PM, Adrian McCarthy wrote:
> This patch was reverted because it breaks a test on the buildbots (that
> I've been unable to reproduce locally), so that's why you didn't seen
> anything. I'll try again to land the patch once I can fix and verify that
> test.
>
> This pa
On Thu, Jul 7, 2016 at 4:10 PM, Reid Kleckner wrote:
> On Thu, Jul 7, 2016 at 3:45 PM, David Blaikie wrote:
>
>> Yeah - is this necessary for CodeView? (does something break, or do you
>> just get simple names where you'd prefer full mangled or qualified names)
>>
>> It was chosen pretty deliber
On Fri, Jul 8, 2016 at 1:04 PM, Nico Weber wrote:
> On Fri, Jul 8, 2016 at 3:57 PM, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>>
>> On Thu, Jul 7, 2016 at 4:10 PM, Reid Kleckner wrote:
>>
>>> On Thu, Jul 7, 2016 at
On Mon, Jul 11, 2016 at 1:05 PM, Reid Kleckner wrote:
> On Mon, Jul 11, 2016 at 10:35 AM, David Blaikie
> wrote:
>>
>> I believe so, but don't have specific numbers. Alexey made this choice
>> when it was originally implemented & I believe had the data back then.
>>
>
> I don't think we made an
On Tue, Jul 12, 2016 at 3:51 PM David Majnemer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On Tue, Jul 12, 2016 at 2:55 PM, Robinson, Paul
> wrote:
>
>> A declaration that gets used within the CU generally does get a
>> debug-info description.
>>
>
> It does except if it is a static da
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
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 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
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
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 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
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
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
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
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
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
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
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
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
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 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 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
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
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:
>
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
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,
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
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
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
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
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 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
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
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 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
>
>
>
> ___
+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'
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);
}
};
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
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
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: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
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
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
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
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
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 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
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
Author: dblaikie
Date: Thu Mar 17 15:45:38 2016
New Revision: 263747
URL: http://llvm.org/viewvc/llvm-project?rev=263747&view=rev
Log:
Re-add (user defined) move ops to UnresolvedSetImpl to allow UnresolvedSet to
be implicitly movable
Modified:
cfe/trunk/include/clang/AST/UnresolvedSet.h
Mo
Author: dblaikie
Date: Thu Mar 17 13:05:07 2016
New Revision: 263730
URL: http://llvm.org/viewvc/llvm-project?rev=263730&view=rev
Log:
Fix implicit copy ctor and copy assignment operator warnings when -Wdeprecated
passed.
Fix implicit copy ctor and copy assignment operator warnings
when -Wdeprec
On Tue, Mar 22, 2016 at 10:50 AM, Justin Bogner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: bogner
> Date: Tue Mar 22 12:50:05 2016
> New Revision: 264071
>
> URL: http://llvm.org/viewvc/llvm-project?rev=264071&view=rev
> Log:
> StaticAnalyzer: Avoid an unintentional copy
>
Jus
Reid sent out a different patch for this warning improvement. Have you
checked that one out? Is it abandoned?
I'm still a bit concerned about whitelisting all these cases & not catching
cases where the parameter is then used inside the function in some
problematic way (the classic being a unique_p
Ah, now I see your follow-up email. Soryr I missed it...
On Wed, Mar 23, 2016 at 9:30 AM, David Blaikie wrote:
> Reid sent out a different patch for this warning improvement. Have you
> checked that one out? Is it abandoned?
>
> I'm still a bit concerned about whitelisting all these cases & not
On Wed, Mar 23, 2016 at 11:03 AM, Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> alexfh added a subscriber: alexfh.
> alexfh added a comment.
>
> As a data point: I ran -Wshadow on our code base with a similar, but
> simpler patch (http://reviews.llvm.org/D18395, just d
can you just match on the name of the template instead?
On Wed, Mar 23, 2016 at 12:46 PM, Etienne Bergeron via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> etienneb created this revision.
> etienneb added a reviewer: alexfh.
> etienneb added a subscriber: cfe-commits.
>
> The current checke
On Wed, Mar 23, 2016 at 3:42 PM, Justin Lebar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: jlebar
> Date: Wed Mar 23 17:42:27 2016
> New Revision: 264205
>
> URL: http://llvm.org/viewvc/llvm-project?rev=264205&view=rev
> Log:
> [CUDA] Don't define __NVCC__.
>
> Summary:
> We deci
*Sent: *Thursday, March 24, 2016 10:39:18 AM
> *Subject: *Re: r264205 - [CUDA] Don't define __NVCC__.
>
> On Thu, Mar 24, 2016 at 8:30 AM, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>>
>> This seems like a different tradeoff from the
On Fri, Mar 25, 2016 at 9:59 AM, Etienne Bergeron via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> etienneb created this revision.
> etienneb added a subscriber: cfe-commits.
>
> The string class contains methods which support receiving either a string
> literal or a string object.
>
> For e
On Fri, Mar 25, 2016 at 10:46 AM, Samuel Benzaquen via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: sbenza
> Date: Fri Mar 25 12:46:02 2016
> New Revision: 264428
>
> URL: http://llvm.org/viewvc/llvm-project?rev=264428&view=rev
> Log:
> [ASTMatchers] Fix build for VariadicFunction.
>
On Fri, Mar 25, 2016 at 4:01 PM, Richard Smith
wrote:
> On Fri, Mar 25, 2016 at 10:55 AM, David Blaikie via cfe-commits
> wrote:
> >
> >
> > On Fri, Mar 25, 2016 at 10:46 AM, Samuel Benzaquen via cfe-commits
> > wrote:
> >>
> >> Author: sbe
Test case?
On Fri, Dec 18, 2015 at 11:44 AM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: adrian
> Date: Fri Dec 18 13:44:31 2015
> New Revision: 256012
>
> URL: http://llvm.org/viewvc/llvm-project?rev=256012&view=rev
> Log:
> Add a defensive check for a nullptr.
>
On Fri, Dec 18, 2015 at 2:40 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Fri Dec 18 16:40:25 2015
> New Revision: 256049
>
> URL: http://llvm.org/viewvc/llvm-project?rev=256049&view=rev
> Log:
> Split RequireCompleteType into a function that actu
Presumably this only applies when using implicit modules builds, not when
using explicit modules builds. (though I'm not sure what the current
behavior of -gmodules is with explicit modules, maybe it's
untested/broken/etc anyway)
On Tue, Dec 22, 2015 at 2:37 PM, Adrian Prantl via cfe-commits <
cfe
On Thu, Dec 24, 2015 at 4:36 PM, Craig Topper via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ctopper
> Date: Thu Dec 24 18:36:02 2015
> New Revision: 256403
>
> URL: http://llvm.org/viewvc/llvm-project?rev=256403&view=rev
> Log:
> Revert r256399 "[Sema] ArrayRef-ize ActOnBaseSpecif
(oops, forgot to reply-all)
-- Forwarded message --
From: David Blaikie
Date: Fri, Jan 8, 2016 at 10:51 AM
Subject: Re: r256287 - Document that we recommend to turn off -gmodules
when building a static
To: Adrian Prantl
On Fri, Jan 8, 2016 at 8:34 AM, Adrian Prantl wrote:
>
This sounds sort of like the missing-declaration warning in Clang, no?
(granted, it's a bit more direct & thus perhaps easier to use, but fulfills
a similar purpose)
On Fri, Jan 8, 2016 at 8:37 AM, Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: alexfh
> Date: F
On Fri, Jan 8, 2016 at 10:08 AM, Artem Belevich via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> tra added inline comments.
>
>
> Comment at: include/clang/Driver/Action.h:36
> @@ -35,1 +35,3 @@
> +///
> +/// Actions are usually owned by a Compilation.
> class Action {
> --
On Fri, Jan 8, 2016 at 10:55 AM, David Blaikie wrote:
>
>
> On Fri, Jan 8, 2016 at 10:08 AM, Artem Belevich via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> tra added inline comments.
>>
>>
>> Comment at: include/clang/Driver/Action.h:36
>> @@ -35,1 +35,3 @@
>> +///
>>
On Wed, Jan 6, 2016 at 11:22 AM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: adrian
> Date: Wed Jan 6 13:22:19 2016
> New Revision: 256962
>
> URL: http://llvm.org/viewvc/llvm-project?rev=256962&view=rev
> Log:
> Module debugging: Defer emitting tag types until th
On Fri, Jan 8, 2016 at 1:34 PM, Adrian Prantl wrote:
>
> On Jan 8, 2016, at 1:31 PM, David Blaikie wrote:
>
>
>
> On Wed, Jan 6, 2016 at 11:22 AM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: adrian
>> Date: Wed Jan 6 13:22:19 2016
>> New Revision: 256962
>>
dblaikie added a subscriber: dblaikie.
Comment at: test/SemaTemplate/temp_arg_template.cpp:80
@@ +79,3 @@
+#if __cplusplus >= 201103L
+ static constexpr int N = sizeof...(Templates);
+#endif
It would be good if we tested for some specific behavior here other than
dblaikie added inline comments.
Comment at: include/clang/Driver/Compilation.h:54
@@ +53,3 @@
+ /// to consumers; it's here just to manage ownership.
+ std::vector> OwningActions;
+
Seems like this name isn't quite right ("OwningActions" sounds like "these are
Thanks!
On Fri, Jan 8, 2016 at 5:15 PM, Adrian Prantl wrote:
>
> > On Jan 8, 2016, at 2:18 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> >>
> >> On Jan 8, 2016, at 1:59 PM, David Blaikie wrote:
> >>
> >>
> >>
> >> On Fri, Jan 8, 2016 at 1:34 PM, Adrian Prantl
>
On Fri, Jan 8, 2016 at 6:26 PM, Alexander Kornienko
wrote:
> I don't see how -Wmissing-declarations relates to this check. None of the
> warnings in the MissingDeclarations group in DiagnosticSemaKinds.td seem to
> be anywhere close to what this check does. Am I missing something?
>
Ah, sorry -
On Fri, Jan 8, 2016 at 4:08 PM, Richard Smith wrote:
> On Thu, Jan 7, 2016 at 6:00 PM, David Blaikie wrote:
>
>> On Fri, Dec 18, 2015 at 2:40 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Fri Dec 18 16:40:25 2015
>>> New Revision: 25604
On Sun, Jan 10, 2016 at 11:42 PM, Owen Anderson via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> resistor created this revision.
> resistor added reviewers: chandlerc, bkramer, klimek.
> resistor added a subscriber: cfe-commits.
> resistor set the repository for this revision to rL LLVM.
> H
This could be tested - though I'm not sure if there's precedent for testing
the types of builtins for other targets, for example. Might be worth
checking?
On Thu, Jan 14, 2016 at 6:26 AM, Krzysztof Parzyszek via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: kparzysz
> Date: Thu Jan 1
dblaikie added a subscriber: dblaikie.
dblaikie accepted this revision.
dblaikie added a reviewer: dblaikie.
dblaikie added a comment.
This revision is now accepted and ready to land.
Looks good - thanks!
http://reviews.llvm.org/D16206
___
cfe-commi
On Thu, Dec 17, 2015 at 4:51 AM, Marina Yatsina via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: myatsina
> Date: Thu Dec 17 06:51:51 2015
> New Revision: 255890
>
> URL: http://llvm.org/viewvc/llvm-project?rev=255890&view=rev
> Log:
> [ms-inline-asm] Add support for composite struct
On Fri, Jan 15, 2016 at 2:29 PM, Joerg Sonnenberger via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: joerg
> Date: Fri Jan 15 16:29:34 2016
> New Revision: 257947
>
> URL: http://llvm.org/viewvc/llvm-project?rev=257947&view=rev
> Log:
> Avoid self-assignment of SmallString, trigger U
On Fri, Jan 15, 2016 at 2:56 PM, Benjamin Kramer
wrote:
> On Fri, Jan 15, 2016 at 11:52 PM, David Blaikie via cfe-commits
> wrote:
> >
> >
> > On Fri, Jan 15, 2016 at 2:29 PM, Joerg Sonnenberger via cfe-commits
> > wrote:
> >>
> >> Author: jo
Author: dblaikie
Date: Fri Jan 15 17:43:28 2016
New Revision: 257957
URL: http://llvm.org/viewvc/llvm-project?rev=257957&view=rev
Log:
OpaquePtr: Use nullptr construction for TemplateTy OpaquePtr typedef
Modified:
cfe/trunk/lib/Parse/ParseDeclCXX.cpp
Modified: cfe/trunk/lib/Parse/ParseDeclCX
Author: dblaikie
Date: Fri Jan 15 17:43:25 2016
New Revision: 257956
URL: http://llvm.org/viewvc/llvm-project?rev=257956&view=rev
Log:
OpaquePtr: Use nullptr construction for DeclGroupPtrTy OpaquePtr typedef
Modified:
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseDeclCXX.cpp
Author: dblaikie
Date: Fri Jan 15 17:43:21 2016
New Revision: 257955
URL: http://llvm.org/viewvc/llvm-project?rev=257955&view=rev
Log:
OpaquePtr: Provide conversion-from-nullptr_t to make default construction
simpler to read/write
Modified:
cfe/trunk/include/clang/Sema/Ownership.h
Modified:
Author: dblaikie
Date: Fri Jan 15 17:43:34 2016
New Revision: 257958
URL: http://llvm.org/viewvc/llvm-project?rev=257958&view=rev
Log:
OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedef
Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseDecl.cpp
c
On Mon, Dec 21, 2015 at 2:35 AM, Romanova, Katya <
katya_roman...@playstation.sony.com> wrote:
> Hi David,
>
>
>
> Thank you so much for the review.
>
> I copied and pasted the diff file. Let me know if it’s OK to commit.
>
>
>
>
>
> >> Could/should this ^ just be: Opts.DebugExplicitImport =
> Tri
dblaikie added a subscriber: dblaikie.
dblaikie added a comment.
Apologies for the massively delayed review. I think this is probably good,
but here are some test cases to discuss (& I've cc'd Paul Robinson and
Adrian Prantl, both who work on debug info in LLVM as well, to get their
thoughts)
Giv
1101 - 1200 of 1518 matches
Mail list logo
