This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING: [PATCH: c++/diagnostic/18313] Warn for pointless qualifiers on return type

Dirk Mueller wrote:
> On Sunday, 12. November 2006 22:27, Mark Mitchell wrote:
>> sense for that specific instantiation.  Here, I think we should warn at
>> instantiation-time, since, in the presence of dependent types, we don't
>> what's a class, or what the cv-qualification may be.
> But why would you want to spill out hundreds of warnings from STL container 
> classes to the user just because he decided to use an instantiation with an 
> integral data type?

We generally don't warn about system headers, so STL itself is probably
not a problem.

But, more generally, we don't presently special-case warnings just
because we're in a template instantiation, and maybe some other
instantiations make the code reasonable.  We have a simple rule:
warnings from instantiations should be the same you get if you wrote the
code as a non-template, unless we already warned at the template

For example, compiling:

  template <typename T>
  bool f(T t) {
    return t < 0;

  template bool f(unsigned);

results in a warning because this seems like a weird thing to do *after
instantiation*.  If "f" is "non_negative_p", then the implementation as
written is perfectly sensible, even for unsigned types, and the warning
is spurious.  Then again, maybe the user wasn't supposed to
instantiation this function with an unsigned type, or the implementor of
the template didn't think about that case, and so the warning is useful.
 We don't know.

One can certainly argue that we shouldn't warn in such cases, but it's a
subtle point, and it should be done with thought, and with a commitment
to audit and adjust current warnings so that we behave consistently.
Otherwise, we end up with a mishmash, which is confusing to users and
maintainers alike.  (These are Zack's "incomplete transitions".)

My tentative inclination is that we should warn -- because anything else
is too complicated -- and that users can use fine-grained warning
control to turn off warnings where spurious.

> You're right. I'm testing the following patch now, ok if bootstrapping and 
> regtesting passes?

First, we need to resolve the issue I raised.  Please don't ask to
commit things until consensus has been reached.  It makes it sound like
you're trying to push your code in, rather than get agreement.

As for Andrew's concern, I agree with you that a first step is to get to
behavior similar to that from the C front end.  So, I don't think we
need to resolve the typedef question here.  (However, I do think it
relates a bit to the template issue; in C, with macros as poor-man's
templates, if "T" is some abstract type, unknown to me, than I might
declare a function returning a "const T".  Just as you are proposing we
allow without warning in templates, we could also argue one should not
warn in C, if the function was "instantiated" from a macro.)


> +               if (!IS_AGGR_TYPE (type) && !CLASS_TYPE_P (type))

is not a good expression of what you're trying to check.  CLASS_TYPE_P
things are always IS_AGGR_TYPE, so once you've checked !IS_AGGR_TYPE,
you've already checked !CLASS_TYPE_P.  I think maybe SCALAR_TYPE_P is
what you're looking for?

Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]