[Bug c++/104111] New: Concept evaluation depends on context where it was first checked

[Bug c++/104111] New: Concept evaluation depends on context where it was first checked

[fchelnokov at gmail dot com]

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

            Bug ID: 104111
           Summary: Concept evaluation depends on context where it was
                    first checked
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

Please consider a concept and a class definitions:
```
template<class T>
concept has_private = requires(){ &T::private_;};

class B{
   int private_;
   friend class A;
};
```

If we first check the concept inside `A` then it will be always evaluated to
true:
```
class A{
   static_assert( has_private<B> );
};
static_assert( has_private<B> );
```
Demo: https://godbolt.org/z/eYP6Tq7Y7

But if we first check the concept outside `A` then it will be always evaluated
to false:
```
static_assert( !has_private<B> );
class A{
   static_assert( !has_private<B> );
};

```
Demo: https://godbolt.org/z/vsTx4oTaE

Clang has the same behavior. At the same time MSVC always evaluates the concept
to false, and it looks correct, because context evaluation shall not depend on
the context.

Related discussion: https://godbolt.org/z/vsTx4oTaE

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[fchelnokov at gmail dot com]

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

--- Comment #1 from Fedor Chelnokov <fchelnokov at gmail dot com> ---
Sorry, related discussion: https://stackoverflow.com/q/53263299/7325599

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-01-19
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Target Milestone|---                         |11.3
                 CC|                            |ppalka at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

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

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
> because concept-id evaluation shall not depend on the context.

One consequence of making this change to concept-id evaluation would be that
for:

  template<class T> void f() requires (!C<T>);

during constraint checking for say f<int>(), we no longer evaluate C<int> (as
part of evaluation of the atomic constraint !C<T>) in the access context of f,
which seems surprising to me.

CC'ing Jason for guidance.

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |67491

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #3)
> > because concept-id evaluation shall not depend on the context.
> 
> One consequence of making this change to concept-id evaluation would be that
> for:
> 
>   template<class T> void f() requires (!C<T>);
> 
> during constraint checking for say f<int>(), we no longer evaluate C<int>
> (as part of evaluation of the atomic constraint !C<T>) in the access context
> of f, which seems surprising to me.
> 
> CC'ing Jason for guidance.

This issue was discussed on the CWG mailing list back in 2018, but seems never
to have made it to the issues list.  There was general agreement at the time
that access should be checked in the lexical context of the atomic constraint,
as with other expressions; this does indeed have the consequence that you
mention.  Which means that since we don't have class-scope concepts, any
constraints that need to depend on access control need to be written directly
in the requires-clause rather than through a concept.  Or just give up on
trying to express constraints that depend on access.

An alternative fix for this bug would be to include the evaluation context in
the satisfaction cache.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #5)
> An alternative fix for this bug would be to include the evaluation context
> in the satisfaction cache.

...if the evaluation involved access checking of a private or protected member.

[Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked

[jason at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Concept evaluation depends  |[DR2589] Concept evaluation
                   |on context where it was     |depends on context where it
                   |first checked               |was first checked

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
https://cplusplus.github.io/CWG/issues/2589.html

[Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.

[Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked

[steve+gcc at tecwec dot eu]

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

Eric Estievenart <steve+gcc at tecwec dot eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steve+gcc at tecwec dot eu

--- Comment #9 from Eric Estievenart <steve+gcc at tecwec dot eu> ---
By the way, the following code exhibits another related weirdness, without
access control being involved:
```
#include <concepts>
struct Op
{
        void operator()( auto x ) const = delete; // want only explicit
customization in scope
};

struct S {};
static_assert( !std::invocable<Op, S> );
template<> void Op::operator()( S ) const {}  // now Op is invocable on S
static_assert( std::invocable<Op, S> );       // so should not fail ! but...
```
(https://godbolt.org/z/Wa6rxeMvP)

Commenting the first assert makes the second suddenly pass...

Quantum physicist would say "spooky action at a distance" ;-)
Hope this helps,
Best.

[Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked

[webrown.cpp at gmail dot com]

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

--- Comment #10 from W E Brown <webrown.cpp at gmail dot com> ---
(In reply to Eric Estievenart from comment #9)

Sorry, but I find neither "weirdness" nor "spooky"-ness in the comment #9 code
as shown.  Rather, I believe it to be simply an example of a program that the
C++ standard would describe as "ill-formed, no diagnostic required."

A common, yet incorrect expectation that template instantiation somehow mirrors
function call semantics seems to me to lie at the heart of the
misunderstanding.  Hypothetically, if the above program were to be well-formed,
the compiler would need to instantiate the member template twice *with
identical template arguments* in order to obtain the expected two different
outcomes.  However, I recall no specification, in the C++ standard, that
requires such (relatively expensive!) duplication of compiler effort:  once a
template has been instantiated, the compiler seems fully entitled, say, to
cache the result of that instantiation and reuse that outcome as may be needed
during the remainder of that TU's compilation.

Put another way, defining the same function in two different ways (one
instantiation as deleted, one not) seems to be a form of ODR violation.

Perhaps the OP is also a manifestation of a similar misunderstanding; I've not
checked.  If so, I would respectfully recommend this PR be closed as invalid.