[Bug c++/113830] New: GCC accepts invalid code when instantiating the local class inside a function

[Bug c++/113830] New: GCC accepts invalid code when instantiating the local class inside a function

[wangbopku15 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

            Bug ID: 113830
           Summary: GCC accepts invalid code when instantiating the local
                    class inside a function
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wangbopku15 at gmail dot com
  Target Milestone: ---

The following invalid code is accepted by both x86-64 gcc-trunk and x86-64
gcc-13.2:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
template<typename T> void f() {
  struct S { void g(int n = T::unknown){}; };
}
template void f<int>();

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The code is invalid because the type name "int" passed in the template function
specialization does not contain the member "unknown":

It appears that if a template function has an internally defined local class
that uses a dependent name in its member function, it can cause the compiler's
name-binding process to get into trouble.

If we compile it via clang-trunk, it rejects the code with the error message:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:2:29: error: type 'int' cannot be used prior to '::' because it has no
members
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please see the godbolt to reproduce it: https://godbolt.org/z/nb3rE8s5a

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-02-08
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Bo Wang from comment #0)
> It appears that if a template function has an internally defined local class
> that uses a dependent name in its member function, it can cause the
> compiler's name-binding process to get into trouble.

Or GCC just doesn't check the default argument because it's not used?

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=66900
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Bug 66900 is somewhat related in that we also allow int::j.

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[wangbopku15 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #3 from Bo Wang <wangbopku15 at gmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Bo Wang from comment #0)
> > It appears that if a template function has an internally defined local class
> > that uses a dependent name in its member function, it can cause the
> > compiler's name-binding process to get into trouble.
> 
> Or GCC just doesn't check the default argument because it's not used?


Please check this one in Godbolt: https://godbolt.org/z/ffj8Pr5n1
It does exist if we use `T::unknow`:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
template<typename T> void f() {
  struct S { void g(int n = T::unknown) noexcept(T::unknown); };
}
template void f<int>();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also, Clang could reject it.

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[wangbopku15 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #4 from Bo Wang <wangbopku15 at gmail dot com> ---
(In reply to Marek Polacek from comment #2)
> Bug 66900 is somewhat related in that we also allow int::j.

I believe these two bugs have different root causes. Bug 113830 should be due
to not instantiating default arguments inside the template function, especially
in instantiating a local class. While Bug 66900 does not have this issue.

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Probably we just don't instantiate g because nothing needs it.
With
template<typename T> void f() {
  struct S { void g(int n = T::unknown){}; };
  S s;
  s.g();
}
template void f<int>();
we error:
pr113830.C: In instantiation of ‘void f() [with T = int]’:
pr113830.C:6:22:   required from here
    6 | template void f<int>();
      |                      ^
pr113830.C:2:32: error: ‘unknown’ is not a member of ‘int’
    2 |   struct S { void g(int n = T::unknown){}; };
      |                                ^~~~~~~
pr113830.C:4:6: note:   when instantiating default argument for call to ‘void
f()::S::g(int) [with T = int]’
    4 |   s.g();
      |   ~~~^~
but when one uses s.g(0); instead of s.g(); we accept it as well.

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Bo Wang from comment #4)
> (In reply to Marek Polacek from comment #2)
> > Bug 66900 is somewhat related in that we also allow int::j.
> 
> I believe these two bugs have different root causes. Bug 113830 should be
> due to not instantiating default arguments inside the template function,
> especially in instantiating a local class. While Bug 66900 does not have
> this issue.

Yes, I'm saying they are related, not dups.

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[wangbopku15 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #7 from Bo Wang <wangbopku15 at gmail dot com> ---
(In reply to Jakub Jelinek from comment #5)
> Probably we just don't instantiate g because nothing needs it.
> With
> template<typename T> void f() {
>   struct S { void g(int n = T::unknown){}; };
>   S s;
>   s.g();
> }
> template void f<int>();
> we error:
> pr113830.C: In instantiation of ‘void f() [with T = int]’:
> pr113830.C:6:22:   required from here
>     6 | template void f<int>();
>       |                      ^
> pr113830.C:2:32: error: ‘unknown’ is not a member of ‘int’
>     2 |   struct S { void g(int n = T::unknown){}; };
>       |                                ^~~~~~~
> pr113830.C:4:6: note:   when instantiating default argument for call to
> ‘void f()::S::g(int) [with T = int]’
>     4 |   s.g();
>       |   ~~~^~
> but when one uses s.g(0); instead of s.g(); we accept it as well.

As mentioned in Comment 3, the following does not appear to be valid code, but
it still compiles. This is unrelated to whether or not the argument is used.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
template<typename T> void f() {
  struct S { void g(int n = T::unknown) noexcept(T::unknown); };
}
template void f<int>();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The point is that the standard does not require a diagnostic for all invalid
code. If the rule in the standard is specified as "ill-formed, no diagnostic
required" then implementations are allowed to ignore it. For example, because
the T::unknown only appears in an unused default argument, or an unused
noexcept-specifier.

In other words "clang gives an error" does not mean "gcc MUST give an error".

But it would be nice if we did give an error, even if it's not required.

Either way, I don't think this has anything to do with the "compiler's
name-binding process". We just don't care that T::unknown is invalid if we
don't use it.

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[wangbopku15 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #9 from Bo Wang <wangbopku15 at gmail dot com> ---
I have tried another case that has no default arguments. This one also be
accepted. We can find that `T::unknown` is used without type-check.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
template<typename T> void f() {
    struct S {  void g() noexcept(T::unknown); };
}
template void f<int>();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Godbolt link is here: https://godbolt.org/z/qY6bajaWE

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But again, T::unknown isn't used except in a template which is not
instantiated.
It can't be checked during parsing because T::unknown is dependent and could
very well be well formed if it was instantiated with a different template
argument.
So, does the standard require that all methods of local classes are
instantiated when the containing function template is instantiate (of course,
that can't be the case for methods which are templates on their own)?

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[wangbopku15 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #11 from Bo Wang <wangbopku15 at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> But again, T::unknown isn't used except in a template which is not
> instantiated.
> It can't be checked during parsing because T::unknown is dependent and could
> very well be well formed if it was instantiated with a different template
> argument.
> So, does the standard require that all methods of local classes are
> instantiated when the containing function template is instantiate (of
> course, that can't be the case for methods which are templates on their own)?

Thank you for pointing out the critical point.

I have read the working draft standard of C++20
(https://github.com/cplusplus/draft/tree/c%2B%2B20).

Following the subsection "13.9.2 Explicit instantiation" in the section "13.9
Template instantiation and specialization", the statement `template void
f<int>();` is an explicit instantiation, which requires instantiating
everything in the function.

So we don't need another explicit function call to instantiate it.

If my understanding of the standard is correct, the compiler indeed should
instantiate and reject this code.

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #12 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Bo Wang from comment #11)
> I have read the working draft standard of C++20
> (https://github.com/cplusplus/draft/tree/c%2B%2B20).
> 
> Following the subsection "13.9.2 Explicit instantiation" in the section
> "13.9 Template instantiation and specialization", the statement `template
> void f<int>();` is an explicit instantiation, which requires instantiating
> everything in the function.

Where are you getting "everything in the function" from? It seems to say rather
the opposite in [temp.explicit]p14:

> An explicit instantiation does not constitute a use of a default argument, so default argument instantiation is not done.

Now, the example shows that this was intended to apply to default arguments of
the function itself, but the actual wording does not limit it to that, so I
actually think this is a bug in clang, by the current wording this must be
accepted?

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[wangbopku15 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #13 from Bo Wang <wangbopku15 at gmail dot com> ---
(In reply to Harald van Dijk from comment #12)
> (In reply to Bo Wang from comment #11)
> > I have read the working draft standard of C++20
> > (https://github.com/cplusplus/draft/tree/c%2B%2B20).
> > 
> > Following the subsection "13.9.2 Explicit instantiation" in the section
> > "13.9 Template instantiation and specialization", the statement `template
> > void f<int>();` is an explicit instantiation, which requires instantiating
> > everything in the function.
> 
> Where are you getting "everything in the function" from? It seems to say
> rather the opposite in [temp.explicit]p14:
> 
> > An explicit instantiation does not constitute a use of a default argument, so default argument instantiation is not done.
> 
> Now, the example shows that this was intended to apply to default arguments
> of the function itself, but the actual wording does not limit it to that, so
> I actually think this is a bug in clang, by the current wording this must be
> accepted?

Please refer to the example in Comment 9 which has no default arguments.

For the standard, I found this one in "13.9 Template instantiation and
specialization" p6 of C++20, which requires access checking.

> The usual access checking rules do not apply to names in a declaration of an 
> explicit instantiation or explicit specialization, with the exception of names 
> appearing in a function body, default argument, base-clause, member-
> specification, enumerator-list, or static data member or variable template 
> initializer. [Note: In particular, the template arguments and names used in the 
> function declarator zincluding parameter types, return types and exception 
> specifications) may be private types or objects that would normally not be
> accessible. —end note]

Also, I don't think Clang rejecting these codes is buggy.

[Bug c++/113830] GCC accepts invalid code when instantiating the local class inside a function

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830

--- Comment #14 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Bo Wang from comment #13)
> (In reply to Harald van Dijk from comment #12)
> > (In reply to Bo Wang from comment #11)
> > > I have read the working draft standard of C++20
> > > (https://github.com/cplusplus/draft/tree/c%2B%2B20).
> > > 
> > > Following the subsection "13.9.2 Explicit instantiation" in the section
> > > "13.9 Template instantiation and specialization", the statement `template
> > > void f<int>();` is an explicit instantiation, which requires instantiating
> > > everything in the function.
> > 
> > Where are you getting "everything in the function" from? It seems to say
> > rather the opposite in [temp.explicit]p14:
> > 
> > > An explicit instantiation does not constitute a use of a default argument, so default argument instantiation is not done.
> > 
> > Now, the example shows that this was intended to apply to default arguments
> > of the function itself, but the actual wording does not limit it to that, so
> > I actually think this is a bug in clang, by the current wording this must be
> > accepted?
> 
> Please refer to the example in Comment 9 which has no default arguments.

Okay, sure, but if we have established that the standard does not say
"everything in the function" needs to be instantiated, where does it say that
*this* needs to be instantiated?

> For the standard, I found this one in "13.9 Template instantiation and
> specialization" p6 of C++20, which requires access checking.

That explains that the special exception that generally applies to template
instantiations does not apply here. This means the usual rules apply, so for
instance, you can't refer to a private member of a class unless you're a
friend. But for templates, these usual rules apply upon instantiation, so we
still need to establish whether or not this is required to be instantiated.