- User Since
- Jan 18 2013, 11:30 AM (286 w, 5 d)
I think it would be reasonable to set a flag on ImplicitCastExprs that are actually semantically part of an explicit cast. I don't think that would be hard to get Sema to do, either by passing a flag down to the code that builds those casts or just by retroactively setting that flag on all the ICE sub-expressions of an explicit cast when "capping" it with the ExplicitCastExpr.
Thanks for the comment.
Tue, Jul 17
Hmm. I think this is a reasonable change to make to the language. Have you investigated to see if this causes source-compatibility problems?
Please test that we still copy captures correctly into the block object and destroy them when the block object is destroyed.
This is the right basic approach. I think it would be better if the diagnostic text was more like err_function_template_spec_no_match, maybe "no candidate function template was found for dependent friend function template specialization". And it would be good to emit notes on any declarations we found but discarded.
Can you explain why this is important for the optimizer?
Sat, Jul 7
Tue, Jul 3
Thanks, much appreciated. A couple more style changes that I noticed and this will be LGTM, although you should also make sure you have Bevin Hansson's approval.
LGTM, but I'd like Richard to sign off, too.
Mon, Jul 2
Thu, Jun 28
This all looks reasonable except that I think the interpretation is exactly backwards, no? From the documentation on the option, -fpadding-on-unsigned-fixed-point causes there to be padding, i.e. the inverse of the old SameFBits; but the default value, comments, and boolean checks throughout the code are all still using the old interpretation.
Wed, Jun 27
Tue, Jun 26
Sun, Jun 24
Fri, Jun 22
Thu, Jun 21
Basic approach seems reasonable to me.
Wed, Jun 20
Functionally seems fine to me.
Jun 18 2018
In general, it's unfortunate that this has to leave so many C++-runtime-specific tendrils in the ObjC code. Unlike the EH type patch, though, I'm not sure I can see a great alternative here, especially because of the semantic restrictions required by outlining.
Jun 15 2018
Jun 11 2018
The non-fragile Objective-C path — i.e. interoperation with C++ exceptions instead of using setjmp/longjmp in an utterly-incompatible style — is absolutely the right direction going forward.
Thanks, comment change looks good. LGTM.
Jun 9 2018
Okay, as a code change this seems more reasonable to me. I haven't really thought through the ABI-compatibility issues, though. CC'ing Tim.
Jun 4 2018
Oh, I see, because you're worried that the host code might contain dynamic_cast or similar features which would complain if RTTI were disabled.
Okay, We can try this, then.
Well, Sema should always be diagnosing conflicts.
Jun 3 2018
Why not just have the driver disable RTTI in the frontend invocation?
Jun 1 2018
Landed as r333791.
I'm not sure it's appropriate to impose this as an overhead on all targets.
Is there a specific reason to change the implementation instead of changing the documentation?
May 31 2018
That's an interesting idea. I don't see any particular reason not to do it this way if you're willing to accept that it's never going to support the full control-flow possibilities of @finally. You will need to add JumpDiagnostics logic to prevent branches out of the block, and I don't know how this will interact with attempts to throw an exception out.
May 24 2018
May 23 2018
May 22 2018
There are at least three good reasons to make sure this can enabled/disabled by a flag:
- We have to anticipate that introducing new keywords will cause some compatibility problems. New language standards that introduce new keywords can be disabled using -std=<something earlier>. We shouldn't let this bypass that just because it's an out-of-band addition to the base language.
- It seems likely to me that this feature will be target-restricted.
- It seems plausible to me that development of this feature might continue past the Clang 7 branch date, and we shouldn't release a compiler with significantly-incomplete features on by default.
The changes to Clang generally seem reasonable, but I think you should split them into a separate commit from the commit that adds the intrinsic itself.
CC: Argyrios for the USR question.
I thought we already had places in Sema that marked inline virtual methods as used, instantiated templates, etc. for devirtualization purposes when optimization was enabled. Did we rip that out?
I like this approach a lot.
May 21 2018
This was approved by the Objective-C language group as a default-off warning.
May 20 2018
Thanks, my comments seem to all be addressed.
May 19 2018
May 18 2018
Maybe there should just be a method that makes a primitive alloca without the casting, and then you can call that in CreateTempAlloca.
Test case should go in test/CodeGenCXX. Also, there already is a blocks.cpp there.
RecursiveASTVisitor instantiations are huge. Can you just make the function take a Stmt and then do the first few checks if it happens to be an Expr?
Incomplete classes are a curse. I don't suppose we can just modify the language specification to make it illegal to use typeid(Incomplete*)? Or make equality/hashing undefined in these cases?
This isn't really an Objective-C user forum, but I'll try to summarize briefly. unsafe_unretained is an unsafe version of weak — it's unsafe because it can be left dangling if the object is deallocated. It's necessary for a small (and getting smaller every year) set of classes that don't support true weak references, and it can be useful as an optimization to avoid the performance overhead of reference counting.
It's waiting on a discussion that's happening pretty slowly, sorry. I know this is frustrating.
May 17 2018
Well, internal and external types are important cases. I'm fine with this. It's a pity that we can't express what we want with aliases, though.
I agree that the new-expression case doesn't use the destructor, and all the other cases of list-initialization presumably use the destructor for the initialized type for separate reasons. Ok.