lebedev.ri added a comment. In https://reviews.llvm.org/D49508#1168620, @rjmccall wrote:
> 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. Hmm, thank you for these pointers. I agree that it would be *nicer*. Let's see.. >>> 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. I meant filter the list to only contain skipped casts, before actually scanning it for specific conditions. >> 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
