public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/115424] 'auto' type inference not working when struct declared in rhs, even when the final type is not anonymous
Date: Tue, 11 Jun 2024 04:11:59 +0000	[thread overview]
Message-ID: <bug-115424-4-cgCphkDDKe@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-115424-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm from the commit message (r13-3620-ge3c898e12d0ace):
```
    * The standard feature disallows the declaration from declaring
      anything that's not an ordinary identifier (thus, the initializer
      cannot declare a tag or the members of a structure or union), while
      making it undefined behavior for it to declare more than one
      ordinary identifier.  (For the latter, while I keep the existing
      error from __auto_type in the case of more than one declarator, I
      don't restrict other ordinary identifiers from being declared in
      inner scopes such as GNU statement expressions.  I do however
      disallow defining the members of an enumeration inside the
      initializer (if the enum definition has no tag, that doesn't
      actually violate a constraint), to avoid an enum type becoming
      accessible beyond where it would have been without auto.
      (Preventing new types from escaping the initializer - thus, ensuring
      that anything written with auto corresponds to something that could
      have been written without auto, modulo multiple evaluation of VLA
      size expressions when not using auto - is a key motivation for some
      restrictions on what can be declared in the initializer.)

    The rule on shadowing and restrictions on other declarations in the
    initializer are actually general rules for what C2x calls
    underspecified declarations, a description that covers constexpr as
    well as auto (in particular, this disallows a constexpr initializer
    from referencing the variable being initialized).  Thus, some of the
    code added for those restrictions will also be of use in implementing
    C2x constexpr.

```

So this might be expected.

  reply	other threads:[~2024-06-11  4:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11  0:30 [Bug c/115424] New: " malekwryyy at gmail dot com
2024-06-11  4:11 ` pinskia at gcc dot gnu.org [this message]
2024-06-11 15:21 ` [Bug c/115424] " jsm28 at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-115424-4-cgCphkDDKe@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).