[cfe-dev] integer constant expression oh my!

[Eli Friedman]

On Mon, Nov 17, 2008 at 10:47 AM, Doug Gregor <doug.gregor at gmail.com> wrote:
> On Mon, Nov 17, 2008 at 1:44 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Nov 17, 2008 at 9:57 AM, Doug Gregor <doug.gregor at gmail.com> wrote:
>>> On Mon, Nov 17, 2008 at 12:47 PM, Sebastian Redl
>>> <sebastian.redl at getdesigned.at> wrote:
>>> This also means that one can end up instantiating a template as part
>>> of the evaluation of an integral constant expression (if that template
>>> is a constexpr function template). I think the only real effect this
>>> has on the design is that the ICE checking and expression evaluation
>>> code will need to move from AST into Sema.
>>
>> Don't we have to instantiate the correct template in Sema as part of
>> typechecking?  And isn't that before we might want to evaluate an
>> expression using the template in question?
>
> We have to instantiate the correct template *declaration* as part of
> type-checking. We don't have to instantiation the template
> *definition* until we try to evaluate the value of the expression.

Right... but I'm pretty sure we're still going to instantiate it
before we try to evaluate the value of the expression.  Take the
following program:

template <int i> int f(int (*a)[-i]) {
  int b[i]; return 2;
}
int b() {return 0 ? f<-1>(0) : 0;}

I'm pretty sure we're still supposed to emit a diagnostic (at the very
least, g++ does).  In -fsyntax-only mode, there isn't anything after
Sema; therefore, Sema has to force the instantiation of the definition
at some point.  The only reasonable place to force the instantiation
of the definition is when Sema processes the call to f<-1>.  This is
before the call exists in the AST, so the template will be
instantiated before we might want to evaluate it.

I don't really want to attempt to drag this out before we actually
have a plan for how we're going to implement templates, but if there
really is an architectural issue here, I would prefer to solve it
sooner rather than later.

-Eli