rjmccall added a comment. In https://reviews.llvm.org/D49508#1168599, @lebedev.ri wrote:
> In https://reviews.llvm.org/D49508#1168584, @rjmccall wrote: > > > Hmm. I think the approach of flagging ICEs that are semantically part of > > an explicit cast is probably a better representation for tools across the > > board. > > > I could do that, but i couldn't find where it should be done. > Where are these "ICEs that are semantically part of an explicit cast" > created? The design of `CastExpr` is that each node does exactly one implicit conversion step, but sometimes a conversion involves performing multiple steps which each has to get its own node, so all those initial conversions have to be represented as ICEs. Also, while we do make some effort to give the explicit cast node a meaningful `CastKind`, in some situations it's just easier to build an ICE with the real CK and then just make the explicit cast a `NoOp`. All those ICEs are triggered by the checking of the explicit cast and therefore semantically part of that operation even if they're separate nodes for technical reasons. > Where would we mark them? Well, explicit casts are handled by SemaCast.cpp, and all the checking routines are managed by a `CastOperation` helper class. In fact, it's set up so that you could very easily (1) stash the original expression in the `CastOperation` construct and then (2) in `complete()`, just walk from the given cast up to the original expression and mark every ICE you see as being part of the explicit cast. >> If we *are* going to do it this way, though, I think you should (1) make the >> collection of skipped expressions optional and (2) collect *all* the skipped >> expressions, not just no-op casts. > > 1. I was wondering about that, will do. > 2. Well, i could do that, but i would need to filter them afterwards in my > use-case. Well, you're filtering them anyway, right? You're scanning the list for explicit casts. > So i wonder - what is the motivation for that? > Nothing else needs that additional knowledge right now. It has a much more obvious specification and it's not hard to imagine clients that would want to scan that list for other things. (In fact, the comma-expressions list could pretty easily be combined into that.) Repository: rC Clang https://reviews.llvm.org/D49508 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
