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 ja...@redhat.com wrote:
On 09/06/2013 12:03 PM, Andrew Sutton wrote:
+// Returns the template type of the class scope being entered. If we're
Andrew Sutton andrew.n.sut...@gmail.com 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
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
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
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
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 in
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
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 the
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,
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
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
12 matches
Mail list logo
