Re: [clang] 0e3a487 - PR12350: Handle remaining cases permitted by CWG DR 244.

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

Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it

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

Re: Github build status reporting

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

Re: [clang] 7342912 - [clang][IFS] Driver Pipeline: generate stubs after standard pipeline (3)

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

Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it

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

Re: r373159 - For P0784R7: compute whether a variable has constant destruction if it

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

Re: r369932 - Fix use of invalidated iterator introduced by r369680.

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=rev > Log: > Fix use of invalidated iterator

Re: r368354 - Mark clang-scan-deps test as requiring thread support

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

Re: r368354 - Mark clang-scan-deps test as requiring thread support

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 >

Re: [PATCH] D64149: [clang-scan-deps] use `-Wno-error` when scanning for dependencies

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

Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find

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

Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find

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

Re: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find

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=rev > Log: > [clang-scan-deps] initial outline of the tool that runs

Re: r363009 - [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer

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. > >

Re: r363009 - [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer

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

Re: r357713 - Verify that Android targets generate DWARF 4 by default.

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.

Re: r357713 - Verify that Android targets generate DWARF 4 by default.

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

Re: r357713 - Verify that Android targets generate DWARF 4 by default.

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:

Re: r351459 - [ObjC] Follow-up r350768 and allow the use of unavailable methods that are

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:

Re: r350768 - [ObjC] Allow the use of implemented unavailable methods from within

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

Re: r350768 - [ObjC] Allow the use of implemented unavailable methods from within

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.

Re: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"

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

Re: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"

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 > >

Re: r336716 - Revert r336590 "[libclang] evalute compound statement cursors before trying to evaluate"

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

Re: r350282 - [libclang] CoroutineBody/Coreturn statements are UnexposedStmts and not Exprs

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:

Re: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++

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

Re: [cfe-dev] r347339 - [clang][Parse] Diagnose useless null statements / empty init-statements

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

Re: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++

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++' "? >>> >> >>

Re: r335081 - Recommit r335063: [Darwin] Add a warning for missing include path for libstdc++

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

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

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

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

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 < >>>

Re: [PATCH] D50154: [clangd] capitalize diagnostic messages

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:

Re: [clang-tools-extra] r338518 - [clangd] Receive compilationDatabasePath in 'initialize' request

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 >

Re: [clang-tools-extra] r338518 - [clangd] Receive compilationDatabasePath in 'initialize' request

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:

Re: [libcxx] r337727 - [CMake] Fix the setting of LIBCXX_HEADER_DIR

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

Re: [libcxx] r337727 - [CMake] Fix the setting of LIBCXX_HEADER_DIR

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

Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs

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:

Re: r313729 - Implement C++ [basic.link]p8.

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

Re: r316268 - [Sema] Fixes for enum handling for tautological comparison diagnostics

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 <

Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target

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

Re: r315984 - [CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info

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:

Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target

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

Re: r321099 - [driver][darwin] Take the OS version specified in "-target" as the target

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

Re: r313729 - Implement C++ [basic.link]p8.

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

Re: r320734 - [Preprocessor] Implement __is_target_{arch|vendor|os|environment} function-like

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:

Re: r320297 - Fix MSVC 'not all control paths return a value' warning

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=rev > Log: > Fix MSVC 'not all control paths return a value'

Re: r319848 - Fix another record-parsing-invocation.c test issue on Windows

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=rev > Log: > Fix

Re: r319715 - Fix record-parsing-invocation.c test on Windows

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

Re: r319715 - Fix record-parsing-invocation.c test on Windows

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: >

Re: [clang-tools-extra] r318327 - [clangd] Try to unbreak tests on PS4 by targeting PC explicitly

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

Re: r316152 - Fix a few nits in RenamingAction.

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=rev > Log: > Fix a few nits in RenamingAction. > > * Add missing

Re: r315755 - Fix -Woverloaded-virtual warning in clang-refactor

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

Re: r315755 - Fix -Woverloaded-virtual warning in clang-refactor

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

Re: r309386 - Recommit r308327 3rd time: Add a warning for missing

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

Re: [clang-tools-extra] r313754 - [clangd] Serialize onDiagnosticsReady callbacks for the same file.

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.

Re: [clang-tools-extra] r313754 - [clangd] Serialize onDiagnosticsReady callbacks for the same file.

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

Re: r310983 - PR19668, PR23034: Fix handling of move constructors and deleted copy

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=rev > Log: > PR19668, PR23034: Fix handling of move constructors and

Re: r312633 - [AST] Traverse CXXOperatorCallExpr in LexicallyOrderedRecursiveASTVisitor

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

Re: r284549 - DR1330: instantiate exception-specifications when "needed". We previously did

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,

Re: r311443 - [ObjC] Check written attributes only when synthesizing ambiguous property

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

Re: r310853 - [rename] Introduce symbol occurrences

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=rev > Log: > [rename] Introduce symbol

Re: r310706 - [modules] Set the lexical DC for dummy tag decls that refer to hidden

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 < >

Re: r310706 - [modules] Set the lexical DC for dummy tag decls that refer to hidden

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:

Re: r308722 - Fixed failing assert in code completion.

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 < >

Re: r309386 - Recommit r308327 3rd time: Add a warning for missing

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

Re: r309386 - Recommit r308327 3rd time: Add a warning for missing

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

Re: r309106 - Recommit r308327 2nd time: Add a warning for missing

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,

Re: r309106 - Recommit r308327 2nd time: Add a warning for missing

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

Re: r308722 - Fixed failing assert in code completion.

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

Re: r308441 - Recommit r308327: Add a warning for missing '#pragma pack (pop)'

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

Re: r306844 - Attempt to fix the linkage error caused by r306840 on the mingw-RA-on-linux bot

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=rev > Log: > Attempt to fix the linkage error caused by r306840

Re: r305719 - [Parser][ObjC] Use an artificial EOF token while parsing lexed ObjC methods

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:

Re: r302677 - [libclang] Introduce clang_Cursor_isExternalSymbol that provides info about decls marked with external_source_symbol attribute

On 10 May 2017 at 16:10, Argyrios Kyrtzidis via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: akirtzidis > Date: Wed May 10 10:10:36 2017 > New Revision: 302677 > > URL: http://llvm.org/viewvc/llvm-project?rev=302677=rev > Log: > [libclang] Introduce clang_Cursor_isExternalSymbol

Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.

On 4 May 2017 at 12:52, Alex L wrote: > > > On 4 May 2017 at 12:43, Alex L wrote: > >> >> >> On 3 May 2017 at 22:23, Richard Smith wrote: >> >>> On 3 May 2017 at 07:29, Alex L wrote: >>> Hi Richard,

Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.

On 4 May 2017 at 12:43, Alex L wrote: > > > On 3 May 2017 at 22:23, Richard Smith wrote: > >> On 3 May 2017 at 07:29, Alex L wrote: >> >>> Hi Richard, >>> >>> This commit has caused an infinite loop in one of our internal libclang

Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.

On 3 May 2017 at 22:23, Richard Smith wrote: > On 3 May 2017 at 07:29, Alex L wrote: > >> Hi Richard, >> >> This commit has caused an infinite loop in one of our internal libclang >> based tooling tests. It keeps repeating the following frames: >> >>

Re: r301992 - [modules] Round-trip -Werror flag through explicit module build.

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

Re: [PATCH] [libclang] Check for a record declaration before a template specialization.

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

Re: r300555 - Driver: Better detection of mingw-gcc

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

Re: r300555 - Driver: Better detection of mingw-gcc

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=rev >

Re: r299226 - [Modules][PCH] Serialize #pragma pack

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

Re: [PATCH] D30009: Add support for '#pragma clang attribute'

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 > > +

Re: FW: SemaAccess bug (protected members of derived)

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

Re: FW: SemaAccess bug (protected members of derived)

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 >

Re: SemaAccess bug (protected members of derived)

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

Re: r294008 - [Sema][ObjC++] Typo correction should handle ivars and properties

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

Re: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.

les/builds/2728 > > This looks 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 d

Re: r294008 - [Sema][ObjC++] Typo correction should handle ivars and properties

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 <

Re: r293787 - [CodeGen][ObjC] Avoid asserting on block pointer types in

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

Re: r293787 - [CodeGen][ObjC] Avoid asserting on block pointer types in

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=rev

Re: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.

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

Re: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.

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 : &&

Re: r293343 - [ubsan] Sanity-check shift amounts before truncation (fixes PR27271)

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

Re: r292497 - [Sema] Fix PR28181 by avoiding calling BuildOverloadedBinOp in C mode

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=rev

Re: [PATCH] Add missing Decl::Kind for -print-decl-contexts

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,

Re: r288689 - Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec

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

Re: r288689 - Fix stack-use-after-scope in CheckExplicitlyDefaultedMemberExceptionSpec

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

Re: [RFC] Embedded bitcode and related upstream (Part II)

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

Re: [libcxx] r287435 - Fix stdint/cstdint modules

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

Re: [PATCH] D25816: Use descriptive message if list initializer is incorrectly parenthesized.

I think you can go ahead and commit it, yes. Alex On 11 November 2016 at 05:28, Serge Pavlov wrote: > Is it OK to commit this patch? > > Thanks, > --Serge > > 2016-10-21 18:21 GMT+07:00 Alex Lorenz : > >> arphaman added a subscriber: rsmith. >> arphaman

  1   2   >