@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -5401,6 +5409,8 @@ std::string CGDebugInfo::GetName(const Decl *D, bool
Qualified) const {
// feasible some day.
return TA.getAsIntegral().getBitWidth() <= 64 &&
IsReconstitutableType(TA.getIntegralType());
+ case Template
https://github.com/dwblaikie commented:
neat idea (I imagine some debuggers will trip over the space in the inlined
name, but seems pretty good)
I'd guess sometimes we'll lose the inlined debug info if two of these traps are
merged, fwiw - but it's probably relatively robust, apart from that.
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify %s
+
+#if !__has_builtin(__builtin_verbose_trap)
+#error
+#endif
dwblaikie wrote:
Is this necessary?
https://github.com/llvm/llvm-project/pull/79230
__
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Could you show the stack (omitting/annotating the repeated part) that leads to
failure? and/or the AST shape that leads to failure?
https://github.com/llvm/llvm-project/pull/79875
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
Be good to have more description of "why" in commit messages in general
(the "what" is provided by the patch itself, especially when it's a small
one like this) - I guess this was to match naming conventions, that this
file generally already follows lower-first, etc.
On Tue, Jan 16, 2024 at 7:04 A
In general, if the lambda is only used within its scope, I'd suggest
switching to a default ref capture "[&]" to reduce maintenance burden of
keeping the capture list up to date.
On Thu, Jan 11, 2024 at 12:09 PM Kazu Hirata via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Kazu Hir
Ah, no worries - thanks for being aware of it & I get we're all having some
teething problems with github, etc.
On Wed, Jan 17, 2024 at 3:36 PM Erich Keane wrote:
> yeah, something weird happened with this one that i haven't figured out
> yet. This was a response to a review comment, and was on
dwblaikie wrote:
> @zmodem template parameter shadowing is an extension with
> `-fms-compatibility`, if that works
Given the prevalence (wellr, given how quickly folks have tripped over it
probably indicates it's fairly prevalent), I think it'll need to be/should be
pulled out into its own wa
@@ -62,7 +62,7 @@ def err_ast_file_out_of_date : Error<
"%select{PCH|module|AST}0 file '%1' is out of date and "
"needs to be rebuilt%select{|: %3}2">, DefaultFatal;
def err_ast_file_invalid : Error<
- "file '%1' is not a valid precompiled %select{PCH|module|AST}0 file">,
dwblaikie wrote:
Does MSVC have the delayed template parsing effects when using modules? If not,
perhaps we should just disable the flag/not allow it to be composed together?
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing list
https://github.com/dwblaikie approved this pull request.
Looks good.
I wonder how this happened in the first place - that the author of the
diagnostic was already adding the 3rd parameter into the arguments but there
was no `%2` in the diagnostic text/template...
It'd be great if we had some
dwblaikie wrote:
> > I still support disabling delayed template parsing by default in all
> > configurations. Ultimately, this feature is a source of bugs, and we should
> > start the clock on its deprecation and removal. This, of course, involves
> > real work, and I haven't allocated any tim
dwblaikie wrote:
> > FWIW, I think we also saw, internally at Google, some significant and
> > surprising (growth in sections, like .debug_loclists and
> > .debug_gnu_pubnames/types) that were a bit surprising/not what I'd have
> > expected of the original committed/reverted patch.
> > Could y
dwblaikie wrote:
> ```c++
> struct A {
> short a1;
> short a2;
> };
>
> struct B {
> [[clang::preferred_type(A)]] unsigned b1 : 32 = 0x000F'000C;
> };
>
> int main()
> {
> B b;
> return b.b1;
> }
> ```
An example where the layout doesn't match the normal struct layout might be
m
@@ -3153,6 +3153,12 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def warn_attribute_und
@@ -3153,6 +3153,12 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def warn_attribute_und
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie approved this pull request.
Some minor comments but generally looks good to me.
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+ (Std->contain
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+ (Std->contain
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+ (Std->contain
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/68986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/68986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -731,6 +731,29 @@ class MetadataLoader::MetadataLoaderImpl {
upgradeCULocals();
}
+ void cloneLocalTypes() {
+for (int I = MetadataList.size() - 1; I >= 0; --I) {
dwblaikie wrote:
any particular reason this iterates in reverse? Probably worth a
@@ -0,0 +1,43 @@
+; RUN: llvm-as < %s -o %t0
+; RUN: llvm-dis %t0 -o - | FileCheck %s
+
dwblaikie wrote:
might be worth a comment describing the purpose of this test (some info from
the commit message, probably)
https://github.com/llvm/llvm-project/pull/68986
_
On Mon, Aug 26, 2019 at 11:28 AM Duncan P. N. Exon Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: dexonsmith
> Date: Mon Aug 26 11:29:51 2019
> New Revision: 369943
>
> URL: http://llvm.org/viewvc/llvm-project?rev=369943&view=rev
> Log:
> FileManager: Use llvm::Expected in ne
On Thu, Sep 5, 2019 at 9:57 AM Duncan P. N. Exon Smith
wrote:
>
>
> On Sep 4, 2019, at 17:39, David Blaikie wrote:
>
>
>
> On Mon, Aug 26, 2019 at 11:28 AM Duncan P. N. Exon Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dexonsmith
>> Date: Mon Aug 26 11:29:51 2019
>>
Any resolution/discussion on this crash?
On Thu, Sep 5, 2019 at 12:49 PM Erik Pilkington via cfe-commits
wrote:
>
> Hi Alexandre,
>
> Looks like this commit is causing crashes on darwin, can you take a look
> please? Here is a failing bot:
> http://lab.llvm.org:8080/green/job/clang-stage1-RA/16
On Fri, Jul 28, 2017 at 10:24 AM Kevin Enderby wrote:
> On Jul 27, 2017, at 9:50 PM, Saleem Abdulrasool via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
> compnerd added a comment.
>
> Does anyone use the overload with the `O` for `exports` with `nullptr`
> instead of `this`? If not, we co
On Fri, Jul 28, 2017 at 4:01 PM Kevin Enderby wrote:
> On Jul 28, 2017, at 10:30 AM, David Blaikie wrote:
>
>
>
> On Fri, Jul 28, 2017 at 10:24 AM Kevin Enderby wrote:
>
>> On Jul 27, 2017, at 9:50 PM, Saleem Abdulrasool via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>> compnerd added
On Thu, Jul 27, 2017 at 6:35 PM Erik Pilkington via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: epilk
> Date: Thu Jul 27 18:35:14 2017
> New Revision: 309349
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309349&view=rev
> Log:
> [demangler] Fix some overzealous -Wreturn-type erro
Test coverage?
On Sun, Jul 30, 2017 at 5:52 AM Lenar Safin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: lll
> Date: Sat Jul 29 13:42:58 2017
> New Revision: 309496
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309496&view=rev
> Log:
> Improve readability of CXX method overrid
On Tue, Jul 25, 2017 at 1:19 AM Roman Lebedev via Phabricator via
cfe-commits wrote:
> lebedev.ri added a comment.
>
> How does this relate to the gcc behavior?
> I suspect not everyone would want to have this relaxed `-Wshadow` mode.
>
Generally I think the goal hasn't been to allow a clang use
On Thu, Jul 27, 2017 at 8:30 AM Dehao Chen via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> danielcdh marked an inline comment as done.
> danielcdh added a comment.
>
> Thanks for the review!
>
> In https://reviews.llvm.org/D35746#822498, @chandlerc wrote:
>
> > LGTM with a t
Not sure I understand the context for these changes - could you describe
the motivation(s) in more detail?
On Sun, Aug 6, 2017 at 10:39 PM Mandeep Singh Grang via Phabricator <
revi...@reviews.llvm.org> wrote:
> mgrang created this revision.
>
> This patch is in response to https://reviews.llvm.o
On Mon, Aug 7, 2017 at 12:08 PM Mandeep Singh Grang via Phabricator <
revi...@reviews.llvm.org> wrote:
> mgrang added a comment.
>
> This patch does 3 things:
>
> 1. Get rid of the unit test objc-modern-metadata-visibility2.mm because
> this test check uses flag -reverse-iterate. This flag will be
Author: dblaikie
Date: Wed Aug 9 11:34:22 2017
New Revision: 310508
URL: http://llvm.org/viewvc/llvm-project?rev=310508&view=rev
Log:
PointerLikeTypeTraits: class->struct to match LLVM change
Modified:
cfe/trunk/include/clang/AST/CanonicalType.h
cfe/trunk/include/clang/AST/DeclCXX.h
On Wed, Aug 9, 2017 at 1:44 AM Grang, Mandeep Singh
wrote:
> In D35043 I have removed the llvm tests which use -reverse-iterate. This
> patch removes the clang tests.
>
Ah, OK. I'm still curious about whether this results in a loss of test
coverage. Without this test, would the bug it was testin
OK - go ahead and remove the tests then, if the functionality is now
covered by the buildbot+existing tests.
On Wed, Aug 9, 2017 at 12:04 PM Grang, Mandeep Singh
wrote:
> > Ah, OK. I'm still curious about whether this results in a loss of test
> coverage. Without this test, would the bug it was
It's helpful to mention why a patch is reverted in the commit message that
reverts. Thought for next time! :)
On Tue, Aug 8, 2017 at 9:46 AM Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: abataev
> Date: Tue Aug 8 09:45:36 2017
> New Revision: 310379
>
> URL: http:/
On Thu, Dec 26, 2019 at 11:58 PM Djordje Todorovic <
djordje.todoro...@rt-rk.com> wrote:
> Hi David,
>
> It's a good question.
>
> Current approach of the debug entry values will consider an entry value as
> a valid value until the variable gets modified.
>
> Please consider this.
>
> void fn(int
Author: David Blaikie
Date: 2019-12-27T12:27:20-08:00
New Revision: d8018233d1ea4234de68d5b4593abd773db79484
URL:
https://github.com/llvm/llvm-project/commit/d8018233d1ea4234de68d5b4593abd773db79484
DIFF:
https://github.com/llvm/llvm-project/commit/d8018233d1ea4234de68d5b4593abd773db79484.diff
Sorry if this is expected behavior, but saw a regression that looks
/plausibly/ correct & is rendered ambiguous by this change so I've gone
ahead and reverted this patch in d8018233d1ea4234de68d5b4593abd773db79484
Comment from the original:
Regressed/causes this to error due to ambiguity:
On Fri, Dec 27, 2019 at 3:48 PM Richard Smith wrote:
> On Fri, 27 Dec 2019 at 12:27, David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> Author: David Blaikie
>> Date: 2019-12-27T12:27:20-08:00
>> New Revision: d8018233d1ea4234de68d
Author: David Blaikie
Date: 2020-09-11T17:45:56-07:00
New Revision: 928d419797ea173090e26f624f08801c7d6661e3
URL:
https://github.com/llvm/llvm-project/commit/928d419797ea173090e26f624f08801c7d6661e3
DIFF:
https://github.com/llvm/llvm-project/commit/928d419797ea173090e26f624f08801c7d6661e3.diff
LLVM_DUMP_METHOD is meant to be used for annotating functions that might be
useful to execute from a debugger to dump data structures, etc - so it's
expected that they'd be unused. Do you find that this function is not
useful to use from a debugger/similar situation? (or perhaps because the
functio
On Sat, Sep 12, 2020 at 1:15 AM Vitaly Buka wrote:
> build fails with -DLLVM_ENABLE_WERROR=ON
>
Oh, I see - it's a -Wunused-function when building with LLVM_ENABLE_DUMP
off.
Kristof - if/when you want to recommit this, I think the only thing you
need to do is make this function not function-loc
Usually this would be addressed with a "using Base::Function" - makes it
clear you aren't intending to override any base behavior, just want to
continue to expose the full overload set
On Mon, Aug 24, 2020 at 8:11 AM Raphael Isemann via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author:
On Mon, Aug 24, 2020 at 9:32 PM Voss, Matthew via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Hi Amy,
>
> Looks like there's some test failures on the PS4 Linux bot as a result of
> this commit. Could you take a look? If the failure persists for a while, I
> may need to revert this to unclo
Would be handy to include a comment to document which compiler version, etc
- so we know when we can remove this/don't waste time trying to remove it
too soon.
On Thu, Dec 17, 2020 at 3:51 AM Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Sam McCall
> Date: 2020-12-17
oh, fair - I didn't stop to notice this was over in
Clang/non-llvm-namespace'd code, so yeah, sounds good!
On Mon, Dec 21, 2020 at 10:49 PM Sam McCall wrote:
> Yeah. I don't actually know those details, the phab revision referenced
> (should have been a URL, oops) is all I know.
>
> The new vers
On Tue, Oct 27, 2020 at 2:21 PM Sriraman Tallam via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
>
> On Tue, Oct 27, 2020 at 2:14 PM David Blaikie via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> dblaikie added a comment.
>>
>> @tmsriram ping on the follow-up here
>>
>
> I checked i
On Wed, Nov 4, 2020 at 8:08 PM Fāng-ruì Sòng wrote:
> I checked chmod -w a.dwo; clang -cc1 -debug-info-kind=limited
> -dwarf-version=4 -split-dwarf-file a.dwo -split-dwarf-output a.dwo
> -emit-obj -o - split-debug-output.c
> which suppresses the output, so -fbasic-block-sections=list= should
> fo
On Wed, Nov 4, 2020 at 9:07 PM Fāng-ruì Sòng wrote:
>
> It is rare to report an error in BackendUtil.cpp . So I checked the
> other Diags.Report instance and noticed that -split-dwarf-file a.dwo
> -split-dwarf-output a.dwo (when a.dwo is not writable) suppresses the
> output. So there is no reason
Author: David Blaikie
Date: 2020-11-09T23:27:47-08:00
New Revision: 724877e219cd219c4b757f10ac4484193cd30c6a
URL:
https://github.com/llvm/llvm-project/commit/724877e219cd219c4b757f10ac4484193cd30c6a
DIFF:
https://github.com/llvm/llvm-project/commit/724877e219cd219c4b757f10ac4484193cd30c6a.diff
Neat!
On Wed, Nov 11, 2020 at 3:08 PM Richard Smith via cfe-commits
wrote:
>
>
> Author: Richard Smith
> Date: 2020-11-11T15:05:51-08:00
> New Revision: 5f12f4ff9078455cad9d4806da01f570553a5bf9
>
> URL:
> https://github.com/llvm/llvm-project/commit/5f12f4ff9078455cad9d4806da01f570553a5bf9
> DIFF
On Wed, Nov 11, 2020 at 3:08 PM Richard Smith via cfe-commits
wrote:
>
>
> Author: Richard Smith
> Date: 2020-11-11T15:05:51-08:00
> New Revision: e7f3e2103cdb567dda4fd52f81bf4bc07179f5a8
>
> URL:
> https://github.com/llvm/llvm-project/commit/e7f3e2103cdb567dda4fd52f81bf4bc07179f5a8
> DIFF:
> ht
On Mon, Nov 16, 2020 at 7:24 PM Richard Smith wrote:
>
> On Mon, 16 Nov 2020 at 18:49, David Blaikie wrote:
>>
>> On Wed, Nov 11, 2020 at 3:08 PM Richard Smith via cfe-commits
>> wrote:
>> >
>> >
>> > Author: Richard Smith
>> > Date: 2020-11-11T15:05:51-08:00
>> > New Revision: e7f3e2103cdb567dd
Author: David Blaikie
Date: 2020-12-03T20:41:06-08:00
New Revision: c4af1c8d939b21ac7deb631887fc26db7451c592
URL:
https://github.com/llvm/llvm-project/commit/c4af1c8d939b21ac7deb631887fc26db7451c592
DIFF:
https://github.com/llvm/llvm-project/commit/c4af1c8d939b21ac7deb631887fc26db7451c592.diff
Author: LemonBoy
Date: 2020-10-22T14:14:19-07:00
New Revision: fd14a1f6fff37ef62a35ca0f8bc630ac8b23516d
URL:
https://github.com/llvm/llvm-project/commit/fd14a1f6fff37ef62a35ca0f8bc630ac8b23516d
DIFF:
https://github.com/llvm/llvm-project/commit/fd14a1f6fff37ef62a35ca0f8bc630ac8b23516d.diff
LOG:
If this is meant to be NFC, I guess the function is never meant to return
null? (it's meant to be an invariant of the code that at least one of the
builders is valid) - if that's the case, I'm not sure if this is good
change.
If there is a bug in the future that causes there to be an no valid buil
Author: David Blaikie
Date: 2021-09-21T11:21:40-07:00
New Revision: 131e8786640a49daf533b7ead4d3b5b82e0aea2a
URL:
https://github.com/llvm/llvm-project/commit/131e8786640a49daf533b7ead4d3b5b82e0aea2a
DIFF:
https://github.com/llvm/llvm-project/commit/131e8786640a49daf533b7ead4d3b5b82e0aea2a.diff
Author: David Blaikie
Date: 2021-09-21T19:30:12-07:00
New Revision: d31dfc30115705332034a81b6b2ab904ca1cf029
URL:
https://github.com/llvm/llvm-project/commit/d31dfc30115705332034a81b6b2ab904ca1cf029
DIFF:
https://github.com/llvm/llvm-project/commit/d31dfc30115705332034a81b6b2ab904ca1cf029.diff
Author: David Blaikie
Date: 2021-09-21T19:30:13-07:00
New Revision: db6f1e8a8857ccaa339304131373f3150528e812
URL:
https://github.com/llvm/llvm-project/commit/db6f1e8a8857ccaa339304131373f3150528e812
DIFF:
https://github.com/llvm/llvm-project/commit/db6f1e8a8857ccaa339304131373f3150528e812.diff
Ping
On Sun, Sep 5, 2021 at 11:28 AM David Blaikie wrote:
> Hey Richard - was just going back over some of the modular codegen code
> (due to a discussion on the EWG mailing list about file extensions that
> ended up touching on the nature of how modules are built) - and I came
> across this cod
Author: David Blaikie
Date: 2021-09-21T20:08:16-07:00
New Revision: 2ff049b12ee3fb60581835a28bf9d0acc1723f23
URL:
https://github.com/llvm/llvm-project/commit/2ff049b12ee3fb60581835a28bf9d0acc1723f23
DIFF:
https://github.com/llvm/llvm-project/commit/2ff049b12ee3fb60581835a28bf9d0acc1723f23.diff
Author: David Blaikie
Date: 2021-09-22T11:11:49-07:00
New Revision: 38c09ea2d279eabe3602e2002f8cdfcc5380
URL:
https://github.com/llvm/llvm-project/commit/38c09ea2d279eabe3602e2002f8cdfcc5380
DIFF:
https://github.com/llvm/llvm-project/commit/38c09ea2d279eabe3602e2002f8cdfcc5380.diff
Author: David Blaikie
Date: 2021-09-23T19:58:32-07:00
New Revision: 25ac0d3c73d68c017546eb622ba7632c6b581bfb
URL:
https://github.com/llvm/llvm-project/commit/25ac0d3c73d68c017546eb622ba7632c6b581bfb
DIFF:
https://github.com/llvm/llvm-project/commit/25ac0d3c73d68c017546eb622ba7632c6b581bfb.diff
Author: David Blaikie
Date: 2021-09-23T20:47:19-07:00
New Revision: e70082e9add7e82e580148fbd4c0a5a832763cb6
URL:
https://github.com/llvm/llvm-project/commit/e70082e9add7e82e580148fbd4c0a5a832763cb6
DIFF:
https://github.com/llvm/llvm-project/commit/e70082e9add7e82e580148fbd4c0a5a832763cb6.diff
Author: David Blaikie
Date: 2021-09-23T21:13:16-07:00
New Revision: 8d9ddd4f509c54d05a38427d7999c061d88ca35c
URL:
https://github.com/llvm/llvm-project/commit/8d9ddd4f509c54d05a38427d7999c061d88ca35c
DIFF:
https://github.com/llvm/llvm-project/commit/8d9ddd4f509c54d05a38427d7999c061d88ca35c.diff
Author: David Blaikie
Date: 2021-09-23T21:15:01-07:00
New Revision: 165926aa4ce9f05572cf8828210a1af5ce286bdb
URL:
https://github.com/llvm/llvm-project/commit/165926aa4ce9f05572cf8828210a1af5ce286bdb
DIFF:
https://github.com/llvm/llvm-project/commit/165926aa4ce9f05572cf8828210a1af5ce286bdb.diff
Author: David Blaikie
Date: 2021-09-24T11:18:10-07:00
New Revision: 8ec7d9b8f875368a5f92596332cd05059df6bbd2
URL:
https://github.com/llvm/llvm-project/commit/8ec7d9b8f875368a5f92596332cd05059df6bbd2
DIFF:
https://github.com/llvm/llvm-project/commit/8ec7d9b8f875368a5f92596332cd05059df6bbd2.diff
ld be parseable only by llvm-dwarfdump...
> > In which case it seems like it should be a -cc1 option not a
> > driver option.
>
Yep, sounds fair - done that in 8ec7d9b8f875368a5f92596332cd05059df6bbd2
> --paulr
> >
> > > -Original Message-
> > >
Ping on this
On Wed, Sep 15, 2021 at 1:52 PM David Blaikie wrote:
>
>
> On Tue, Sep 14, 2021 at 10:04 AM Richard Smith
> wrote:
>
>> On Mon, 13 Sept 2021 at 19:24, David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>
FWIW, a common way to address this issue is to use the 'unsigned' suffix,
as in:
EXPECT_EQ(x, 5u);
On Thu, Sep 23, 2021 at 4:24 PM Nemanja Ivanovic via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Nemanja Ivanovic
> Date: 2021-09-23T18:24:39-05:00
> New Revision: 76d845cb169f048cb
Author: David Blaikie
Date: 2021-09-28T10:44:35-07:00
New Revision: 85f612efeb352e759f120ee183bf31b1fd7e801a
URL:
https://github.com/llvm/llvm-project/commit/85f612efeb352e759f120ee183bf31b1fd7e801a
DIFF:
https://github.com/llvm/llvm-project/commit/85f612efeb352e759f120ee183bf31b1fd7e801a.diff
Author: David Blaikie
Date: 2021-02-24T16:25:37-08:00
New Revision: 7c926fee930012f9ec19cdaab23b7e154a3845ba
URL:
https://github.com/llvm/llvm-project/commit/7c926fee930012f9ec19cdaab23b7e154a3845ba
DIFF:
https://github.com/llvm/llvm-project/commit/7c926fee930012f9ec19cdaab23b7e154a3845ba.diff
Author: David Blaikie
Date: 2021-06-08T08:25:59-07:00
New Revision: c5d56fec502f36a0c994835ca23bc93a6c682d95
URL:
https://github.com/llvm/llvm-project/commit/c5d56fec502f36a0c994835ca23bc93a6c682d95
DIFF:
https://github.com/llvm/llvm-project/commit/c5d56fec502f36a0c994835ca23bc93a6c682d95.diff
Please include in the commit message a reason for a revert.
On Mon, Aug 16, 2021 at 11:14 AM Kostya Kortchinsky via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Kostya Kortchinsky
> Date: 2021-08-16T11:13:05-07:00
> New Revision: 80ed75e7fb45f9f5fc84ca7cbe258be036015384
>
> URL:
>
Ah, thanks for the details!
On Mon, Aug 16, 2021 at 1:26 PM Kostya Kortchinsky
wrote:
> Apologies.
> As explained in another thread, this was a mistake of mine as I reverted 2
> CLs instead of 1 (mine).
> This was resolved with the original author.
> My own CL ended up breaking some 32-bit build
Perhaps the test case could be stripped down a bit?
template
class Array {};
template
class S {};
template
Array Make();
void Call() {
Array> v = Make>();
}
Seems to exhibit the same issue, by the looks of it.
On Mon, Aug 16, 2021 at 6:38 PM via cfe-commits
wrote:
>
> Author: Weverything
(ping on this)
On Mon, May 10, 2021 at 8:37 AM David Blaikie wrote:
> Christopher - had a chance to look into this any further?
>
> Roman - I'm OK either way on that. I don't think it's the most costly
> false positive - not too much code is probably freeing via a reference
> (rather than a poin
Was this design/code reviewed (there's no mention in the commit message of
a link to a phab review, for instance)? Probably worth some discussion - if
there was a review, could you link it here in a reply?
On Thu, Jun 24, 2021 at 2:23 PM Martin Storsjö via cfe-commits <
cfe-commits@lists.llvm.org>
Ah, found it in https://reviews.llvm.org/D104819 - good to leave that in in
the "Differential Revision: " part of the commit message (or if you end up
splitting patches off from a review, such that it doesn't necessarily make
sense for it to close the review (preparatory patches, etc) then linking
Author: David Blaikie
Date: 2021-06-28T22:57:21-07:00
New Revision: e1b8fde1cbfc031d67d9b316f1b4ac3ab9c8801f
URL:
https://github.com/llvm/llvm-project/commit/e1b8fde1cbfc031d67d9b316f1b4ac3ab9c8801f
DIFF:
https://github.com/llvm/llvm-project/commit/e1b8fde1cbfc031d67d9b316f1b4ac3ab9c8801f.diff
Author: David Blaikie
Date: 2021-06-29T16:39:59-07:00
New Revision: 632e15e766ee625ae367b2e872f3df903e507bfb
URL:
https://github.com/llvm/llvm-project/commit/632e15e766ee625ae367b2e872f3df903e507bfb
DIFF:
https://github.com/llvm/llvm-project/commit/632e15e766ee625ae367b2e872f3df903e507bfb.diff
Author: David Blaikie
Date: 2021-07-06T16:28:02-07:00
New Revision: 6c9559b67b91966bfeff9e17808a3e84a92e64a0
URL:
https://github.com/llvm/llvm-project/commit/6c9559b67b91966bfeff9e17808a3e84a92e64a0
DIFF:
https://github.com/llvm/llvm-project/commit/6c9559b67b91966bfeff9e17808a3e84a92e64a0.diff
Author: David Blaikie
Date: 2021-07-08T13:37:57-07:00
New Revision: 1def2579e10dd84405465f403e8c31acebff0c97
URL:
https://github.com/llvm/llvm-project/commit/1def2579e10dd84405465f403e8c31acebff0c97
DIFF:
https://github.com/llvm/llvm-project/commit/1def2579e10dd84405465f403e8c31acebff0c97.diff
Author: David Blaikie
Date: 2021-07-08T13:37:57-07:00
New Revision: 1def2579e10dd84405465f403e8c31acebff0c97
URL:
https://github.com/llvm/llvm-project/commit/1def2579e10dd84405465f403e8c31acebff0c97
DIFF:
https://github.com/llvm/llvm-project/commit/1def2579e10dd84405465f403e8c31acebff0c97.diff
t;
> -Original Message-
> From: cfe-commits On Behalf Of David
> Blaikie via cfe-commits
> Sent: Tuesday, July 6, 2021 16:28
> To: cfe-commits@lists.llvm.org
> Subject: [clang] 6c9559b - DebugInfo: Mangle K&R declarations for debug
> info linkage names
>
>
> A
Author: David Blaikie
Date: 2021-07-09T12:07:36-07:00
New Revision: 768e3af6345a532d383205049679aaaccca26628
URL:
https://github.com/llvm/llvm-project/commit/768e3af6345a532d383205049679aaaccca26628
DIFF:
https://github.com/llvm/llvm-project/commit/768e3af6345a532d383205049679aaaccca26628.diff
Ping
On Tue, Sep 21, 2021 at 7:58 PM David Blaikie wrote:
> Ping
>
> On Sun, Sep 5, 2021 at 11:28 AM David Blaikie wrote:
>
>> Hey Richard - was just going back over some of the modular codegen code
>> (due to a discussion on the EWG mailing list about file extensions that
>> ended up touching
Author: David Blaikie
Date: 2021-11-01T17:08:26-07:00
New Revision: 8bf12445383b2f3149a9d095bfbc0f6d5b00dfaa
URL:
https://github.com/llvm/llvm-project/commit/8bf12445383b2f3149a9d095bfbc0f6d5b00dfaa
DIFF:
https://github.com/llvm/llvm-project/commit/8bf12445383b2f3149a9d095bfbc0f6d5b00dfaa.diff
Author: David Blaikie
Date: 2021-11-11T21:59:27-08:00
New Revision: 6512098877c3a230bbd38bc81b14a4e5844739ff
URL:
https://github.com/llvm/llvm-project/commit/6512098877c3a230bbd38bc81b14a4e5844739ff
DIFF:
https://github.com/llvm/llvm-project/commit/6512098877c3a230bbd38bc81b14a4e5844739ff.diff
Author: David Blaikie
Date: 2021-03-04T16:20:44-08:00
New Revision: cedc53254a5d2e04e79cc0e7bf5a8c71fafa295e
URL:
https://github.com/llvm/llvm-project/commit/cedc53254a5d2e04e79cc0e7bf5a8c71fafa295e
DIFF:
https://github.com/llvm/llvm-project/commit/cedc53254a5d2e04e79cc0e7bf5a8c71fafa295e.diff
401 - 500 of 1491 matches
Mail list logo
