After merging from trunk this morning, I discovered that
DECL_SIZE_UNIT is now being used to store lists of specializations. I
had been using that to store template constraints. Oops.
This patch moves constraints outside the usual tree structures into an
association maintained in a hash table. It
Just a couple of typos:
On 06/24/2013 11:56 AM, Andrew Sutton wrote:
+// Returns true if NEWDECL and OLDDEC are member functions with with
"OLDDECL"
+// different constraints. If NEWDECL and OLDDECL are non-template members
+// or specializations of non-template members, they overloads are
Andrew Sutton writes:
| Revisions from previous patch.
|
| I've taken constraint_info out of lang_decl_min and made it specific
| to TEMPLATE_DECLs by saving it as DECL_SIZE_UNIT. It seems to be
| unused for templates. When I start working on the shorthand notation,
| I'll do something similar f
Revisions from previous patch.
I've taken constraint_info out of lang_decl_min and made it specific
to TEMPLATE_DECLs by saving it as DECL_SIZE_UNIT. It seems to be
unused for templates. When I start working on the shorthand notation,
I'll do something similar for template parameters and auto
decl
Andrew Sutton writes:
| > | 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
Andrew Sutton writes:
| > | Previous discussion seemed to indicate that saving constraints with
| > | template decls was preferable.
| >
| > Yes; exactly.
| >
| > | The committed version in the branch carries those constraints in
| > | template_info for the temploid.
| >
| > Yes; I think that is
> | 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
| 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
> | Previous discussion seemed to indicate that saving constraints with
> | template decls was preferable.
>
> Yes; exactly.
>
> | The committed version in the branch carries those constraints in
> | template_info for the temploid.
>
> Yes; I think that is good.
So we should associate constraints
* We have to avoid increasing memory consumption for regular C++ codes
that do not use concepts lite. This is an important criteria. We
have only one front-end that is invoked in C++03, C++11, C++14, and
C++17 modes. Almost all existing codes are C++03, C++11, and even
C++14 only and do
> | 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 d
Andrew Sutton writes:
| > 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 witho
> 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
On Sat, Jun 22, 2013 at 12:11 PM, Gabriel Dos Reis wrote:
> Andrew Sutton writes:
>
> | I the long term, I think we'll end up having constraints attached to
> | declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
> | Although now that I'm looking, it seems that lang_decl_parm does
Andrew Sutton writes:
| I the long term, I think we'll end up having constraints attached to
| declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
| Although now that I'm looking, it seems that lang_decl_parm does not
| inherit lang_min. Hmm...
|
| Mostly, though, I'm not sure wh
I the long term, I think we'll end up having constraints attached to
declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
Although now that I'm looking, it seems that lang_decl_parm does not
inherit lang_min. Hmm...
Mostly, though, I'm not sure where I could put it where both
TEMPLA
On Sat, Jun 22, 2013 at 10:57 AM, Andrew Sutton
wrote:
> I changed the implementation to associate constraints with template
> decls (actually lang_decl_min) rather than template_info.
Hmm, why move it to lang_decl_min? Now, every C++ declaration will
have a constraint, instead of just temploids
I changed the implementation to associate constraints with template
decls (actually lang_decl_min) rather than template_info.
The handling of constrained non-template member functions changes a
little. When a class template is instantiated the instantiated
requirements are associated directly with
18 matches
Mail list logo
