Joe Buck wrote: > Mark Mitchell wrote: >>> I don't see any a priori problem with changing to match the C front end. >>> We could of course change some of the pedwarns into errors if we really >>> think they ought to be errors. Or, some of them could be ordinary >>> warnings when not -pedantic, and pedwarns when -pedantic.
>> Sounds like we want a separate category of diagnostic with the current >> C++ pedwarn semantics so that we can change pedwarns themselves back to >> a warning by default. > > Agreed. Some have argued that the change makes sense because of > consistency arguments. I'm not impressed with that; the compiler > is designed to be used, so the question is what most serves the users. Exactly so. I think that we have two kinds of pedwarns: those that are pedantic in the sense we use for C (like, that there cannot be a naked semicolon at the top-level of a file, or that "long long" is not in C++98) and those that refer to semantically reasonable constructs that we previously accepted, often because they were allowed by cfront or the ARM. With flag_permissive, we probably want the latter category to be warnings at most; without flag_permissive, we want them to be errors. This is a conceptually simple project, but it will take some work to implement it, because someone will have to look at every pedwarn and decide which category they are in. Any volunteers? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
