[PATCH] Fix PR c++/29475: Incomplete template diagnostics

[Mark Mitchell]

Simon Martin wrote:

> 2006-11-05  Simon Martin  <simartin@users.sourceforge.net>
> 
> 	PR c++/29475
> 	* call.c (build_over_call): Always call perform_or_defer_access_check with
> 	the declaration of the function member being called to have a proper
> 	diagnostic in case it is not accessible. When the member is a member
> 	template, the DECL_ACCESS to use is in the primary template; FN is
> 	temporarily altered accordingly.

I don't like this approach for several reasons.  First, temporary
changing the internal representation of things can potentially break
invariants expected by the rest of the code.  Second, if the function
came from a PCH file, we're now triggering writes we don't need, and we
know that number of PCH pages written is a good metric for time.  Third,
 if perform_or_defer_access_check defers the check, it will still come
out wrong: when it goes to process the saved check, the temporary change
will have been undone.

I think that leaves two possible solutions: keep DECL_ACCESS in sync
between functions and specializations, or pass another parameter to
perform_or_defer_access_check, with the declaration to use when printing
error messages.

And, I prefer the second option, since keeping DECL_ACCESS seems harder.
    However, in order to make this work with deferred checks, you would
have to save the deferred check too.  Presently, the deferred checks are
stored in a TREE_LIST, and so we've run out of room there.  But, we
don't want a TREE_LIST anyhow; these should be a VEC of a custom data
structure:

  struct {
    /* The declaration to use when checking access.  */
    tree decl;
    /* The base class in which the declaration is referenced.  */
    tree binfo;
    /* The declaration to use when printing diagnostics.  */
    tree diagnostic_decl;
  };

Would you care to take on that change as well?  If not, you could add
the extra parameter to perform_or_defer_access_check, but just store
decl, rather than diagnostic_decl.  That will not fix the full problem,
but it will fix some of the cases, and it moves us in the right direction.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713