Gabriel Dos Reis - incomplete type return types (original) (raw)
This is the mail archive of the gcc@gcc.gnu.orgmailing 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] |
- From: Gabriel Dos Reis
- To: mark at codesourcery dot com, jason at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: 29 Nov 2005 22:48:14 +0100
- Subject: incomplete type return types
Hi,
I'm looking at PR C++/25156 for which I have a fix (not the incomplete one posted in the audit trail). Everyting goes well, except it makes the testcase g++.dg/expr/return1.C fail for excess error
return1.C:8: error: return-statement with a value, in function returning 'void'
// PR c++/18545
struct A;
A foo() // { dg-error "" }
{
A a; // { dg-error "" }
return a;
}The resason here is that, after we complained that A is incomplete (therefore cannot be used as return type in the function definition), cp/decl.c:check_function_type() changes the return type to void, thus giving misleading diagnostic later.
My question is: why don't we leave the type as is and refrain from going through in-depth semantics processing -- like gimplification and all that (we know the code is in error so that effort is wasted. -- that require that the compiler internal structure be in a sound state?
-- Gaby
- Follow-Ups:
- Re: incomplete type return types
* From: Mark Mitchell
- Re: incomplete type return types
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |