https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681
--- Comment #1 from Andrew Sutton <andrew.n.sutton at gmail dot com> --- This is a good one. It is a regression, but it didn't have to do with the resolution of partial specializations. The substitution into requires-expressions was too eagerly doing full semantic on analysis on simple and compound requirements, and that was causing a later constraint check for a member function to fail unexpectedly. Substituting a concrete type (say, MA2) into the constraint !CA2<MA2> is generating a requirement for the expression t.MA2::mf(). When we go to check that letter, we perform another substitution with the expectation that, in this case, the result would be identical to the original since it's already been resolved. However, the substitution actually rebuilds the call expression and tries to resolve it as MA2::mf(t), which fails. Anyways, this is resolved by deferring all semantic analysis to constraint checking, and not allowing it to happen when we substitute into requirements. Fixed in r222236.
