This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 05/26/2011 02:30 PM, Paolo Carlini wrote:I should have told you. The error is produced via complete_type_or_maybe_complain called from line 1650 of build_functional_cast itself, by cxx_incomplete_type_diagnostic.Hmm, where's the error coming from in the non-template case? From cp_build_c_cast? In that case always giving the error in build_functional_cast and then returning error_mark_node should avoid duplication.We want to do that only when processing a template, because otherwise we get a duplicate diagnostic, see, eg, auto9.C
complete_type_or_maybe_complain, when type is an error_mark_node understands that an error has been produced already and simply returns NULL_TREE. Thus, something like the below works. Is it closer to what you had in mind?I'd rather deal with that by suppressing that error if we already have error_mark_node.error_mark_node unconditionally, means a better diagnostic, without redundant "array bound is not an integer constant before...".
Attachment:
CL_42056_2
Description: Text document
Attachment:
patch_42056_2
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |