> | Agreed. But without some source-level annotations in the tree, I don't > | think I can generate the diagnostics that programmer's might otherwise > | expect. I'd have to emit the internal representation. > > Do you have examples where we don't do or we can't do the obvious thing > in terms of diagnostics?
I think we'll have this problem anywhere we want to pretty-print a template parameter that's declared using the concept shorthand. I'll have a better feeling for the issue once I start working the shorthand in. > | If those constraints are cached, I don't see any other place to put > | them except in the template info. > > Exactly. Previous discussion seemed to indicate that saving constraints with template decls was preferable. > | On the other hand, it seems like the only place we actually need to > | worry about is with non-template member functions. > > Member function of templates are temploids, so no worry there either. > (Internally, they act and are represented like templates.) There's a difference between when those declarations are instantiated and when their constraints really need to be evaluated. Because temploids are instantiated with a class definition (prior to use), we (may) need to carry some information with those instances. The committed version in the branch carries those constraints in template_info for the temploid. The submitted patch carries the instantiated constraints with the member declaration. The most recent version on my work computer doesn't carry any constraints with temploids -- it instantiates the requirements directly from the template/args in the declarations' template_info. > | I think I can just grab the requirements and arguments and check them > | without caching them in the template_info. > > I think we need to remember them for duplicate_decls or other routines > that either check or use ODR-derived properties. This doesn't seem to be a problem. IIRC, the instantiated declarations are differentiated by their template constraints, not their instantiated constraints. Differentiating by instantiated constraints may not be viable, anyways. Especially, if the instantiation folds them to only "true" or "false". > | We still don't have nodes specific to TEMPLTAE_DECL or > | TEMPLATE_PARM_DECL though. > > A tree with TREE_CODE equal to TEMPLATE_DECL or TEMPLATE_PARM_DECL is > just that. What we do is to use all unused- tree slots. Or are you > suggesting we have exhausted all available pre-defined slots on such nodes? Unknown. I'll have to look. But, I don't think we have a single TEMPLATE_PARM_DECL node. Template parameters are either TYPE_DECLs or PARM_DECLs. I think auto declarations, get VAR_DECLs, but I haven't looked closely at that design. I'd have to look to see if there are any free tree slots all of those decl nodes to minimize. Andrew
