This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [c++-concepts]: constraint association


> Internally, we want to always store the canonical form of a decl, not the
> source-level form -- the current g++ AST isn't prepared for that (I wish
> it was, but it isn't.)  This allows for simple comparison and other
> semantics processing.

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.


>> I think we want constraints for:
>>
>>   * FUNCTION_DECL
>>   * TEMPLATE_DECL
>>   * TYPE_DECL
>>   * TEMPLATE_PARM_DECL
>
> Well, thinking more about it, I believe we want it only for
>    * TEMPLATE_DECL
>    * TEMPLATE_PARM_DECL.
>
> The FUNCTION_DECL and the TYPE_DECL gets their constraints
> from the abstract instantiation of the associated TEMPLATE_DECL.

If those constraints are cached, I don't see any other place to put
them except in the template info.

On the other hand, it seems like the only place we actually need to
worry about is with non-template member functions. I think I can just
grab the requirements and arguments and check them without caching
them in the template_info.

I'll have to experiment.

We still don't have nodes specific to TEMPLTAE_DECL or
TEMPLATE_PARM_DECL though. It seems like lang_decl_min is the only
place to put this where it will be avilable to both.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]