Dec 9 2019
I looked at the test failure, the REQUIRES line is necessary because the test calls emit-obj. I've asked Zahira to commit it to fix the bots.
Got other build fails.
Doesn't the LIT test require a:
// REQUIRES: x86-registered-target
Dec 8 2019
LGTM. Could you commit this soon to get the bots green again?
Dec 6 2019
This might be easier to read the edit that I have made:
ksh-3.2$ git diff
diff --git a/clang/test/CodeGen/opt-record-1.c b/clang/test/CodeGen/opt-record-1.c
index 3f37e32..00a753d 100644
@@ -1,12 +1,12 @@
- RUN: %clang_cc1 %s -opt-record-file=t1.opt -fopenmp -emit-llvm-bc -o %t.bc
- RUN: %clang_cc1 -x ir %t.bc -opt-record-file %t.opt -fopenmp -emit-obj
+ RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -target-cpu x86-64 %s -O3 -opt-record-file=t1.opt -fopenmp -emit-llvm-bc -o %t.bc
+ RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -target-cpu x86-64 -O3 -x ir %t.bc -opt-record-file %t.opt -fopenmp -emit-obj
// RUN: cat %t.opt | FileCheck -check-prefix=CHECK %s
If you agree with the edit I will commit the change. Thanks.
Please see the edit in the list test. Fixed the build issue that occurred in the buildbot:
Dec 4 2019
Fixed the indentation. Thanks.
Changed it. Thanks.
Thanks for the review. Please let me know if I have addressed everything.
Nov 29 2019
After an (offline) review from @erichkeane (added now as a reviewer) , stripped the unnecessary code. Thanks.
Nov 26 2019
Nov 25 2019
Oct 14 2019
Aug 8 2019
Agree with all these comments -- I'm no expert on when and when not to std::move, but this is undoing changes I've made to fix buildbots on different compilers.
Aug 5 2019
Jul 3 2019
Thanks for the review.
I think and hope that I have responded to every issue you raised. Let me know if there are still pending issues.
May 30 2019
A review please :-) Thanks.
May 21 2019
And this patch actually fixes the bug. Thanks.
May 20 2019
@rsmith I think I have made all the changes you have pointed out to. But please note that this new patch only impements an explicit AST representation of uuid in template arguments. It does not fix the bug for which this review was opened for.
I will take care of the bug in time. But before doing that I want to make sure that the changes required to give an explicit AST for uuid is correct.
Apr 2 2019
There are still a few things I haven't addressed yet. Mostly because not sure there is another solution like getting rid of the map from StringRef to expr. The other issue is not adding new kind to ParsedAttr. There may be another way of doing it, but didn't look at it yet.
Meanwhile can you please let me know if you are happy with the current status of the implementation.
Mar 19 2019
It would be nice to have a review for this year old (updated) patch. Thanks.
Mar 18 2019
Mar 11 2019
Mar 8 2019
Mar 7 2019
Feb 25 2019
Feb 23 2019
Let's see if I have included every thing mentioned. Thanks.
Feb 20 2019
Feb 14 2019
Feb 13 2019
Feb 12 2019
Feb 11 2019
It looks like the patch got mucked up somehow, I only see three testing files in the patch now?
Feb 8 2019
Can you add tests for C mode as well, as it seems the behavior differs there.
Feb 6 2019
That seems like a reasonable place to try, to me.
Feb 3 2019
I'm still not sure this is the best place to make this change, but the functionality is important. There are still unaddressed comments (no need to check MSVCCompatibility, formatting), and I think once those are fixed we can land this.
Jan 30 2019
Feedback please. Thanks.
Jan 26 2019
Nov 24 2018
Feedback on this please. Thanks.
May 14 2018
May 1 2018
Is this better? Thanks.
Apr 28 2018
Apr 25 2018
This shouldn't be conditional under -fms-compatibility, it's part of dllexport, which is already under -fms-extensions / -fdeclspec-extensions.
I don't think this is the right place to do this. Can it be done as part of processing the dllexport attribute or as part of the main storage class calculation?
Apr 23 2018
Apr 20 2018
Please let me know if I have answered to all the issues you raised. Thanks.
Apr 15 2018
Apr 14 2018
We should really, really avoid making this sort of change without first trying to desugar uuidof into a reference to a variable. That would solve a ton of problems, problems like this one.
Apr 13 2018
Apr 11 2018
Apr 9 2018
Mar 20 2018
Mar 19 2018
This is the LLVM I get. The above test case is failing:
I think this breaks CodeGenCXX/dllimport-base.cpp and devirtualize-ms-dtor.cpp?
Mar 16 2018
LGTM 2. It fixes PR32990.
Mar 9 2018
Mar 8 2018
Attached the test case.
Test case to add.
I believe he's saying you should rebase, since an additional testcase has already been added.
Oops! I thought I had done it already. Sorry. On it.
Can you check the base revision you used to upload the patch? I think there should just be new test case code now.
Mar 2 2018
Hopefully I have responded to the issues you have raised.
I have added the test case you have submitted, to make sure that an expression is generated.
Some of the error messages in the lit test have to be updated (they do match MSVC error messages).
Feb 28 2018
Feb 26 2018
Here's my thinking: the __uuidof expression literally declares a variable called _GUID_ddb47a6a_0f23_11d5_9109_00e0296b75d3 of type __s_GUID which is why it behaves the way it does: https://godbolt.org/g/74FY7U
This is an implementation detail leaking, though. no? Note that that is a reserved name.
I don't think it is reasonable to invent new semantics which are different from the MSVC ones because we find the MSVC ones inelegant.
I mostly agree, but my point is that this is *not* the MSVC semantics, it's merely an implementation detail that non-conforming code happens to be able to observe. Suppose that type_info objects were similarly accessible in MSVC by guessing their mangled names. Would you be arguing that we should inject variables for those too? (And note that it is *nearly* true that type_info objects work that way: https://godbolt.org/g/zByFFg -- but the parser gets confused somehow when you reference them.) The only difference I can see between these cases is that the reserved name used for the GUID case happens to not contain any ?s and @s, so happens to be utterable as an identifier.
We should not attempt to be compatible with the cases where MSVC's implementation details happen to leak into user-visible semantics.
What is the relative upside to a new kind of Decl? Better AST fidelity?
Yes, exactly. The same reason we don't desguar other things any more than we have to.