view lphobos/typeinfos1.d @ 1499:df11cdec45a2

Another shot at fixing the issues with (constant) struct literals and their addresses. See DMD2682, #218, #324. The idea is to separate the notion of const from 'this variable can always be replaced with its initializer' in the frontend. To do that, I introduced Declaration::isSameAsInitializer, which is overridden in VarDeclaration to return false for constants that have a struct literal initializer. So {{{ const S s = S(5); void foo() { auto ps = &s; } // is no longer replaced by void foo() { auto ps = &(S(5)); } }}} To make taking the address of a struct constant with a struct-initializer outside of function scope possible, I made sure that AddrExp::optimize doesn't try to run the argument's optimization with WANTinterpret - that'd again replace the constant with a struct literal temporary.
author Christian Kamm <kamm incasoftware de>
date Sun, 14 Jun 2009 19:49:58 +0200
parents 3efbcc81ba45
children
line wrap: on
line source

module typeinfos1;

import
typeinfo1.ti_byte,
typeinfo1.ti_cdouble,
typeinfo1.ti_cfloat,
typeinfo1.ti_char,
typeinfo1.ti_creal,
typeinfo1.ti_dchar,
typeinfo1.ti_delegate,
typeinfo1.ti_double,
typeinfo1.ti_float,
typeinfo1.ti_idouble,
typeinfo1.ti_ifloat,
typeinfo1.ti_int,
typeinfo1.ti_ireal,
typeinfo1.ti_long,
typeinfo1.ti_ptr,
typeinfo1.ti_real,
typeinfo1.ti_short,
typeinfo1.ti_ubyte,
typeinfo1.ti_uint,
typeinfo1.ti_ulong,
typeinfo1.ti_ushort,
typeinfo1.ti_void,
typeinfo1.ti_wchar;