abduld / include-what-you-use

Automatically exported from code.google.com/p/include-what-you-use
Other
0 stars 0 forks source link

iwyu suggests too much to add (inherited += operator) #111

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
    // an example:
    // main.cc
    #include "mystring.hh"

    int main()
    {
        mystring s;
        s += "hello"; // triggers spurious include
        return 0;
    }
    //mystring.hh
    #include <string>
    struct mystring : public std::basic_string<char> {};

due to '+=' usage iwyu wrongly suggests pulling '#include <string>'

While this one does not trigger warning:

    // main.cc
    #include "mystring.hh"

    int main()
    {
        mystring s;
        //s += "hello"; // triggers spurious include
        return 0;
    }

Thanks!

Original issue reported on code.google.com by slyich on 18 Sep 2013 at 3:13

GoogleCodeExporter commented 9 years ago
Thanks for the minimal test case!

I think this exposes a weakness in IWYU's reasoning (much like issue 105) 
around author intent (see 
https://code.google.com/p/include-what-you-use/wiki/WhatIsAUse#Author_Intent).

In this case, mystring is equivalent to a typedef of std::basic_string<char>, 
and so mystring.hh should re-export <string>.

I think this is handled rather stepmotherly at the moment, and that maybe there 
should be a more explicit way for IWYU to mark an #include as re-exported 
implicitly due to author intent.

Let me see if I can materialize those thoughts...

Original comment by kim.gras...@gmail.com on 18 Sep 2013 at 6:54

GoogleCodeExporter commented 9 years ago
An example which seems closely related. It seems even simpler, in that sense 
that it is just a typedef and no inheritance. Requires -std=c++11.
//sharedptr_test.cc
#include "myptr.h"
int main() {
    myptr p;
    *p; //no error without this line
}
//myptr.h
#include <memory>
typedef std::shared_ptr<char> myptr;     

Original comment by rol...@rschulz.eu on 28 May 2014 at 6:09

GoogleCodeExporter commented 9 years ago
Actually my example doesn't seem to be caused by "*p" using an overloaded 
operator. Other overloaded operators (e.g. !p) are OK. The problem seems to be 
with the return type. Even though it simply evaluates to "char" the template 
expression seems to be confusing IWYU.

Original comment by rol...@rschulz.eu on 28 May 2014 at 7:51

GoogleCodeExporter commented 9 years ago
My example still shows an error with IWYU@HEAD and with libc++. Should I move 
my example to a separate issue?

Original comment by rol...@rschulz.eu on 29 May 2014 at 2:56

GoogleCodeExporter commented 9 years ago
I completely missed your first comment #2 on this, I didn't see an e-mail 
coming out.

Thanks for the additional example, I think this is a separate problem, so it 
would be nice if you could add a new issue for it. I think we can link that 
with #135, because I think they are subtly related in implementation details.

Original comment by kim.gras...@gmail.com on 29 May 2014 at 8:37