On Oct 5, 2010, at 5:19 PM, John McCall wrote: > > On Oct 5, 2010, at 5:03 PM, jahanian wrote: > >> >> On Oct 5, 2010, at 4:52 PM, John McCall wrote: >> >>> On Oct 5, 2010, at 4:24 PM, Fariborz Jahanian wrote: >>>> Author: fjahanian >>>> Date: Tue Oct 5 18:24:00 2010 >>>> New Revision: 115713 >>>> >>>> URL: http://llvm.org/viewvc/llvm-project?rev=115713&view=rev >>>> Log: >>>> Issue deprecated warning when typeof uses an >>>> expression of deprecated type. >>> >>> This seems strange to me; deprecation warnings are usually based on how >>> something is spelled, not what it actually resolves to. For example, even >>> if a record type is deprecated, you can still make variables of that type >>> if you have a non-deprecated typedef for it. So if the variable itself >>> isn't deprecated, I'm not sure why getting its type with typeof is more >>> suspect than any other use. Is there a specific use case motivating this? >> >> typeof is a gcc extension and I followed gcc's behavior. I guess it is >> because typeof is really a replacement for using >> the deprecated type directly. But I don't know more than that. > > Okay. > >>> There are a lot of subsidiary questions here, like whether we should warn >>> in the following test cases: >>> deprecated_type *a; typeof(*a) b; // we now warn about this >>> deprecated_type *a; typeof(a) b; // but not about this >>> deprecated_typedef a; typeof(a) b; // or this >> >> gcc issues warnings on these but not for this, for example: >> >>> deprecated_type a[10]; typeof (a) b; > > Actually, as far as I can tell you've implemented the exact condition that > gcc uses: it warns if the expression has a deprecated record or enum type, > discarding typedefs and not looking through pointers/arrays/whatever. > >> So, I would say gcc's behavior is not consistent (I have access to 4.2 only >> though). >> But, I think we should warn in all cases (if we do for typeof ). > > I agree that if we want to warn here, we should at least warn about > deprecated typedefs. But my preference would be to not warn here at all.
Agreed. Actually, gcc does that too (please see my followup email). - Fariborz > > John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
