[cfe-dev] Fix for PR4701

[Daniel Dunbar]

Ah, the problem appears to be related to the use of PCH:
--
ddunbar at giles:tmp$ cat t.h
#include <Foundation/Foundation.h>
ddunbar at giles:tmp$ cat t.m
id f0(id x) {
  return x->isa;
}
ddunbar at giles:tmp$ clang -x objective-c-header t.h
ddunbar at giles:tmp$ clang -include t.h t.m
0   clang-cc          0x0000000101080755 PrintStackTrace(void*) + 38
1   clang-cc          0x0000000101080ce3 SignalHandler(int) + 336
2   libSystem.B.dylib 0x00007fff812ff83a _sigtramp + 26
3   libSystem.B.dylib 000000000000000000 _sigtramp + 2127562720
4   clang-cc          0x0000000100374eb1
clang::ASTContext::getCanonicalType(clang::QualType) + 39
5   clang-cc          0x0000000100262463
clang::Sema::ImpCastExprToType(clang::Expr*&, clang::QualType,
clang::CastExpr::CastInfo const&, bool) + 123
6   clang-cc          0x00000001002d4635
clang::Sema::ActOnMemberReferenceExpr(clang::Scope*,
clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>,
clang::SourceLocation, clang::tok::TokenKind, clang::SourceLocation,
clang::IdentifierInfo&, clang::OpaquePtr<0>, clang::CXXScopeSpec
const*) + 545
7   clang-cc          0x0000000100429172
clang::Parser::ParsePostfixExpressionSuffix(clang::ASTOwningResult<&(clang::ActionBase::DeleteExpr(void*))>)
+ 2624
8   clang-cc          0x000000010042b587
clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 3115
9   clang-cc          0x000000010042ceb7
clang::Parser::ParseCastExpression(bool, bool, bool) + 99
10  clang-cc          0x000000010042818c
clang::Parser::ParseAssignmentExpression() + 148
11  clang-cc          0x0000000100428616 clang::Parser::ParseExpression() + 42
12  clang-cc          0x0000000100442583
clang::Parser::ParseReturnStatement() + 203
13  clang-cc          0x00000001004441cd
clang::Parser::ParseStatementOrDeclaration(bool) + 2653
14  clang-cc          0x0000000100447a55
clang::Parser::ParseCompoundStatementBody(bool) + 239
15  clang-cc          0x000000010044800b
clang::Parser::ParseFunctionStatementBody(clang::OpaquePtr<0>) + 193
16  clang-cc          0x0000000100450e6d
clang::Parser::ParseFunctionDefinition(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 1009
17  clang-cc          0x00000001004518d3
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::AccessSpecifier)
+ 1599
18  clang-cc          0x0000000100451ec2
clang::Parser::ParseExternalDeclaration() + 1232
19  clang-cc          0x0000000100451f74
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<1>&) + 106
20  clang-cc          0x0000000100260725
clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*,
clang::ASTContext&, bool, bool) + 497
21  clang-cc          0x0000000100030692
ProcessInputFile(clang::Preprocessor&, clang::PreprocessorFactory&,
std::string const&, ProgActions, llvm::StringMap<bool,
llvm::MallocAllocator> const&, llvm::LLVMContext&) + 4175
22  clang-cc          0x000000010003203e main + 2909
23  clang-cc          0x000000010002c550 start + 52
Stack dump:
0.	Program arguments:
/Volumes/Data/Users/ddunbar/llvm/Debug/bin/clang-cc -triple
x86_64-apple-darwin10 -S -disable-free -main-file-name t.m
--relocation-model pic -pic-level=1 --disable-fp-elim
--unwind-tables=1 --mcpu=core2 --fmath-errno=0
-mmacosx-version-min=10.6.0 -include-pch t.h.gch
-fdiagnostics-show-option -o
/var/folders/DQ/DQ8GT3++HESEzT1obWBynE+++TI/-Tmp-/cc-YvJBuv.s -x
objective-c t.m
1.	t.m:2:13: current parser token 'isa'
2.	t.m:1:13: parsing function body 'f0'
3.	t.m:1:13: in compound statement ('{}')
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)
--

Probably the state about the redefinition isn't getting properly
restored? I don't know much about the PCH implementation, myself...

 - Daniel


On Tue, Aug 18, 2009 at 8:57 AM, David Chisnall<csdavec at swansea.ac.uk> wrote:
> On 18 Aug 2009, at 16:47, Daniel Dunbar wrote:
>
>> I think you missed the point here.
>>
>> If ObjCIdRedefinitionType has not been assigned, then it will be the
>> null QualType. The comparison will succeed (since BaseType is not
>> null), then BaseType will be assigned to the null type, then the code
>> will crash a few lines later.
>
> Once again, can you provide a test case which demonstrates this?  I have
> tests which attempt to access fields on an id-typed variable with no
> definition of id provided, and they do not crash and do use this code path.
>  If you can demonstrate a condition where this manifests as a bug, then I
> would be more than happy to fix it.  As, at the moment, it is working as I
> expect it to work, so I can't fix it because I am not seeing any breakage.
>
> The comparison is only there to avoid a redundant implicit cast when there
> is one already (which can only happen in cases where a redefinition is
> supplied).
>
> David
>