[Bug c++/49399] New: [C++0x] substitution failure error

[Bug c++/49399] New: [C++0x] substitution failure error

[jarrydb at cse dot unsw.edu.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

           Summary: [C++0x] substitution failure error
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jarrydb@cse.unsw.edu.au


Created attachment 24515
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24515
substitution failure

When accessing a private member of a class in a substitution failure is not an
error sort of way, the compiler reports an error.

Compiling the attached code gives the following:

g++ --std=c++0x value_type.cpp
value_type.cpp: In function ‘int broken_fun(int, typename T::value_type*) [with
T = broken, typename T::value_type = int]’:
value_type.cpp:4:15: error: ‘typedef int broken::value_type’ is private
value_type.cpp:14:37: error: within this context

It works fine without c++0x mode, and on previous versions of gcc.

output of gcc -v

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/jarryd/local/gcc-4.7/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/jarryd/installers/gcc-svn/configure
--prefix=/home/jarryd/local/gcc-4.7 --disable-multilib
--enable-languages=c,c++,go
Thread model: posix
gcc version 4.7.0 20110614 (experimental) (GCC)

[Bug c++/49399] [C++0x] substitution failure error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-14 08:15:14 UTC ---
when you say "works fine" do you mean "doesn't do the access check"?
surely if SFINAE correctly honours access control then the function shouldn't
be callable and the program won't compile

[Bug c++/49399] [C++0x] substitution failure error

[jarrydb at cse dot unsw.edu.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #2 from Jarryd Beck <jarrydb at cse dot unsw.edu.au> 2011-06-14 11:52:58 UTC ---
By works fine I mean that the code compiles, and when it runs, the program
returns the number 4.

Maybe I'm misunderstanding how this is all supposed to work and something has
changed in the spec meaning that this is now broken. However that would mean
boost is broken too (quite possible).

It comes from BOOST_MPL_HAS_XXX_TRAIT_DEF. They use it to work out if a class
has a particular member defined. It has been working fine up until recently
when it broke with C++0x.

[Bug c++/49399] [C++0x] substitution failure error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-14 12:11:05 UTC ---
The program should not compile.

In C++03 it should fail to compile because it accesses a private member. SFINAE
does not take access control into account in C++03, so that is an error.  G++
fails to reject the program because access checking in templates is buggy.

There was a last minute change in the C++0x FDIS to make SFINAE consider access
control. The previous draft
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf) says in
section 14.8.2 [temp.deduct] p8 "Access checking is not done as part of the
substitution process. Consequently, when deduction succeeds, an access error
could still result when the function is instantiated."
That was changed in the FDIS, so accessing the private member should cause
deduction to fail, so there is no broken_fun and the call to it in main should
fail.  G++ 4.7 doesn't implement that change yet, so rejects the program for
the wrong reason.

If you had a second, less specific, overload of broken_fun then the program
would still be invalid in C++03 but should be well-formed in C++0x. G++ doesn't
accept it because access checking is not done as part of the substitution
process yet.

e.g. this is valid C++0x

struct broken
{
  private:
  typedef int value_type;
};

template <typename T>
int
broken_fun(int, typename T::value_type* = 0);

template <typename T>
char
broken_fun(...);

int main(int argc, char* argv[])
{

  return sizeof(broken_fun<broken>(5));
}

[Bug c++/49399] [C++0x] substitution failure error

[jarrydb at cse dot unsw.edu.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #4 from Jarryd Beck <jarrydb at cse dot unsw.edu.au> 2011-06-14 12:21:15 UTC ---
(In reply to comment #3)
> The program should not compile.
> 
> In C++03 it should fail to compile because it accesses a private member. SFINAE
> does not take access control into account in C++03, so that is an error.  G++
> fails to reject the program because access checking in templates is buggy.
> 
> There was a last minute change in the C++0x FDIS to make SFINAE consider access
> control. The previous draft
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf) says in
> section 14.8.2 [temp.deduct] p8 "Access checking is not done as part of the
> substitution process. Consequently, when deduction succeeds, an access error
> could still result when the function is instantiated."
> That was changed in the FDIS, so accessing the private member should cause
> deduction to fail, so there is no broken_fun and the call to it in main should
> fail.  G++ 4.7 doesn't implement that change yet, so rejects the program for
> the wrong reason.
> 
> If you had a second, less specific, overload of broken_fun then the program
> would still be invalid in C++03 but should be well-formed in C++0x. G++ doesn't
> accept it because access checking is not done as part of the substitution
> process yet.
> 
> e.g. this is valid C++0x
> 
> struct broken
> {
>   private:
>   typedef int value_type;
> };
> 
> template <typename T>
> int
> broken_fun(int, typename T::value_type* = 0);
> 
> template <typename T>
> char
> broken_fun(...);
> 
> int main(int argc, char* argv[])
> {
> 
>   return sizeof(broken_fun<broken>(5));
> }

Ah, I see. Well the example you gave also doesn't compile. This is exactly what
the boost library does too, I missed that part in their code, meaning that
parts of boost no longer compile with gcc 4.7.

[Bug c++/49399] [C++0x] substitution failure error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-14 12:27:35 UTC ---
Then they never should have compiled in the first place, and won't compile with
clang or Comeau either.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1170 is the
relevant DR

[Bug c++/49399] [C++0x] substitution failure error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-14 12:30:06 UTC ---
(In reply to comment #4)
> Ah, I see. Well the example you gave also doesn't compile. This is exactly what
> the boost library does too, I missed that part in their code, meaning that
> parts of boost no longer compile with gcc 4.7.

And I know it doesn't, as I said "G++ doesn't accept it because access checking
is not done as part of the substitution process yet."

Even when that's done, it will only be valid C++0x not, C++03.

[Bug c++/49399] [C++0x] substitution failure error

[jarrydb at cse dot unsw.edu.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #7 from Jarryd Beck <jarrydb at cse dot unsw.edu.au> 2011-06-14 12:34:35 UTC ---
(In reply to comment #6)
> (In reply to comment #4)
> > Ah, I see. Well the example you gave also doesn't compile. This is exactly what
> > the boost library does too, I missed that part in their code, meaning that
> > parts of boost no longer compile with gcc 4.7.
> 
> And I know it doesn't, as I said "G++ doesn't accept it because access checking
> is not done as part of the substitution process yet."
> 
> Even when that's done, it will only be valid C++0x not, C++03.

Ok, I thought that was what you meant. Does this however mean that this bug is
now valid for C++0x, given what they say in the link that you gave?

"If a substitution results in an invalid type or expression, type deduction
fails. An invalid type or expression is one that would be ill-formed if written
using the substituted arguments. [Note: Access checking is not done as part of
the substitution process. —end note]"

Should a bug for the reverse also be filed for the C++03 part of gcc? I wonder
what boost mpl people would say about a bug report since this actually works
even though it's wrong...

[Bug c++/49399] [C++0x] substitution failure error

[jarrydb at cse dot unsw.edu.au]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #8 from Jarryd Beck <jarrydb at cse dot unsw.edu.au> 2011-06-14 12:35:31 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > Ah, I see. Well the example you gave also doesn't compile. This is exactly what
> > > the boost library does too, I missed that part in their code, meaning that
> > > parts of boost no longer compile with gcc 4.7.
> > 
> > And I know it doesn't, as I said "G++ doesn't accept it because access checking
> > is not done as part of the substitution process yet."
> > 
> > Even when that's done, it will only be valid C++0x not, C++03.
> 
> Ok, I thought that was what you meant. Does this however mean that this bug is
> now valid for C++0x, given what they say in the link that you gave?
> 
> "If a substitution results in an invalid type or expression, type deduction
> fails. An invalid type or expression is one that would be ill-formed if written
> using the substituted arguments. [Note: Access checking is not done as part of
> the substitution process. —end note]"
> 
> Should a bug for the reverse also be filed for the C++03 part of gcc? I wonder
> what boost mpl people would say about a bug report since this actually works
> even though it's wrong...

Sorry that should be access checking is done. This text entry didn't preserve
the strike through of the not.

[Bug c++/49399] [C++0x] substitution failure error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-14 12:40:52 UTC ---
Note that returning 4 was *never* correct for that program.  In C++03 it
shouldn't compile and in C++0x it should return 1.  There's a bug in the
Boost.MPL docs which should say the macro works for *public* nested type member
x::name and cannot be used if the name is not accessible (and if you report
that you might as well also report the docs keep saying "memeber")

There are already several bug reports for G++ not doing access checking
correctly in templates, no need to report another one.  You could consider it a
bug that the resolution of DR1170 isn't implemented yet, but it's a known
missing feature that simply hasn't been implemented yet.

[Bug c++/49399] [C++0x] substitution failure error

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49399

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jason at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> 2011-06-15 16:47:02 UTC ---
Closing.  Feel free to open a bug report requesting implementation of DR 1170.