- User Since
- Dec 4 2013, 1:37 PM (272 w, 6 h)
Thu, Feb 14
Sorry, I didn't mean to accept this yet. I think this is something that is better fixed in Sema.
Sorry, I was misunderstanding the problem.
Wed, Feb 13
I think the root of the problem is that BlockDecl knows the captured variable but doesn't know the type of the capture. The type of the variable and the type of the capture can be different if the block is nested inside a lambda or another block, which is why CI.hasCopyExpr() can return a non-null value when VT is a lvalue reference:
The code is crashing here because the loop in computeBlockInfo is trying to capture a variable that is captured by reference by the enclosing lambda as if it were captured by value. This is the type of VT:
Fri, Feb 8
Improve diagnostic messages.
Thu, Feb 7
Tue, Feb 5
Make sure that volatile trivial fields in a struct don't cause Sema to emit a diagnostic. Simplify the code in Sema::ActOnFields .
This patch is unnecessarily complicated and is not correct.
Mon, Feb 4
Add a note diagnostic to inform the user of the reason for not allowing annotating a class with trivial_abi.
Fri, Feb 1
Add a test case for an anonymous struct nested inside an anonymous union.
Thu, Jan 31
Address review comments.
Tue, Jan 29
LGTM with one minor nit.
Tue, Jan 22
Jan 10 2019
Jan 9 2019
Pass Init by reference and use the rewritten expression returned in it to perform variable initialization. Add a test case that tests new expression with auto types.
Jan 8 2019
We should probably check that alignedAllocMinVersion returns the correct versions for other OSes too, but this patch is fine.
Jan 7 2019
Make deduceVarTypeFromInitializer and DeduceVariableDeclarationType return the new initialization expression and use it in Sema::AddInitializerToDecl. Add a test case that tests lambda capture with an initializer.
We can make DeduceVariableDeclarationType return the rewritten expression and replace Init in Sema::AddInitializerToDecl with it.
Jan 4 2019
I'm not sure whether this is something libc++ (as opposed to the compiler) should handle or not. I just wanted to understand what the expected behavior is first.
It seems like this patch causes clang to accept the following code when compiled with -std=c++11. Is this the expected behavior? Shouldn't the compiler reject the code if it's not compiled with -std=c++17 or newer?
Jan 3 2019
Do not record use of weak variables when the type of an auto variable is being deduced.
Jan 2 2019
Dec 29 2018
Sorry for the delay. The updated patch replaces '@' with '\1' on all targets.
Dec 20 2018
Check whether the declaration passed to Sema::CanUseDecl is an aligned allocation/deallocation function that is unavailable.
Dec 19 2018
Remove the call to CheckPlaceholderExpr in Sema::BuildDecltypeType and move it to Sema::DeduceAutoType. Assert that the expression that is passed to Sema::BuildDecltypeType isn't a placeholder.
Dec 18 2018
Sorry, please ignore my previous comment. I was looking at the wrong place.
Here are a couple of examples I found running the regression tests:
Dec 14 2018
Call CheckPlaceholderExpr instead of pushing an unevaluated evaluation context.
The patch looks largely fine to me.
Dec 13 2018
Just to clarify, this patch doesn't change clang's handling of C++ unions that have non-static data members with non-trivial special member functions.
Dec 10 2018
Dec 9 2018
Dec 4 2018
Dec 3 2018
Nov 30 2018
I've reverted the changes I made to test/SemaCUDA/call-host-fn-from-device.cu since r342749 fixed the overload resolution bug.
Nov 14 2018
Nov 5 2018
Oct 30 2018
Oct 20 2018
Oct 19 2018
Oct 11 2018