r180603 - C++1y: support simple variable assignments in constexpr functions.

[Abramo Bagnara]

Il 05/05/2013 18:41, Richard Smith ha scritto:
> On Sun, May 5, 2013 at 9:17 AM, Richard Smith <richard at metafoo.co.uk
> <mailto:richard at metafoo.co.uk>> wrote:
> 
>     On Sun, May 5, 2013 at 8:45 AM, Abramo Bagnara
>     <abramo.bagnara at bugseng.com <mailto:abramo.bagnara at bugseng.com>> wrote:
> 
>         Il 05/05/2013 17:05, Richard Smith ha scritto:
>         > On Sun, May 5, 2013 at 2:53 AM, Abramo Bagnara
>         > <abramo.bagnara at bugseng.com
>         <mailto:abramo.bagnara at bugseng.com>
>         <mailto:abramo.bagnara at bugseng.com
>         <mailto:abramo.bagnara at bugseng.com>>> wrote:
>         >
>         >     Il 26/04/2013 16:36, Richard Smith ha scritto:
>         >     > Modified: cfe/trunk/lib/Sema/SemaInit.cpp
>         >     > URL:
>         >    
>         http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=180603&r1=180602&r2=180603&view=diff
>         >     >
>         >    
>         ==============================================================================
>         >     > --- cfe/trunk/lib/Sema/SemaInit.cpp (original)
>         >     > +++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Apr 26 09:36:30 2013
>         >     > @@ -97,6 +97,7 @@ static void CheckStringInit(Expr *Str, Q
>         >     >      DeclT =
>         S.Context.getConstantArrayType(IAT->getElementType(),
>         >     >                                             ConstVal,
>         >     >                                            
>         ArrayType::Normal, 0);
>         >     > +    Str->setType(DeclT);
>         >     >      return;
>         >     >    }
>         >
>         >     Is this change deliberate? It seems to introduce a regression:
>         >
>         >     $ cat z.c
>         >
>         >     void f() {
>         >       signed char s[] = "a";
>         >       unsigned char u[] = "a";
>         >     }
>         >     $ _clang -cc1 -ast-dump z.c
>         >     TranslationUnitDecl 0x67d96e0 <<invalid sloc>>
>         >     |-TypedefDecl 0x67d9bc0 <<invalid sloc>> __int128_t '__int128'
>         >     |-TypedefDecl 0x67d9c20 <<invalid sloc>> __uint128_t
>         'unsigned __int128'
>         >     |-TypedefDecl 0x67d9f70 <<invalid sloc>> __builtin_va_list
>         >     '__va_list_tag [1]'
>         >     `-FunctionDecl 0x67da010 <z.c:2:1, line:5:1> f 'void ()'
>         >       `-CompoundStmt 0x67da350 <line:2:10, line:5:1>
>         >         |-DeclStmt 0x67da208 <line:3:3, col:24>
>         >         | `-VarDecl 0x67da100 <col:3, col:21> s 'signed char [2]'
>         >         |   `-StringLiteral 0x67da198 <col:21> 'signed char
>         [2]' lvalue "a"
>         >         `-DeclStmt 0x67da338 <line:4:3, col:26>
>         >           `-VarDecl 0x67da270 <col:3, col:23> u 'unsigned char
>         [2]'
>         >             `-StringLiteral 0x67da2c8 <col:23> 'unsigned char [2]'
>         >     lvalue "a"
>         >
>         >     Type of string literal should be plain char.
>         >
>         >
>         > Yes, this is deliberate; we intended to set the string
>         literal's type to
>         > the type of the initialized variable (otherwise we would be
>         initializing
>         > an array of 'unsigned char' from an array of 'char'), but
>         accidentally
>         > only updated it in either the array bound or the type, but not
>         both.
>         >
>         >   unsigned char a[] = "foo", b[4] = "bar";
>         >
>         > ... used to produce ...
>         >
>         > |-VarDecl 0x6222ad0 <<stdin>:1:1, col:21> a 'unsigned char [4]'
>         > | `-StringLiteral 0x6222ba8 <col:21> 'const char [4]' lvalue "foo"
>         > `-VarDecl 0x6222c60 <col:1, col:35> b 'unsigned char [4]'
>         >   `-StringLiteral 0x6222cb8 <col:35> 'unsigned char [4]'
>         lvalue "bar"
> 
>         BTW: uniformity is still not there:
>         $ cat z.c
>         void f() {
>           unsigned char q[] = ("a");
>         }
>         $ _clang -cc1 -ast-dump z.c
>         TranslationUnitDecl 0x6f296e0 <<invalid sloc>>
>         |-TypedefDecl 0x6f29bc0 <<invalid sloc>> __int128_t '__int128'
>         |-TypedefDecl 0x6f29c20 <<invalid sloc>> __uint128_t 'unsigned
>         __int128'
>         |-TypedefDecl 0x6f29f70 <<invalid sloc>> __builtin_va_list
>         '__va_list_tag [1]'
>         `-FunctionDecl 0x6f2a010 <z.c:2:1, line:4:1> f 'void ()'
>           `-CompoundStmt 0x6f2a240 <line:2:10, line:4:1>
>             `-DeclStmt 0x6f2a228 <line:3:3, col:28>
>               `-VarDecl 0x6f2a100 <col:3, col:27> q 'unsigned char [2]'
>                 `-ParenExpr 0x6f2a1c8 <col:23, col:27> 'unsigned char
>         [2]' lvalue
>                   `-StringLiteral 0x6f2a198 <col:24> 'char [2]' lvalue "a"
> 
> 
>     Yes, this is definitely wrong. A ParenExpr shouldn't change the type
>     of its operand.
> 
> 
> Fixed in r181159, thanks; this could be coaxed into producing a
> crash-on-valid.


void f() {
  unsigned char q[2] = __extension__ ("a");
}

Consider also this case.

-- 
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com