C++ PATCHes for c++/50545, 51222

[Jason Merrill]

I've been surprised at the number of issues that have come up while I've 
been working on implementing the notion of instantiation-dependent 
expressions, which aren't currently described in the standard other than 
as "expression involving a template parameter".  I checked in fixes for 
several of these issues last week, but now here's another batch.

The first patch fixes an issue with partial ordering whereby we weren't 
keeping processing_template_decl set when instantiating a function using 
dependent template arguments.

The second patch gives the error about using a parenthesized expression 
list to initialize a non-class variable even if the expressions are 
dependent, to avoid a diagnostic regression as more things become dependent.

The third patch uses coerce_template_parms to make sure that after we've 
substituted the deduced args into the partial specialization argument 
list, we do have arguments of the appropriate type and that constants 
have been folded the way we want.  Without this we could have unresolved 
overloads and variables instead of constants.

The fourth patch implements making a template template parameter a 
friend, which is tested in cpp0x/friend2.C and seems to have worked 
before entirely by accident.

The fifth patch moves the decision to build a SCOPE_REF to express a 
non-type-dependent qualified-id to a different place so that it is 
preserved in partial instantiations.

And finally, the implementation of instantiation_dependent_expression_p. 
  We really only need to check it in two places: deciding whether a 
decltype represents a dependent type, and in checking for 
value-dependence.  I've proposed to the committee that making 
value-dependent a superset of instantiation-dependent, but not doing the 
same for type-dependent, is the best way to handle 
instantiation-dependency, and that's what I've implemented here.  I also 
implemented something that has been a bit controversial on the 
committee: treating member references as instantiation-dependent even 
when they don't actually involve any template parameters, because access 
checking at instantiation time might vary between specializations; see 
my test decltype41.C for an example.

Tested x86_64-pc-linux-gnu, applying to trunk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inst-dep.patch
Type: text/x-patch
Size: 935 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120831/9e36aa19/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compound.patch
Type: text/x-patch
Size: 1524 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120831/9e36aa19/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bindings.patch
Type: text/x-patch
Size: 4624 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120831/9e36aa19/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: friend2.patch
Type: text/x-patch
Size: 4216 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120831/9e36aa19/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scope_ref.patch
Type: text/x-patch
Size: 2793 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120831/9e36aa19/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 51222.patch
Type: text/x-patch
Size: 12742 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120831/9e36aa19/attachment-0005.bin>