public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ed Smith-Rowland <3dw4rd@verizon.net>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [C++-0x] User defined literals.
Date: Sun, 17 Jul 2011 13:54:00 -0000	[thread overview]
Message-ID: <4E226CA1.90709@verizon.net> (raw)
Message-ID: <20110717135400.cKNy5eQdCYcRm2oJp6HVFgANB0ypBY2CWwZ07i5mBjI@z> (raw)
In-Reply-To: <4E1CB4EB.3070703@redhat.com>

On 07/12/2011 04:56 PM, Jason Merrill wrote:
> A few more notes:
>
>> +      if (DECL_NAMESPACE_SCOPE_P (decl))
>> +       {
>> +         if (!check_literal_operator_args(decl,
>> + &long_long_unsigned_p, &long_double_p))
>> +           {
>> +             error ("%qD has illegal argument list", decl);
>> +             return NULL_TREE;
>> +           }
>> +
>> +         if (CP_DECL_CONTEXT (decl) == global_namespace)
>> +           {
>> +             const char *suffix = UDLIT_OP_SUFFIX (DECL_NAME (decl));
>> +             if (long_long_unsigned_p)
>> +               {
>> +                 if (cpp_interpret_int_suffix (suffix, strlen 
>> (suffix)))
>> +                   warning (0, "integer suffix shadowed by 
>> implementation");
>> +               }
>> +             else if (long_double_p)
>> +               {
>> +                 if (cpp_interpret_float_suffix (suffix, strlen 
>> (suffix)))
>> +                   warning (0, "floating point suffix"
>> +                               " shadowed by implementation");
>> +               }
>> +           }
>> +       }
>
> Doesn't the shadowing apply everywhere, not just at file scope?
Yes, the shadowing should apply everywhere.  What test do I use to get that?
I seem to remember trying something like global_p without success.
>
>> +  if (cpp_userdef_string_p (tok->type))
>> +    {
>> +      string_tree = USERDEF_LITERAL_VALUE (tok->u.value);
>> +      tok->type = cpp_userdef_string_remove_type (tok->type);
>> +      curr_tok_is_userdef_p = true;
>> +    }
>
> It seems like a mistake to change tok->type without changing the 
> value.  Why not just set the 'type' local variable appropriately?
The string lexer is comparing the types of string fragments during 
concatenation to make sure there is no inconsistency (wide vs. narrow, etc.)
The type of string fragment for this purpose is is the string type w/o 
the user-definedness.
Now maybe I should use a *second* local variable, say curr_type, for the 
current fragment.  The variable type stores the initial string type and 
the type
all subsequent fragments must equal.
>
>> +             const char *curr_suffix = IDENTIFIER_POINTER (suffix_id);
>> +             if (have_suffix_p == 0)
>> +               {
>> +                 suffix = xstrdup (curr_suffix);
>> +                 have_suffix_p = 1;
>> +               }
>> +             else if (have_suffix_p == 1 && strcmp (suffix, 
>> curr_suffix) != 0)
> ...
>> +         USERDEF_LITERAL_SUFFIX_ID (literal) = get_identifier (suffix);
>
> Just remember the identifier and compare it with ==.  Identifiers are 
> unique.
Done.
>
>> +  /* Lookup the name we got back from the id-expression.  */
>> +  decl = cp_parser_lookup_name (parser, name,
>
> Maybe use lookup_function_nonclass?
I used this and it simplifies things somewhat.  I'm trying to follow a 
crash while parsing friend declared literals.
>
> Jason
>
>


  reply	other threads:[~2011-07-17  8:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-25 16:35 Ed Smith-Rowland
2011-07-12 17:47 ` Jason Merrill
2011-07-12 21:22   ` Jason Merrill
2011-07-17  8:11     ` Ed Smith-Rowland [this message]
2011-07-17 13:54       ` Ed Smith-Rowland
2011-07-18  7:07       ` Jason Merrill
2011-07-20 22:09     ` Ed Smith-Rowland
2011-07-20 22:31       ` Jason Merrill
2011-08-19 21:56         ` Ed Smith-Rowland
2011-07-17 10:34   ` Ed Smith-Rowland
2011-07-17 14:16     ` Ed Smith-Rowland

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=4E226CA1.90709@verizon.net \
    --to=3dw4rd@verizon.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /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).