On Tue, 7 Aug 2018 at 10:52, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
>
> On Tue, Aug 7, 2018 at 10:33 AM Alex Lorenz via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> arphaman added a comment.
>>
>> In https://reviews.llvm.org/D50154#1191002, @dblaikie wrote:
>
On Tue, 7 Aug 2018 at 11:38, David Blaikie wrote:
>
>
> On Tue, Aug 7, 2018 at 11:22 AM Alex L wrote:
>
>> On Tue, 7 Aug 2018 at 10:52, David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Aug 7, 2018 at 10:33 AM Alex Lorenz via Phabricator <
>>> revi...@r
On 7 August 2018 at 17:40, Fangrui Song wrote:
>
> On 2018-08-07, David Blaikie wrote:
>
>>
>> On Tue, Aug 7, 2018 at 4:02 PM Alex L wrote:
>>
>>On Tue, 7 Aug 2018 at 11:38, David Blaikie wrote:
>>
>>On Tue, Aug 7, 2018 at 11:22 AM Alex L wrote:
>>
>>On Tue, 7 Aug 2018
Are the pshpack1.h/poppack.h headers included from other headers in the SDK
or are they intended for end-users? If they're only used in the SDK then
the SDK headers should probably be system headers, so the warning should be
silenced.
Apart from that there's no real good solution for this issue un
At the moment this method override is not used by the clang-refactor tool,
so I don't think I can add a test for it.
On 16 October 2017 at 10:11, David Blaikie wrote:
> Is there a test that could be added to cover this new code?
>
> On Fri, Oct 13, 2017 at 2:15 PM Alex Lorenz via cfe-commits <
>
That's a good idea! I'll commit an llvm_unreachable fix for this override
then.
On 16 October 2017 at 10:32, David Blaikie wrote:
> Generally it's preferably to avoid adding dead code (partly for this
> reason - it's hard to track when it gets used and ensure it's appropriately
> tested) could t
Thanks!
On 19 October 2017 at 01:20, Haojian Wu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: hokein
> Date: Thu Oct 19 01:20:55 2017
> New Revision: 316152
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316152&view=rev
> Log:
> Fix a few nits in RenamingAction.
>
> * Add missi
Sorry for the late response,
On Sat, 18 Aug 2018 at 20:10, Nico Weber wrote:
> Also, the diag text should probably say "pass '-stdlib=libc++' " not "pass
> '-std=libc++' "?
>
Good catch, thanks! I'll commit a fixup for it.
>
> On Sat, Aug 18, 2018 at 11:06 PM Nico Weber wrote:
>
>> Should th
On Fri, 7 Sep 2018 at 05:41, Nico Weber wrote:
> On Wed, Sep 5, 2018 at 9:25 PM Alex L wrote:
>
>> Sorry for the late response,
>>
>> On Sat, 18 Aug 2018 at 20:10, Nico Weber wrote:
>>
>>> Also, the diag text should probably say "pass '-stdlib=libc++' " not
>>> "pass '-std=libc++' "?
>>>
>>
>>
The revert commit is r337782.
On 23 July 2018 at 17:32, Alex L wrote:
> Hi,
>
> I had to revert your commit as it caused a number of failures in our
> public and internal CI.
> When building compiler-rt on Darwin (stage1), after this commit the build
> failed to build X-ray and libfuzzer because
Hi,
I had to revert your commit as it caused a number of failures in our public
and internal CI.
When building compiler-rt on Darwin (stage1), after this commit the build
failed to build X-ray and libfuzzer because the libc++ headers were no
longer found. The compiler-rt libraries were built using
Is there a particular reason why this commit didn't have a corresponding
test included?
Cheers,
Alex
On 1 August 2018 at 04:28, Simon Marchi via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: simark
> Date: Wed Aug 1 04:28:49 2018
> New Revision: 338518
>
> URL: http://llvm.org/viewv
On 1 August 2018 at 11:21, Simon Marchi wrote:
> On 2018-08-01 01:30 PM, Alex L wrote:
> > Is there a particular reason why this commit didn't have a corresponding
> test included?
> > Cheers,
> > Alex
>
> Back when we made the corresponding change in "onChangeConfiguration",
> there was no
> str
On 20 June 2017 at 16:53, Duncan P. N. Exon Smith
wrote:
>
> On Jun 19, 2017, at 10:53, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: arphaman
> Date: Mon Jun 19 12:53:21 2017
> New Revision: 305719
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305719&view=rev
Sorry, I forgot to add the tests in SVN. I committed them in 320735
On 14 December 2017 at 11:22, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Thu Dec 14 11:22:02 2017
> New Revision: 320734
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320734&vie
Hi Richard,
This commit has caused a new regression in Clang which causes an assertion
failure for extern "C" function definitions whose return type is a pointer
to a record. I filed https://bugs.llvm.org/show_bug.cgi?id=35697 which
contains the minimized test case for this issue. Do you mind taki
Thanks for raising your concerns.
We decided to avoid -m-version-min flag in favor of -target to simplify
the driver logic and to encourage the adoption of -target. Now after r321145
we only warn about -m-version-min flag when the OS version specified in
it is different to the OS version specified
On 21 December 2017 at 12:34, James Y Knight wrote:
> I totally agree with moving towards eliminating the -m-version-min
> flags, it's much better to put it in the target, and will clean up a lot of
> cruft in the driver, eventually.
>
> Now -- we (or anyone else who runs into this) can simply st
Hi,
This commit has caused a new regression in LLVM 6. I filed the following
PR: https://bugs.llvm.org/show_bug.cgi?id=35724 .
Could you please take a look?
Thanks,
Alex
On 17 October 2017 at 02:12, Ivan A. Kosarev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: kosarev
> Date: T
I committed the patch that allows -m-version-min to specify the OS
version when -target doesn't specify in r321559. Let me know if it works
for you!
Thanks,
Alex
On 21 December 2017 at 12:34, James Y Knight wrote:
> I totally agree with moving towards eliminating the -m-version-min
> flags, it'
Hi Richard,
This commit has caused a second regression in Clang which triggers a new
invalid -Wunused-function warning. I filed
https://bugs.llvm.org/show_bug.cgi?id=36584 which contains the minimized
test case for this issue. Do you mind taking a look at it?
Thanks,
Alex
On 19 December 2017 at
Thanks, we might have similar cases in our code base as well. We'll see if
we can fix that too.
On Fri, 11 Jan 2019 at 06:13, Nico Weber wrote:
> Here's some user feedback on this new feature.
>
> It looks like the warning is only suppressed if `init` has a definition in
> the @interface block.
Hi,
We are planning to fix this issue by not checking if the method is defined.
I will post a patch this week.
Cheers,
Alex
On Fri, 11 Jan 2019 at 10:26, Alex L wrote:
> Thanks, we might have similar cases in our code base as well. We'll see if
> we can fix that too.
>
> On Fri, 11 Jan 2019 at
Hi Hans,
Could you please cherry-pick this change into the release branch?
Cheers,
Alex
On Thu, 17 Jan 2019 at 10:16, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Thu Jan 17 10:12:45 2019
> New Revision: 351459
>
> URL: http://llvm.org/viewvc/llvm-
We have about 100k unique occurrences of this warning across a slice of our
software stack. It's simply not feasible to us to adopt it, so we would
prefer for it to be reverted to avoid downstream divergence in Apple's
clang. Granted, these occur in projects that use -Weverything but those
projects
On Fri, 7 Sep 2018 at 12:02, Alex L wrote:
>
> On Fri, 7 Sep 2018 at 05:41, Nico Weber wrote:
>
>> On Wed, Sep 5, 2018 at 9:25 PM Alex L wrote:
>>
>>> Sorry for the late response,
>>>
>>> On Sat, 18 Aug 2018 at 20:10, Nico Weber wrote:
>>>
Also, the diag text should probably say "pass '-s
Hi Stephen,
It looks like your change has caused the 'debug-options.c' test to start
failing on Darwin. It looks like we emit "-dwarf-version=4" by default, and
not 2. Could you please take a look.
Here's a link to a latest build on the public LLVM CI that contains the
failure:
http://lab.llvm.or
Thanks, for the explanation, it makes sense. It looks like an explicit
`darwin14` in one of the non-versioned darwin triples fixes the issue. I
will commit the fix right away.
Cheers,
Alex
On Thu, 4 Apr 2019 at 18:24, Adrian Prantl wrote:
> IIRC, the dwarf version on Darwin depends on the depl
Thanks! I committed the fix in r357740. The test should start passing now.
Cheers,
Alex
On Thu, 4 Apr 2019 at 18:32, Stephen Hines wrote:
> Ah I just saw this. Please feel free to CC me on the fix CL and I will
> approve it. I didn't realize that the exact specification was missing
> for that.
It's a good idea to merge the two. I'll work on moving the ObjC traversal
change when I get the time.
Thanks for the quick patches Johannes!
On 9 September 2017 at 12:03, Johannes Altmanninger
wrote:
> Richard Smith writes:
>
> > I am extremely uncomfortable about the direction this patch seri
On 16 August 2017 at 02:49, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Tue Aug 15 18:49:53 2017
> New Revision: 310983
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310983&view=rev
> Log:
> PR19668, PR23034: Fix handling of move constructors and
This commit causes the formatting.test to fail on macOS with an uncaught
exception:
libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: mutex lock failed: Invalid argument
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/35642/
I'm still looking
Perfect, thanks!
On 20 September 2017 at 20:33, Ilya Biryukov wrote:
> Fixed by r313801.
> Sorry for all the trouble.
>
> On Wed, Sep 20, 2017 at 9:22 PM, Ilya Biryukov
> wrote:
>
>> I think I know what's wrong. I've already seen those failures. std::mutex
>> gets destroyed before threads waiti
Hmm, the logging was meant to exercise the creation of chained diagnostic
consumer, so without it the test is kind of pointless. I'll undo your
change, but will set the file to "-" which will print the log to STDERR and
won't create new files. Does that sound reasonable?
Cheers,
Alex
On Tue, 11 J
Thanks, that sounds good to me. I added the assignment with the new comment
in 363199.
On Wed, 12 Jun 2019 at 03:59, Ilya Biryukov wrote:
> Sure, that should work just fine. Could you also add a comment what events
> setting the log file sets in motion? It is not obvious from the test code.
>
>
On Wed, 12 Jun 2019 at 14:29, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Wed Jun 12 14:32:49 2019
> New Revision: 363204
>
> URL: http://llvm.org/viewvc/llvm-project?rev=363204&view=rev
> Log:
> [clang-scan-deps] initial outline of the tool that run
Hi Douglas,
Thanks for the heads up! That's definitely a bug.
I don't think "-c" is needed here. I will adjust this test this morning to
remove the "-c", and will address the bug later.
Thanks,
Alex
On Mon, 17 Jun 2019 at 18:02, wrote:
> Hi Alex,
>
> In the test you added here, the json file c
I committed r363742 with the fix to the test.
Cheers,
Alex
On Tue, 18 Jun 2019 at 10:23, Alex L wrote:
> Hi Douglas,
>
> Thanks for the heads up! That's definitely a bug.
> I don't think "-c" is needed here. I will adjust this test this morning to
> remove the "-c", and will address the bug lat
Thanks for fixing this!
I think changing clang-scan-deps to ignore -j when `LLVM_ENABLE_THREADS` is
probably a better solution. I'll work on a patch that does that.
On Thu, 8 Aug 2019 at 15:07, Reid Kleckner wrote:
> The specific issue here is that clang-scan-deps uses threads, which seems
>
Hi Reid,
I have fixed this issue in r368640, clang-scan-deps will no longer spawn
threads if threading if disabled.
Cheers,
Alex
On Thu, 8 Aug 2019 at 15:13, Alex L wrote:
> Thanks for fixing this!
>
> I think changing clang-scan-deps to ignore -j when `LLVM_ENABLE_THREADS`
> is probably a be
The warning output is suppressed, yes. Yeah, we should probably just
disable them. I'll follow up with a commit.
On Wed, 3 Jul 2019 at 15:25, Duncan P. N. Exon Smith via Phabricator <
revi...@reviews.llvm.org> wrote:
> dexonsmith added a comment.
>
> Is warning output suppressed? If so, should w
Oops, I committed wrong column number in the test due to reindentation.
Fixed in r350283.
~ Alex
On Wed, 2 Jan 2019 at 17:16, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Wed Jan 2 17:13:33 2019
> New Revision: 350282
>
> URL: http://llvm.org/viewv
Thanks for reverting the commit! Unfortunately I missed the failure back
then.
I fixed the leak and recommitted the change in r350666.
Cheers,
Alex
On Tue, 10 Jul 2018 at 12:53, Evgeniy Stepanov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: eugenis
> Date: Tue Jul 10 12:49:07 20
Looks like there was another leak I missed. I'm working on fixing it now.
Cheers,
Alex
On Tue, 8 Jan 2019 at 14:38, Alex L wrote:
> Thanks for reverting the commit! Unfortunately I missed the failure back
> then.
> I fixed the leak and recommitted the change in r350666.
>
> Cheers,
> Alex
>
> On
Fixed in r350680.
On Tue, 8 Jan 2019 at 15:24, Alex L wrote:
> Looks like there was another leak I missed. I'm working on fixing it now.
> Cheers,
> Alex
>
> On Tue, 8 Jan 2019 at 14:38, Alex L wrote:
>
>> Thanks for reverting the commit! Unfortunately I missed the failure back
>> then.
>> I fi
Hi Dmitry,
I think that this commit has caused a regression that's tracked by PR
30440. I'll try working on a fix for it.
Alex
On 30 June 2016 at 02:40, Dmitry Polukhin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: dpolukhin
> Date: Thu Jun 30 04:40:38 2016
> New Revision: 2742
On 3 October 2016 at 13:12, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Mon Oct 3 07:12:03 2016
> New Revision: 283102
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283102&view=rev
> Log:
> Fix PR 28885: Fix AST Printer output for the inherited c
On 3 October 2016 at 13:23, Alex L wrote:
>
>
> On 3 October 2016 at 13:12, Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Mon Oct 3 07:12:03 2016
>> New Revision: 283102
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=283102&view=rev
>> Log:
On 6 October 2016 at 15:50, David Blaikie wrote:
>
>
> On Thu, Oct 6, 2016 at 6:16 AM Alex Lorenz wrote:
>
>> arphaman created this revision.
>> arphaman added reviewers: dblaikie, krememek.
>> arphaman added a subscriber: cfe-commits.
>> arphaman set the repository for this revision to rL LLVM.
On 13 October 2016 at 03:42, Richard Smith wrote:
> Do we need the same change for if-statements too?
>
Yes, a similar change should be made for them as well.
>
> On 12 Oct 2016 6:26 pm, "Vedant Kumar via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
>> vsk created this revision.
>> vs
Thanks, I will take a look at it right now. I believe your solution is the
right fix.
On 5 December 2017 at 07:09, Sean Eveson wrote:
> Hi,
>
> It looks like the test is still failing on one of the Windows build bots:
> http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015
>
> From lookin
I committed the fix in r319836.
On 5 December 2017 at 12:49, Alex L wrote:
> Thanks, I will take a look at it right now. I believe your solution is the
> right fix.
>
> On 5 December 2017 at 07:09, Sean Eveson wrote:
>
>> Hi,
>>
>> It looks like the test is still failing on one of the Windows b
I missed that one, thanks!
Sorry about the breakages.
On 5 December 2017 at 15:04, Douglas Yung via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: dyung
> Date: Tue Dec 5 15:04:12 2017
> New Revision: 319848
>
> URL: http://llvm.org/viewvc/llvm-project?rev=319848&view=rev
> Log:
> Fi
Thanks!
On 10 December 2017 at 03:05, Simon Pilgrim via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rksimon
> Date: Sun Dec 10 03:05:14 2017
> New Revision: 320297
>
> URL: http://llvm.org/viewvc/llvm-project?rev=320297&view=rev
> Log:
> Fix MSVC 'not all control paths return a val
Thanks for the fix!
On Mon, 26 Aug 2019 at 10:29, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Mon Aug 26 10:31:06 2019
> New Revision: 369932
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369932&view=rev
> Log:
> Fix use of invalidated iterator i
Thanks, I recommitted it in r309386.
On 27 July 2017 at 15:53, Hans Wennborg wrote:
> On Thu, Jul 27, 2017 at 3:41 AM, Alex L wrote:
> >
> >
> > On 26 July 2017 at 22:32, Hans Wennborg wrote:
> >>
> >> On Wed, Jul 26, 2017 at 11:27 AM, Hans Wennborg
> wrote:
> >> > On Wed, Jul 26, 2017 at 5:2
That's an interesting case. I'll tweak the warning to diagnose this
scenario better today.
On 29 July 2017 at 00:56, Hans Wennborg wrote:
> On Fri, Jul 28, 2017 at 7:41 AM, Alex Lorenz via cfe-commits
> wrote:
> > Author: arphaman
> > Date: Fri Jul 28 07:41:21 2017
> > New Revision: 309386
> >
Add a note with a fixit in r309559.
On 31 July 2017 at 10:50, Alex L wrote:
> That's an interesting case. I'll tweak the warning to diagnose this
> scenario better today.
>
> On 29 July 2017 at 00:56, Hans Wennborg wrote:
>
>> On Fri, Jul 28, 2017 at 7:41 AM, Alex Lorenz via cfe-commits
>> wro
Ping?
On 21 July 2017 at 10:44, Alex L wrote:
> Hans, can you please merge this to the LLVM 5.0 branch?
>
> AFAIK It's a recent regression that should get fixed in LLVM 5.0.
>
> Cheers,
> Alex
>
>
> On 21 July 2017 at 10:24, Ilya Biryukov via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
Hi Hans & Richard,
Is it possible to get this merged into LLVM 5.0?
Cheers,
Alex
On 11 August 2017 at 13:06, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Fri Aug 11 05:06:52 2017
> New Revision: 310706
>
> URL: http://llvm.org/viewvc/llvm-project?r
Sure, I committed r310829 which moves the lexical decl adjustment.
Hans, can you please merge r310706 with r310829.
Cheers,
Alex
On 12 August 2017 at 01:29, Richard Smith wrote:
> On 11 August 2017 at 17:20, Bruno Cardoso Lopes via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Ale
It's an NFC, thus untested.
On 14 August 2017 at 17:19, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Mon Aug 14 09:19:24 2017
> New Revision: 310853
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310853&view=rev
> Log:
> [rename] Introduce symbol o
Hi Hans,
Can you please merge this into LLVM 5? It fixes a rather serious
Objective-C bug that I introduced just a couple of weeks before the branch.
Cheers,
Alex
On 22 August 2017 at 11:38, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Tue Aug 22 0
Hi Richard,
It looks like this commit caused PR34298 (https://bugs.llvm.org/show_bu
g.cgi?id=34298). Now Clang fails to compile a libc++ std::function member
variable with an incomplete return type. Libstdc++ works though, so I
assume that the right way to fix this is to change libc++?
Cheers,
Al
Hi Richard,
I posted a patch that partially reverts your commit:
https://reviews.llvm.org/D72411. Unfortunately I can't revert it fully.
Thanks,
Alex
On Mon, 11 Nov 2019 at 15:30, Alex L wrote:
> Here's a reduced test case.
>
> ```
> // OPTIONS: -x objective-c -std=gnu99 -fobjc-arc -emit-llvm
Hi Rchard,
Some of our code started triggering the warning you added in this code, but
I'm not sure if the warning is actually valid or not in this case:
https://godbolt.org/z/9fxs3K
namespace geo {
template
class optional {
optional() { }
~optional();
};
}
template
geo::optional::~optiona
Hi Richard,
I have a question about this commit. It looks like it started emitting
`cxa_guard_acquire/release` calls in Objective-C code, for globals with
constant initializers, causing link failures for things that don't link
with libc++abi. Was that intentional? I'm still working on a reduced
te
Here's a reduced test case.
```
// OPTIONS: -x objective-c -std=gnu99 -fobjc-arc -emit-llvm
@interface Foo
@end
Foo *foo() {
static Foo *f = ((void*)0;
return f;
}
// CHECK-NOT: cxa_guard
```
AFAIK clang should not emit C++ guard variables in non-C++ code. Is that
correct?
On Mon, 11 Nov 20
Hi Puyan,
This commit caused two Clang failures on Darwin:
Clang :: InterfaceStubs/merge-conflict-test.c
Clang :: InterfaceStubs/object-float.c
Here's the build log from out bot:
http://lab.llvm.org:8080/green/job/clang-stage1-RA/3929/console
Can you please resolve the issue with the te
Hi Galina,
Thanks for doing this! I'm curious as to how the buildbot CI communicates
with Github, is the buildbot itself capable of performing the Github API
requests, or do you have an external tool/script that does that?
Thanks,
Alex
On Mon, 25 Nov 2019 at 12:59, Galina Kistanova via cfe-commi
On 3 April 2018 at 14:30, Chandler Carruth wrote:
> On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: arphaman
>> Date: Tue Apr 3 13:50:05 2018
>> New Revision: 329110
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=329110&view=rev
This doesn't seem like a good permanent solution (as Paul pointed out -std
will change in the future). Will you be able to avoid this in the future?
On 15 November 2017 at 11:38, Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: sammccall
> Date: Wed Nov 15 11:38:09 2017
>
Thanks for working on this patch! I'm sorry to say but I had an earlier
patch in review that fixes this issue (https://reviews.llvm.org/D26964). I
think my patch covers all of the decl kinds that are fixed by this patch. I
plan on committing my patch today.
Alex
On 29 December 2016 at 23:35, Fang
Hi,
Can you please add a suitable test-case? Clang's code-completion tests are
normally in test/CodeCompletion or test/Index.
Cheers,
Alex
On 21 March 2017 at 12:05, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> There are a number of users of the clang static
Thanks, can you please attach a diff that includes both the code change and
the new test?
On 21 March 2017 at 14:18, Dixon Ryan (ETAS/ERS-PD2) via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Sending to mailing list.
>
>
>
> *From:* Dixon Ryan (ETAS/ERS-PD2)
> *Sent:* 21 March 2017 14:18
>
Thanks,
It looks like your solution isn't quite right as it causes Clang to accept
invalid access to protected members, e.g. as tested by
"test/CXX/class.access/class.protected/p1.cpp".
Do you think there's an alternative solution that you could use?
Alex
On 21 March 2017 at 14:48, Dixon Ryan (
On 5 April 2017 at 13:38, Duncan Exon Smith wrote:
>
>
> > On Apr 5, 2017, at 05:13, Aaron Ballman via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > aaron.ballman added inline comments.
> >
> >
> >
> > Comment at: lib/Sema/SemaAttr.cpp:578
> > +return;
> > + Diag(
Thanks Duncan!
On 15 April 2017 at 01:25, Duncan P. N. Exon Smith
wrote:
> FYI, I reverted the modules side of this in r300380. For details, see the
> commit message. TL;DR: this didn't actually make modules builds closer to
> matching non-modules builds, thanks to how submodules work; on the
I think you've got the wrong Phabricator link in the commit log.
On 18 April 2017 at 15:27, Martell Malone via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: martell
> Date: Tue Apr 18 09:27:36 2017
> New Revision: 300555
>
> URL: http://llvm.org/viewvc/llvm-project?rev=300555&view=re
No problem, thanks for the quick update!
On 18 April 2017 at 15:56, Martell Malone wrote:
> Yes I do :)
> I updated https://reviews.llvm.org/D15005 with a comment incase anyone
> goes there.
> I also updated https://reviews.llvm.org/D15006 (the correct link) to
> point to the commit revision.
>
Hi Hans,
Would it be possible to merge this for 4.0?
Cheers,
Alex
On 19 January 2017 at 17:17, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Thu Jan 19 11:17:57 2017
> New Revision: 292497
>
> URL: http://llvm.org/viewvc/llvm-project?rev=292497&view
Hi Vedant,
This commit has caused a compiler crash in our stage 2 green dragon
ASAN+Ubsan bot (
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_build/). I have
reverted it in r293475. The following example reproduces the crash with
-fsanitize=undefined :
typedef unsigned long long u
Hi Benjamin,
This commit has caused a linking in our stage 2 modules buildbot at
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/.
Specifically, after this commit 'clang-reorder-fields' gets the following
linking error:
FAILED: bin/clang-reorder-fields
: &&
/Users/buildslave/jen
I've narrowed the problem down to the difference in the linkage type for
"clang::ast_matchers::recordDecl" between the module and non-module build:
Module:
@_ZN5clang12ast_matchersL10recordDeclE = external global
%"class.clang::ast_matchers::internal::VariadicDynCastAllOfMatcher.847",
align 1
Non
Hi Hans,
Would it be possible to merge this for 4.0?
Cheers,
Alex
On 1 February 2017 at 17:37, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Wed Feb 1 11:37:28 2017
> New Revision: 293787
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293787&view
Thanks!
On 1 February 2017 at 18:57, Hans Wennborg wrote:
> OK. Merged in r293797.
>
> Thanks,
> Hans
>
> On Wed, Feb 1, 2017 at 9:50 AM, Alex L wrote:
> > Hi Hans,
> >
> > Would it be possible to merge this for 4.0?
> >
> > Cheers,
> > Alex
> >
> > On 1 February 2017 at 17:37, Alex Lorenz via
Hi Hans,
Is there any chance we can merge this for 4.0? It fixed a nasty bug where
clang didn't catch invalid ObjC++ code during semantic analysis which led
to invalid object files or crashes in CodeGen.
Cheers,
Alex
On 3 February 2017 at 14:22, Alex Lorenz via cfe-commits <
cfe-commits@lists.ll
like a modules compiler bug, as opposed to a problem in the
> commit itself. Alex, can you file a PR for this?
>
> > On 2017-Feb-01, at 07:35, Alex L via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > I've narrowed the problem down to the diff
Thanks!
On 3 February 2017 at 22:34, Hans Wennborg wrote:
> Thanks! r294059.
>
> On Fri, Feb 3, 2017 at 2:29 PM, Richard Smith
> wrote:
> > It looks like the only cases it should have any real impact on are those
> > where we would previously miscompile/crash, so this seems OK to me to
> merge
It worked!
On 30 June 2017 at 18:15, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arphaman
> Date: Fri Jun 30 10:15:48 2017
> New Revision: 306844
>
> URL: http://llvm.org/viewvc/llvm-project?rev=306844&view=rev
> Log:
> Attempt to fix the linkage error caused by r30
Thanks, I'll take a look.
On 19 July 2017 at 13:31, Hans Wennborg wrote:
> On Wed, Jul 19, 2017 at 2:26 PM, Hans Wennborg wrote:
> > On Wed, Jul 19, 2017 at 1:30 PM, Alex Lorenz via cfe-commits
> > wrote:
> >> Author: arphaman
> >> Date: Wed Jul 19 04:30:41 2017
> >> New Revision: 308441
> >>
Hans, can you please merge this to the LLVM 5.0 branch?
AFAIK It's a recent regression that should get fixed in LLVM 5.0.
Cheers,
Alex
On 21 July 2017 at 10:24, Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: ibiryukov
> Date: Fri Jul 21 02:24:00 2017
> New Revision
On 26 July 2017 at 22:32, Hans Wennborg wrote:
> On Wed, Jul 26, 2017 at 11:27 AM, Hans Wennborg wrote:
> > On Wed, Jul 26, 2017 at 5:20 AM, Alex Lorenz via cfe-commits
> > wrote:
> >> Author: arphaman
> >> Date: Wed Jul 26 05:20:57 2017
> >> New Revision: 309106
> >>
> >> URL: http://llvm.org/
Hi Roman,
This commit has caused a regression in LLVM 6 which now triggers
-Wsign-compare for typeof(enum) and typeof(enumConstant). I filed
https://bugs.llvm.org/show_bug.cgi?id=36008. Could you please take a look
at it?
Thanks,
Alex
On 21 October 2017 at 09:44, Roman Lebedev via cfe-commits <
Hello Eric,
I think that this commit (r287435) might have broken the green dragon stage
2 ASAN + UBSAN buildbot:
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/2643/
I'm not sure why exactly the tests fail, since ASAN/UBSAN isn't triggering
anything, and it's just a module err
On 30 November 2016 at 15:46, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Hi Steven,
>
> On Fri, Jun 3, 2016 at 2:36 PM, Steven Wu via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi everyone
>>
>> I am still in the process of upstreaming some improvements to the e
Hi Vitaly,
I noticed that you posted this patch up for review at
https://reviews.llvm.org/D27422, but then committed it instantly without
waiting for approval (and you did the same for r288685 as well). Is there
any particular reason why you did this? I think that you should've waited
for approval
On 6 December 2016 at 19:39, Vitaly Buka wrote:
> Hi Alex,
>
>
>
> On Tue, Dec 6, 2016 at 11:14 AM Alex L wrote:
>
> Hi Vitaly,
>
> I noticed that you posted this patch up for review at
> https://reviews.llvm.org/D27422, but then committed it instantly without
> waiting for approval (and you did
Hi,
On 21 April 2017 at 12:55, Emilio Cobos Álvarez via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> This allows us to get the default template parameters too.
>
> This patch was submitted also as https://reviews.llvm.org/D31732, but I
> see no
> reference to it in cfe-commits or llvm-commi
Hi Richard,
This commit has caused an infinite loop in one of our internal libclang
based tooling tests. It keeps repeating the following frames:
frame #33528: 0x000109db2edf
libclang.dylib`clang::DiagnosticsEngine::ReportDelayed(this=0x00011c002c00)
at Diagnostic.cpp:149
frame #3
1 - 100 of 108 matches
Mail list logo
