Andrew Sutton writes:
| Ok to commit? Attached is the doc fix patch. I'll send the TREE_TYPE
| patch shortly.
Yes, please -- that is what Jason earlier. Let me know when youve
committed so that I can synchronize with trunk.
-- Gaby
Ok to commit? Attached is the doc fix patch. I'll send the TREE_TYPE
patch shortly.
Andrew
Andrew Sutton
On Sat, Sep 7, 2013 at 1:00 PM, Jason Merrill wrote:
> On 09/06/2013 12:03 PM, Andrew Sutton wrote:
>>
>> +// Returns the template type of the class scope being entered. If we're
>> +// ente
On 09/06/2013 12:03 PM, Andrew Sutton wrote:
+// Returns the template type of the class scope being entered. If we're
+// entering a constrained class scope. TMPL is the most general template
+// of the scope being entered, and TYPE is its type.
TMPL is not part of the interface of fixup_templa
Updated as per comments.
I moved the resolve_template_scope function out to
finish_template_type. I couldn't figure out how to get the parsed
template parameter from the looked-up template in
lookup_class_template. That information may not be available outside
the parse state.
Andrew
Andrew Sutto
On 09/04/2013 01:33 PM, Andrew Sutton wrote:
Ah. The goal is to check after we've deduced/coerced template
arguments into a valid substitution. With functions, that's in
fn_type_unification (hopefully called from instantiate_template)
Actually fn_type_unification calls instantiate_template, but
>> It's not supposed to be different. Checking constraints in
>> instantiate_template is actually too late. We want to check before
>> instantiation, at the point of use.
>
> Right, what I was getting at is that instantiate_template actually only
> instantiates the declaration of a function, not th
On 09/04/2013 11:59 AM, Andrew Sutton wrote:
It's not supposed to be different. Checking constraints in
instantiate_template is actually too late. We want to check before
instantiation, at the point of use.
Right, what I was getting at is that instantiate_template actually only
instantiates th
>> 1. Type constraints are checked on lookup rather than instantiation.
>
>
> How is this different from function template constraints? Is this just a
> difference in internal function name (instantiate_template vs
> lookup_template_class)?
It's not supposed to be different. Checking constraints
On 09/03/2013 11:01 AM, Andrew Sutton wrote:
Attached is a patch for constrained class templates. It's the 3rd time
I've sent it.
Please feel free to ping me if you're waiting for a patch review; once a
week is not too much.
1. Type constraints are checked on lookup rather than instantiatio
Attached is a patch for constrained class templates. It's the 3rd time
I've sent it.
I added some fixes for bugs discovered after the previous send, and
added support for matching constrained declarations in out-of-class
member function definitions.
2013-08-02 Andrew Sutton
* gcc/cp/pt
Attached is a patch that deals with class template constraints. In
particular, it does 3 things:
1. Type constraints are checked on lookup rather than instantiation.
2. Initial support for constrained out-of-class definitions is added
(more work needed)
3. Support for constrained partial template
I changed the method by which class (and alias) template constraints
are checked. Rather than waiting until instantiation, they are now
checked after computing the binding in lookup_class template.
Actually, after the hashtable lookup so we don't re-check constraints
for previously instantiated spe
12 matches
Mail list logo
