test case?
On Mon, Jul 30, 2018 at 1:39 PM Stephen Kelly via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: steveire
> Date: Mon Jul 30 13:39:14 2018
> New Revision: 338301
>
> URL: http://llvm.org/viewvc/llvm-project?rev=338301&view=rev
> Log:
> Avoid returning an invalid end source
What's the motivation for clangd to differ from clang here? (& if the first
letter is going to be capitalized, should there be a period at the end? But
also the phrasing of most/all diagnostic text isn't in the form of complete
sentences, so this might not make sense)
On Fri, Aug 3, 2018 at 1:44 P
Reckon there's a chance of improved diagnostic text in cases like this?
Will users understand what the problem is/how to fix it when they read
"temporary
implicitly bound to local reference will be destroyed at the end of the
full-expression" - feels very standard-ese-y to me? & I appreciate teh
de
Looks good! Though it may be useful in the future to describe, in the
commit message, the motivation for a change - how'd you find this? What
motivated you to make this particular fix just now, etc? ("identified using
clang-tidy" or "spotted during post-commit review of change r", etc...)
On T
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
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.o
If it never comes up, maybe an assertion would suffice? (& if the assertion
ever does fire - hey, we've found a test case to use)
How'd you find this/what motivated you to make the change?
On Tue, Aug 7, 2018 at 3:11 PM Stephen Kelly wrote:
>
> Hi David,
>
> I'm happy to add a test case, but I
*nod* Maybe consistency's enough for now. But yeah, if you can test whether
the assertion fires (though for invalid locs, that usually means invalid
code - and we don't have nice big repositories of weird invalid code - just
the clang regression tests).
On Tue, Aug 7, 2018 at 3:27 PM Stephen Kel
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@list
On Wed, Aug 8, 2018 at 5:00 AM Ilya Biryukov via Phabricator <
revi...@reviews.llvm.org> wrote:
> ilya-biryukov added a comment.
>
> In https://reviews.llvm.org/D50154#1191002, @dblaikie wrote:
>
> > What's the motivation for clangd to differ from clang here?
>
>
> The presentation of diagnostics
Author: dblaikie
Date: Thu Aug 16 14:30:24 2018
New Revision: 339941
URL: http://llvm.org/viewvc/llvm-project?rev=339941&view=rev
Log:
Update for LLVM API change
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:
http://llvm.org/viewvc/llvm-
Author: dblaikie
Date: Thu Aug 16 16:56:32 2018
New Revision: 339968
URL: http://llvm.org/viewvc/llvm-project?rev=339968&view=rev
Log:
Disable pubnames in NVPTX debug info using metadata
Added:
cfe/trunk/test/CodeGen/debug-nvptx.c
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
Modified:
Author: dblaikie
Date: Mon Aug 20 13:14:08 2018
New Revision: 340206
URL: http://llvm.org/viewvc/llvm-project?rev=340206&view=rev
Log:
DebugInfo: Add the ability to disable DWARF name tables entirely
This changes the current default behavior (from emitting pubnames by
default, to not emitting the
I haven't looked in detail here, but in general: Don't split an
implementation and its headers into different notional libraries, as that
breaks modular code generation (an implementation and its headers usually
have circular dependencies - inline functions that call non-inline
functions, and the o
On Fri, May 18, 2018 at 2:22 PM Eric Liu wrote:
> Thanks a lot for looking into this Bruno! The fix looks promising; I'll
> give it a try next week :D
>
> On Fri, May 18, 2018 at 10:33 PM David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>&
Probably nice to mention in the commit message what the fix was (& if/where
there was there a test added for it?) so readers don't have to try to
eyeball diff this commit against the otherone.
On Wed, May 23, 2018 at 4:45 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Aut
Is there also missing test coverage here?
On Sun, Sep 24, 2017 at 8:19 AM Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rksimon
> Date: Sun Sep 24 08:17:46 2017
> New Revision: 314079
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314079&view=rev
> Log:
> Fix impl
On Wed, Sep 27, 2017 at 11:50 AM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:
> probinson added a comment.
>
> In https://reviews.llvm.org/D14358#882445, @dblaikie wrote:
>
> > > I would prefer to eliminate the `` from the instance name as
> well, because our debugger reconstru
On Wed, Sep 27, 2017 at 1:58 PM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:
> probinson added a reviewer: rnk.
> probinson added a comment.
>
> +rnk for the CodeView question.
>
>
>
>
> Comment at: include/clang/Frontend/CodeGenOptions.def:222
>
hey Lang (& folks here) any chance there's some overlap between the RPC
functionality here and the RPC functionality in ORC that could be
deduplicated/refactored?
On Fri, Oct 6, 2017 at 5:30 AM Ilya Biryukov via Phabricator via
cfe-commits wrote:
> ilya-biryukov accepted this revision.
> ilya-bi
I mention it only out of interest of deduplication of functionality/code
within the LLVM project as a whole. Be nice not to maintain two things if
one would suffice.
On Thu, Oct 12, 2017 at 6:21 AM Sam McCall wrote:
> Interesting - this is pretty primitive, and still fairly tightly coupled
> to
Would it be better/possible to improve the warning to not have this false
positive, rather than suppressing it?
On Sun, Oct 15, 2017 at 1:12 PM Roman Lebedev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: lebedevri
> Date: Sun Oct 15 13:12:42 2017
> New Revision: 315874
>
> URL: h
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
Is there missing test coverage for this?
On Tue, Oct 10, 2017 at 9:12 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ibiryukov
> Date: Tue Oct 10 09:12:47 2017
> New Revision: 315323
>
> URL: http://llvm.org/viewvc/llvm-project?rev=315323&view=rev
> Log:
> [clangd
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 momen
What John said, but also a narrower test would be good - checking that the
appropriate call instruction gets a debug location, rather than checking
that a bunch of inlining doesn't cause the assertion/verifier failure,
would be good. (Clang tests should, as much as possible, not rely on or run
the
On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ericwf
> Date: Wed Feb 7 10:36:51 2018
> New Revision: 324498
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324498&view=rev
> Log:
> [Driver] Add option to manually control discarding v
Unit test?
On Fri, Feb 9, 2018 at 10:45 AM Phabricator via Phabricator via
llvm-commits wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL324761: Introduce an API for LLDB to compute the
> default module cache path (authored by adrian, commit
FWIW, you can write "*M" rather than M.getValue() if you reckon that's
neater.
And you could roll the declaration/initialization of M into the 'if'
condition - but I can understand why you might prefer not to, given it's a
many-line statement, etc.
On Tue, Feb 6, 2018 at 4:39 PM Erich Keane via c
On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier wrote:
> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie wrote:
>
>>
>>
>> On Wed, Feb 7, 2018 at 10:38 AM Eric Fiselier via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ericwf
>>> Date: Wed Feb 7 10:36:51 2018
>>> New Revision:
ah, sweet :)
On Mon, Feb 12, 2018 at 2:59 PM Eric Fiselier wrote:
> On Mon, Feb 12, 2018 at 3:35 PM, David Blaikie wrote:
>
>>
>>
>> On Mon, Feb 12, 2018 at 2:25 PM Eric Fiselier wrote:
>>
>>> On Mon, Feb 12, 2018 at 9:15 AM, David Blaikie
>>> wrote:
>>>
On Wed, Feb 7, 2018 at
Ah.. hrm :/
On Mon, Feb 12, 2018 at 6:03 PM Eric Fiselier wrote:
> On Mon, Feb 12, 2018 at 4:01 PM, David Blaikie wrote:
>
>> ah, sweet :)
>>
>> On Mon, Feb 12, 2018 at 2:59 PM Eric Fiselier wrote:
>>
>>> On Mon, Feb 12, 2018 at 3:35 PM, David Blaikie
>>> wrote:
>>>
On Mon, Feb
Maybe - though that'd actually make for larger debug info & not be much
use.
With nodebug+always_inline (which is how the intrinsics are provided) the
function call dissolves into the raw instruction it's meant to represent.
The debug info describes that instruction as if it had been written at th
Author: dblaikie
Date: Tue Feb 20 08:35:08 2018
New Revision: 325594
URL: http://llvm.org/viewvc/llvm-project?rev=325594&view=rev
Log:
PR36442: Correct description of -fsplit-dwarf-inlining
Modified:
cfe/trunk/include/clang/Driver/Options.td
Modified: cfe/trunk/include/clang/Driver/Options.t
Author: dblaikie
Date: Wed Feb 21 08:00:50 2018
New Revision: 325692
URL: http://llvm.org/viewvc/llvm-project?rev=325692&view=rev
Log:
Remove use of the 'gmlt' term from the -fsplit-dwarf-inlining flag description
to make it more readily legible
Modified:
cfe/trunk/include/clang/Driver/Optio
I'm assuming most of these tests aren't actually testing for attributes -
perhaps it'd be better to remove their dependence on a particular attribute
list number so future changes to attributes don't require so many touches?
On Sun, May 28, 2017 at 10:38 PM Mehdi Amini via cfe-commits <
cfe-commi
Why would matching on an empty string be bad in this case?
On Thu, May 25, 2017 at 4:25 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rtrieu
> Date: Thu May 25 18:25:36 2017
> New Revision: 303934
>
> URL: http://llvm.org/viewvc/llvm-project?rev=303934&view=rev
>
Could you avoid creating the FinalBB unless it's needed rather than
creating it and then adding it so it can be removed? (or, if the creation
can't be avoided, maybe it's OK to 'delete FinalBB' here, rather than
adding it for it to be removed later?)
(also bracing seems off - could you run your ch
On Mon, May 29, 2017 at 2:12 PM Gor Nishanov wrote:
> It is not known in advance whether the final block is needed or not. It
> will become known once the user-authored body of the coroutine is emitted.
> I cannot defer creation of it up until that point, since final bb acts as a
> jump target fo
Fair enough. I don't have all the context there either.
Perhaps Richard Smith could sanity check what the right memory management
scheme is here.
On Mon, May 29, 2017 at 3:54 PM Gor Nishanov wrote:
> My clang-foo is not strong enough :) .
>
> I wanted to make sure that: "CurCoro.Data->FinalJD =
If SPs are now all finalized early - I'm assuming there's some other code
that finalizes SPs that's no longer needed?
Also - this seems like a layering/separation issue - does other code call
into the DI as casually/explicitly as this code being added to CGVTables?
(Or should the callback go throu
I'll let Adrian weigh in - but I suspect, if possible, it'd be better to
just finalize them all once IRGen for the function finishes.
On Tue, May 30, 2017 at 6:02 PM Keno Fischer
wrote:
> For some reason your comments aren't showing up on Phabricator, so
> replying via email - hope everybody sees
Author: dblaikie
Date: Thu Jun 1 14:08:34 2017
New Revision: 304456
URL: http://llvm.org/viewvc/llvm-project?rev=304456&view=rev
Log:
Add compatibility alias for -Wno-#warnings
GCC uses -Wno-cpp for this, so seems reasonable to add an alias to
match.
Modified:
cfe/trunk/include/clang/Basic/
On Mon, May 29, 2017 at 3:28 PM Eric Fiselier via Phabricator via
cfe-commits wrote:
> EricWF created this revision.
>
> @rsmith Is there a better place to put this test?
>
>
> https://reviews.llvm.org/D33660
>
> Files:
> lib/Sema/SemaCoroutine.cpp
> test/SemaCXX/coreturn.cpp
> test/SemaCXX
On Mon, May 29, 2017 at 10:23 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Tue May 30 00:22:59 2017
> New Revision: 304190
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304190&view=rev
> Log:
> Diagnose attempts to build a preprocessed module th
Alternatively, you could disable the check (or change the count it checks)
if this is defined. (& if you disable the check when this is defined, you
could change an existing build/test config (or add a new one) to have this
disabled)
On Tue, May 30, 2017 at 8:19 PM Billy Robert O'Neal III via Phab
On Wed, May 31, 2017 at 5:45 PM Gor Nishanov via Phabricator via
cfe-commits wrote:
> GorNishanov created this revision.
>
> Coroutine related test that used to trigger broken IR prior to r304335.
>
>
> https://reviews.llvm.org/D33750
>
> Files:
> test/CodeGenCoroutines/coro-await-domination.cp
Is it right to only change the behavior of this caller? Presumably other
callers (like getSpellingColumnNumber, getExpansionColumnNumber, etc)
probably want the same handling? Do any callers /not/ want this behavior?
On Thu, Jun 1, 2017 at 3:14 AM Erik Verbruggen via Phabricator via
cfe-commits w
what was the warning?
On Fri, Jun 2, 2017 at 11:48 AM Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: alexfh
> Date: Fri Jun 2 13:47:50 2017
> New Revision: 304583
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304583&view=rev
> Log:
> [clang-tidy] Add `const
This change seemed to be buggy (& I assume missing test coverage to
demonstrate that). Galina fixed it in
http://llvm.org/viewvc/llvm-project?rev=304663&view=rev based on a compiler
warning.
Can you add test coverage to this code to exercise these untested codepaths?
On Tue, Apr 11, 2017 at 12:34
I followed up on the original commit (r299921) to request that as well.
On Sat, Jun 3, 2017 at 1:26 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Can we get a testcase for this bug? Seems like we can't have any coverage
> for the case where IsArmArch is supposed to be fa
On Mon, Jun 5, 2017 at 10:28 AM Maxim Ostapenko wrote:
> On 05/06/17 20:16, David Blaikie wrote:
> > This change seemed to be buggy (& I assume missing test coverage to
> > demonstrate that). Galina fixed it in
> > http://llvm.org/viewvc/llvm-project?rev=304663&view=rev based on a
> > compiler wa
On Tue, Jun 6, 2017 at 3:59 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:
> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D33102#773296, @dblaikie wrote:
>
> > I still feel like that's more testing than would be ideal (does the
> context of the cast matter? Weth
Looks all good, please commit whenever you're ready - if you don't have
commit access, I (or anyone else with commit access) can commit this for
you.
On Tue, Jun 6, 2017 at 1:57 PM Roman Lebedev wrote:
> On Tue, Jun 6, 2017 at 8:52 PM, David Blaikie wrote:
> >
> >
> > On Tue, Jun 6, 2017 at 3:5
On Sat, Jun 10, 2017 at 3:33 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:
> lebedev.ri planned changes to this revision.
> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D33102#773296, @dblaikie wrote:
>
> > But sure. Could you also (manually, I guess) confirm t
On Tue, Jun 6, 2017 at 3:56 AM Chandler Carruth via Phabricator via
cfe-commits wrote:
> chandlerc created this revision.
> Herald added subscribers: mcrosier, sanjoy, klimek.
>
> This really is a collection of improvements to the rules for LLVM
> include sorting:
>
> - We have gmock headers now,
Richard, looks like this might be better as:
if (auto QL = OE->getQualifierLoc())
... QL.getBeginLoc() ...
?
On Wed, Jun 7, 2017 at 3:23 AM Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: d0k
> Date: Wed Jun 7 05:23:17 2017
> New Revision: 304892
>
> URL: http
On Mon, Jun 12, 2017 at 10:10 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:
> lebedev.ri added a comment.
>
> So i'm trying to analyze that stage2 warning.
>
Could you link to the buildbot failure to see the original LLVM project
code triggering this situation?
> The testc
Prefer FileCheck over grep, generally?
On Mon, Jun 12, 2017 at 11:05 AM Yaron Keren via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: yrnkrn
> Date: Mon Jun 12 13:05:13 2017
> New Revision: 305213
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305213&view=rev
> Log:
> Add regressio
Yeah, looks like the UB is baked in pretty deep here, so it's not
reasonable to try to fix it just because of this.
I'd probably suggest trying making that cast in PointerUnion.h into a
reinterpret cast? Would that suffice to address the const issues? Otherwise
a const_cast + reinterpret_cast?
hey Saleem - might be worth sending a cfe-dev email about what the general
direction/goals are here (may not need precommit review for every patch,
but just some sanity checking)
On Mon, Jun 12, 2017 at 1:08 AM Daniel Jasper via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: djasper
>
I've been seeing errors from this test recently:
Command Output (stderr):
--
1 error generated.
Error while processing
/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-tidy/diagnostic.cpp.nonexistent.cpp.
/usr/local/google/home/blaikie/dev/llvm/src/tools/clang/tools/e
hard to say if it's more readable without seeing it - if you could attach a
patch, if it's easy enough/you worked it up before, might be worth
comparing/contrasting
On Tue, Jun 13, 2017 at 12:28 AM Dean Michael Berris via Phabricator <
revi...@reviews.llvm.org> wrote:
> dberris added a comment.
Ah, I find that the test passes if I remove the compile_commands.json file
from my build directory (I have Ninja configured to generate a
compile_commands.json file).
Looks like what happens is it finds the compilation database and fails hard
when the database doesn't contain a compile command for
On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov wrote:
> 2017-06-14 4:24 GMT+07:00 David Blaikie :
>
>> Ah, I find that the test passes if I remove the compile_commands.json
>> file from my build directory (I have Ninja configured to generate a
>> compile_commands.json file).
>>
>> Looks like what hap
https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (& have a
sufficiently recent cmake), then CMake will generate a
compile_commands.json in the root of the build tree. The test finds this &
fails, instead of finding
On Mon, Jun 12, 2017 at 9:15 PM Dean Michael Berris via Phabricator <
revi...@reviews.llvm.org> wrote:
> dberris added a reviewer: dblaikie.
> dberris added a subscriber: dblaikie.
> dberris added a comment.
>
> @dblaikie -- do you have time to have a look?
>
Sure sure - no need to ping a patch m
On Mon, Jun 19, 2017 at 12:30 AM Daniel Jasper via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: djasper
> Date: Mon Jun 19 02:30:04 2017
> New Revision: 305665
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305665&view=rev
> Log:
> clang-format: Add capability to format the diff on
Ah, nevermind - I hadn't sync'd this change! Sorry for the noise.
Thanks for the feature!
On Mon, Jun 19, 2017 at 11:18 AM David Blaikie wrote:
> On Mon, Jun 19, 2017 at 12:30 AM Daniel Jasper via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: djasper
>> Date: Mon Jun 19 02:30:
Ping (+Manuel, perhaps he's got some ideas about this, given background in
the tooling & compilation database work, or could point this to someone who
does?)
On Thu, Jun 15, 2017 at 10:40 AM David Blaikie wrote:
> https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
>
> If you ena
On Sat, Jun 24, 2017 at 10:08 AM Serge Pavlov wrote:
> With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json is
> created in the directory
> /tools/clang/tools/extra/test/clang-tidy/Output, but the tests
> from /llvm/tools/clang/tools/extra/test/clang-tidy run in the
> directory /tool
On Sat, Jun 24, 2017 at 10:08 AM Serge Pavlov wrote:
> With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json is
> created in the directory
> /tools/clang/tools/extra/test/clang-tidy/Output,
>
I'd be really surprised if this is the case - why would
cmake/ninja/makefiles put the compil
Ah, I see now then.
I have a symlink from the root of my source directory pointing to the
compile_commands.json in my build directory.
I have this so that the vim YouCompleteMe plugin (& any other clang tools)
can find it, as they usually should, for using tools with the llvm/clang
project...
So
On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator <
revi...@reviews.llvm.org> wrote:
> xgsa added a comment.
>
> In https://reviews.llvm.org/D39622#954585, @probinson wrote:
>
> > Philosophically, mangled names and DWARF information serve different
> purposes, and I don't think you will find o
On Fri, Dec 15, 2017 at 8:09 AM xgsa wrote:
> David, thank you for the detailed answer and corner cases.
>
> Just to clarify: everywhere in my mail where I mentioned "debugger", I
> meant LLDB, but not GDB (except, where I mentioned GDB explicitly).
> Currently, I have no plans to work on GDB, ho
This operator bool should probably be explicit (as most/all of them should
be - and most of them in LLVM are) - to avoid undue implicit conversion to
other int types.
On Wed, Dec 13, 2017 at 7:43 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ibiryukov
> Date: Wed
st
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:25, David Blai
ven with long term solution implemented
>> in clang/lldb, gdb still won't resolve dynamic types properly for the
>> described cases.
>>
>> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>>
>> 15.12.2017 21:25, David Blaikie via cfe-commits
ied (I suppose, at least
> tests should be added), because even with long term solution implemented
> in clang/lldb, gdb still won't resolve dynamic types properly for the
> described cases.
>
> [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html
>
> 15.12.2017 21:
Generally I'd encourage you/anyone to use [&] for any lambda that doesn't
escape its scope - avoids any issues like this & doesn't really hinder
readability imho.
On Wed, Dec 20, 2017 at 9:23 AM Eric Liu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ioeric
> Date: Wed Dec 20 09:2
Test case?
On Thu, Dec 21, 2017 at 2:39 PM Richard Trieu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rtrieu
> Date: Thu Dec 21 14:38:29 2017
> New Revision: 321319
>
> URL: http://llvm.org/viewvc/llvm-project?rev=321319&view=rev
> Log:
> [ODRHash] Canonicalize Decl's before pro
any chance this can be implemented based on keyboard layout, so it's good
for dvorak users as well? (maybe it already is, I don't know - just
mentioning it in case)
On Thu, Dec 21, 2017 at 2:58 PM George Karpenkov via Phabricator via
cfe-commits wrote:
> This revision was automatically updated t
On Tue, Dec 19, 2017 at 9:43 PM Akira Hatanaka wrote:
> On Tue, Dec 12, 2017 at 12:12 PM, John McCall wrote:
>
>> On Tue, Dec 12, 2017 at 1:45 PM, David Blaikie
>> wrote:
>>
>>> On Mon, Dec 11, 2017 at 5:38 PM John McCall wrote:
>>>
On Mon, Dec 11, 2017 at 6:19 PM, David Blaikie
wro
Sure, this is post-commit review feedback.
vim with dvorak works in the sense that it's not unusable, but it's pretty
awkward (see, for example, discussions like this:
http://vim.wikia.com/wiki/Using_Vim_with_the_Dvorak_keyboard_layout )
On Tue, Jan 2, 2018 at 10:03 AM George Karpenkov
wrote:
>
(just a side note: perhaps this conversation would've been more suited to
cfe-dev? I sort of missed it because I only check commits once a week,
unless I'm specifically cc'd on something. All good though :))
On Wed, Jan 3, 2018 at 4:06 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org>
I'm sure it's something obvious I don't understand here, but maybe someone
else doesn't either & could benefit from it:
What exactly does this change do? In what important way is "cp X Y"
different from "cat X > Y"?
On Mon, Jan 8, 2018 at 7:06 AM Sam McCall via cfe-commits <
cfe-commits@lists.llv
It helps to have the first line of the commit message be roughly
descriptive, since it forms the brief commit summary in version tools and
the subject line in commit email - just "NFC" is a bit unclear. Usually
these sort of commits are described as, say "Suppress -Asserts
unused-variable warning f
Rough guess: That seems like a lot of code changes for relatively little
test changes - are all parts of this change tested? (Might well be - just
lots of layers to plumb things through - but if there's lots of places that
get locations and only a few of those are tested, maybe this could use more
Great - are you tracking/planning to implement this for trivial_abi once
it's in? (was mentioned in the code review, but not sure if it's on your
plate/plan or not (no worries if it isn't, just keeping these things in
mind))
On Thu, Jan 4, 2018 at 5:14 PM Adrian Prantl via cfe-commits <
cfe-commit
Excellent :)
On Mon, Jan 8, 2018 at 8:39 AM Adrian Prantl wrote:
>
> On Jan 8, 2018, at 8:14 AM, David Blaikie wrote:
>
> Great - are you tracking/planning to implement this for trivial_abi once
> it's in? (was mentioned in the code review, but not sure if it's on your
> plate/plan or not (no w
Author: dblaikie
Date: Tue Jan 9 14:03:47 2018
New Revision: 322126
URL: http://llvm.org/viewvc/llvm-project?rev=322126&view=rev
Log:
Wire up GCOV to the new pass manager
GCOV in the old pass manager also strips debug info (if debug info is
disabled/only produced for profiling anyway) after the
I haven't as yet, no. Sorry - happy if someone else wants to have a go, or
I'll take a closer look soon.
- Dave
On Thu, Jan 11, 2018 at 11:38 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:
> lebedev.ri added a comment.
>
> In https://reviews.llvm.org/D41455#963752, @aaron.ba
Might be useful in the future to use a more specific commit message such as
"add missing override" (or "add missing override to address
-Wmissing-override warning"), etc.
On Wed, Feb 28, 2018 at 6:03 AM Gabor Horvath via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: xazax
> Date: Wed
On Thu, May 31, 2018 at 11:20 AM Peter Collingbourne via Phabricator <
revi...@reviews.llvm.org> wrote:
> pcc created this revision.
> pcc added reviewers: tejohnson, dblaikie.
> Herald added subscribers: JDevlieghere, hiraditya, eraman, inglorion,
> mehdi_amini.
>
> https://reviews.llvm.org/D4759
Probably CC someone from apple here & ask about rdar://8678458 - they can
look it up & provide the missing context.
On Mon, Jun 4, 2018 at 8:17 AM Roman Lebedev via Phabricator <
revi...@reviews.llvm.org> wrote:
> lebedev.ri added reviewers: rjmccall, akyrtzi.
> lebedev.ri added a comment.
>
> It
Author: dblaikie
Date: Mon Jun 4 14:23:29 2018
New Revision: 333955
URL: http://llvm.org/viewvc/llvm-project?rev=333955&view=rev
Log:
Update for an LLVM header file move
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-p
Author: dblaikie
Date: Thu Jun 14 16:09:06 2018
New Revision: 334778
URL: http://llvm.org/viewvc/llvm-project?rev=334778&view=rev
Log:
Modules: Fix implicit output file for .cppm to .pcm instead of stdout
This code was introduced back in r178148, a change to introduce
-module-file-info - which st
On Fri, Oct 19, 2018 at 3:56 PM Adrian Prantl via Phabricator via
llvm-commits wrote:
> aprantl added a comment.
>
> I have a vague recollection that this column info hack was added to
> disambiguate two types defined on the same line (which is something that
> happened more often than one would
sis and into somewhere in lib/StaticAnalyzer. There shouldn't
>> be any problem with clang-tidy using it from there, since it already
>> depends on the static analyzer.
>>
> I'm happy to do the move.
> Could you (or someone) help point out where exactly I shou
Does this match GCC's approach here?
(I ask this sort of as throwaway/conversation starter - because the
linkage/behavior around multiversion functions and their inlining is full
of sharp corners/risks of code moving out of the areas appropriately
restricted based on the cpu features)
On Mon, Oct
1 - 100 of 1480 matches
Mail list logo
