Run clang -cc1 -triple i686-pc-win -S -fms-extensions -cxx-abi microsoft test/CodeGenCXX/mangle-ms-uuidof.cpp Expected: Prints "Cannot mangle this yet" Actual: Crash. Looks related to r160667. Nicos-MacBook-Pro:clang thakis$ ~/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang -cc1 -triple i686-pc-win -S -fms-extensions -cxx-abi microsoft test/CodeGenCXX/mangle-ms-uuidof.cpp 0 clang 0x000000010166c525 PrintStackTrace(void*) + 37 1 clang 0x000000010166c8e4 SignalHandler(int) + 500 2 libsystem_c.dylib 0x00007fff8ef8e8ea _sigtramp + 26 3 libsystem_c.dylib 0x000000010285ca00 _sigtramp + 18446603342454776112 4 clang 0x0000000100ac9515 clang::TemplateArgumentLoc::getSourceRange() const + 53 5 clang 0x0000000100a94228 (anonymous namespace)::MicrosoftCXXNameMangler::mangleTemplateArgs(llvm::SmallVectorImpl<clang::TemplateArgumentLoc> const&) + 200 6 clang 0x0000000100a93156 (anonymous namespace)::MicrosoftCXXNameMangler::mangleUnqualifiedName(clang::NamedDecl const*, clang::DeclarationName) + 2678 7 clang 0x0000000100a92e8e (anonymous namespace)::MicrosoftCXXNameMangler::mangleUnqualifiedName(clang::NamedDecl const*, clang::DeclarationName) + 1966 8 clang 0x0000000100a92553 (anonymous namespace)::MicrosoftCXXNameMangler::manglePostfix(clang::DeclContext const*, bool) + 227 9 clang 0x0000000100a8f8be (anonymous namespace)::MicrosoftCXXNameMangler::mangleName(clang::NamedDecl const*) + 126 10 clang 0x0000000100a8ee84 (anonymous namespace)::MicrosoftCXXNameMangler::mangle(clang::NamedDecl const*, llvm::StringRef) + 340 11 clang 0x0000000100a8e6ab (anonymous namespace)::MicrosoftMangleContext::mangleName(clang::NamedDecl const*, llvm::raw_ostream&) + 251 12 clang 0x00000001002c3f95 clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl) + 773 13 clang 0x00000001002c8822 clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl, llvm::Type*, bool) + 82 14 clang 0x0000000100245595 clang::CodeGen::CodeGenFunction::EmitCXXMemberCallExpr(clang::CXXMemberCallExpr const*, clang::CodeGen::ReturnValueSlot) + 2549 15 clang 0x0000000100239e94 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) + 676 16 clang 0x0000000100263114 (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) + 132 17 clang 0x000000010025d849 clang::StmtVisitorBase<clang::make_ptr, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 473 18 clang 0x0000000100258590 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 96 19 clang 0x000000010022c839 clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) + 169 20 clang 0x000000010022c78a clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 58 21 clang 0x00000001002ad35d clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 381 22 clang 0x00000001002b227b clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 251 23 clang 0x00000001002ad809 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 185 24 clang 0x00000001002ad209 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 41 25 clang 0x00000001002bec51 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 913 26 clang 0x00000001002c7c5d clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl) + 2109 27 clang 0x00000001002c5229 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 249 28 clang 0x00000001002c6977 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 1463 29 clang 0x00000001002cca72 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 882 30 clang 0x00000001002e6d3f (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 95 31 clang 0x00000001002bb708 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 168 32 clang 0x00000001002f32d3 clang::ParseAST(clang::Sema&, bool, bool) + 419 33 clang 0x00000001002ba6dc clang::CodeGenAction::ExecuteAction() + 460 34 clang 0x00000001000bdd68 clang::FrontendAction::Execute() + 104 35 clang 0x000000010009210c clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 956 36 clang 0x000000010005b7b7 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3463 37 clang 0x0000000100051bbd cc1_main(char const**, char const**, char const*, void*) + 749 38 clang 0x000000010005805e main + 3134 39 clang 0x00000001000518a4 start + 52
Created attachment 9280 [details] repro
timurrrr, looks like some code on the stack was added by you. Ideas?
Looking at the code, I think for some reason one of the TemplateArgumentLoc #1 has wrong SourceRange set up. These guys come from the isTemplate function. In this particular case, the bad data comes from the (Spec != NULL, TSI == NULL) branch (line 400 currently) which was introduced in r158376 by Charles: 400: TemplateArgs.push_back(TemplateArgumentLoc(ArgList[i], 401: TemplateArgumentLocInfo())); Charles, do you have any idea how to fix this?
FTR, the diagnostic printing code was written by Charles as well.
(In reply to comment #3) > Looking at the code, I think for some reason one of the TemplateArgumentLoc #1 > has wrong SourceRange set up. > These guys come from the isTemplate function. > In this particular case, the bad data comes from the (Spec != NULL, TSI == > NULL) branch (line 400 currently) which was introduced in r158376 by Charles: > 400: TemplateArgs.push_back(TemplateArgumentLoc(ArgList[i], > 401: TemplateArgumentLocInfo())); > > Charles, do you have any idea how to fix this? I do not. In fact, if I did, I probably wouldn't have passed an empty TemplateArgumentLocInfo to the TemplateArgumentLoc constructor in the first place. As I recall, the problem is that we don't have source location information--or if we do, it's really hard to get. I remember looking into getting proper source location information before proposing this patch, but I (obviously) didn't find much for this particular case (Spec != NULL && TSI == NULL). This source location madness should go away anyway once all the template argument manglings are implemented. (It isn't present in the Itanium mangler, where unlike the Microsoft mangler they actually are all implemented.) Maybe the right solution is to work on actually implementing the case demonstrated by Nico :). Let's run the test case through Visual Studio and see what it produces. I'll get back to you later on that.
Is there any way to re-write diagnostics like this: if (<have enough info>) { // Full diagnostic } else { // Compact diagnostic } ? Otherwise we'll be seeing bugs like this on and on again.
Something like this makes the crash go away: + SourceLocation Loc; SourceRange Range; + if (TAL.getLocInfo().getAsExpr()) { + Loc = TAL.getLocation(); Range = TAL.getSourceRange() } // Issue a diagnostic. [...] "template argument yet"); - Diags.Report(TAL.getLocation(), DiagID) - << TA.getKind() - << TAL.getSourceRange(); + Diags.Report(Loc, DiagID) + << TA.getKind() << Range; …but it prints errors without locations in most cases with that, and it's pretty hacky. Maybe it's better to just implement manglings for more things, and medium term move off of TemplateArgumentLoc to just TemplateArgument (and get locations from elsewhere, e.g. off Exprs, or don't omit them.)
(In reply to comment #7) > Something like this makes the crash go away: > > + SourceLocation Loc; SourceRange Range; > + if (TAL.getLocInfo().getAsExpr()) { > + Loc = TAL.getLocation(); Range = TAL.getSourceRange() } > // Issue a diagnostic. > > [...] > > "template argument yet"); > - Diags.Report(TAL.getLocation(), DiagID) > - << TA.getKind() > - << TAL.getSourceRange(); > + Diags.Report(Loc, DiagID) > + << TA.getKind() << Range; > > > …but it prints errors without locations in most cases with that, and it's > pretty hacky. Maybe it's better to just implement manglings for more things, > and medium term move off of TemplateArgumentLoc to just TemplateArgument (and > get locations from elsewhere, e.g. off Exprs, or don't omit them.) Well, this is better than crashing ;). I was considering doing something like this myself. How about we do this for now, and then we can work on implementing more manglings? WDYT?
I think this was fixed way back in r177471 by simplifying the diagnostic.