[Bug c++/98283] New: decltype(auto) may be deduce static data member to wrong type

[Bug c++/98283] New: decltype(auto) may be deduce static data member to wrong type

[wuyongwei at gmail dot com]

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

            Bug ID: 98283
           Summary: decltype(auto) may be deduce static data member to
                    wrong type
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wuyongwei at gmail dot com
  Target Milestone: ---

The following code shows that `decltype(auto)` is deduced to the wrong type
when used in template code for an expression like `(var.static_data_member>)`.

```cpp
#include <cstddef>
#include <type_traits>
#include <utility>

template <typename T>
struct type_displayer;

#define TYPE_DISPLAY(x) type_displayer<decltype(x)> test_obj;

struct SkipField {};

struct TestSkip {
    template <typename T, std::size_t> struct FIELD;

    int value;
    static SkipField unused;

    template <typename T>
    struct FIELD<T, 0> {
        T &&obj;
        FIELD(T &&ref) : obj(std::forward<T>(ref))
        {
        }
        decltype(auto) value()
        {
            return (obj.value);
        }
        static constexpr const char *name()
        {
            return "value";
        }
    };

    template <typename T>
    struct FIELD<T, 0 + 1> {
        T &&obj;
        FIELD(T &&ref) : obj(std::forward<T>(ref))
        {
        }
        decltype(auto) value()
        {
            return (obj.unused);
        }
        decltype((obj.unused)) valueAlt()
        {
            return (obj.unused);
        }
        static constexpr const char *name()
        {
            return "unused";
        }
    };
};

int main()
{
    TestSkip s;
    // decltype((TestSkip::FIELD<TestSkip&, 0>(s).value()))    is int&
    // decltype((TestSkip::FIELD<TestSkip&, 1>(s).value()))    is SkipField,
but it should be SkipField&
    // decltype((TestSkip::FIELD<TestSkip&, 1>(s).valueAlt())) is SkipField&
}
```

This is a simplified usage scenario, where I want to use a macro to generate
code to emulate static reflection. Here is the problematic part:

```cpp
        decltype(auto) value()
        {
            return (obj.unused);
        }
```

This function returns `SkipField`, instead of the expected `SkipField&`. I have
verified that clang does what I want.

Currently I have to avoid `decltype(auto)` as a workaround:

```cpp
        decltype((obj.unused)) valueAlt()
        {
            return (obj.unused);
        }
```

(I used the macro TYPE_DISPLAY to check the type of an expression.)

[Bug c++/98283] decltype(auto) may deduce a static data member to wrong type in a template

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Keywords|                            |accepts-invalid
   Last reconfirmed|                            |2021-08-03
            Summary|decltype(auto) may deduce a |decltype(auto) may deduce a
                   |static data member to wrong |static data member to wrong
                   |type                        |type in a template

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reduced testcase that is accepted but should not be:
struct TestSkip {
    static int unused;
};
template <class T>
struct FIELD {
    TestSkip *obj;
    decltype(auto) value()  {  return (obj->unused);  }
};
int main()
{
    TestSkip s;
    int sf;
    int i;
    decltype((FIELD<int>().value())) b;
}

Confirmed.

[Bug c++/98283] decltype(auto) may deduce a static data member to wrong type in a template

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:e4f1ea5d8b96fc9fbe4fc0e0e0a4938ceeef092f

commit r14-560-ge4f1ea5d8b96fc9fbe4fc0e0e0a4938ceeef092f
Author: Patrick Palka <ppalka@redhat.com>
Date:   Sun May 7 11:57:22 2023 -0400

    c++: parenthesized -> resolving to static data member [PR98283]

    Here we're neglecting to propagate parenthesized-ness when the
    member access (this->m) resolves to a static data member (and
    thus finish_class_member_access_expr yields a VAR_DECL instead
    of a COMPONENT_REF).

            PR c++/98283

    gcc/cp/ChangeLog:

            * pt.cc (tsubst_copy_and_build) <case COMPONENT_REF>: Propagate
            REF_PARENTHESIZED_P more generally via force_paren_expr.
            * semantics.cc (force_paren_expr): Document default argument.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp1y/paren6.C: New test.

[Bug c++/98283] decltype(auto) may deduce a static data member to wrong type in a template

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |14.0
                 CC|                            |ppalka at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 14, thanks for the bug report