On Feb 23, 2012, at 6:42 PM, David Blaikie wrote: > Sorry, I'll provide some more context - AnalyzeImplicitConversions > itself does "IgnoreParensImpCasts" as its first thing - but not before > recording the QualType of the outer Expr (lines 4202, 4203). Many of > the diagnostics work simply by comparing the type of the outer > expression with the type of the inner one - thus they fired /all/ if > you didn't have that IgnoreParensImpCasts before the > AnalyzeImplicitConversions call - because they looked just like > implicit conversions (they /were/ in the AST). Now that explicit > conversions aren't implemented as implicit ones this problem doesn't > exist. > > In fact when I made this change I was hoping there were cases where an > explicit conversion could contain an implicit one as you showed - but > further, that such cases might have real warnings. Turned out removing > that outer IgnoreParensImpCasts didn't cause any clang tests to change > at all... nice, even if it didn't allow us to catch new cases. > > In any case I suspect it's the right thing - there's no reason for us > to be ignoring those implicit conversions except that we were doing it > to support our not-so-great AST representation of explicit > conversions.
There are a few situations where we implement a cast with multiple implicit conversions. One example would be something like (_Complex float) 0 which is an IntegralToFloating conversion followed by a FloatingRealToComplex. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
