Would anyone object to an attempt to improve cast<> error messages by
outputting the expected type and the type received?
The interface I'm thinking of is to use ADL to do visitor-style lookup,
so we don't need to change every client. In particular, for clients in
clang, we can just create these functions implicitly from our
TableGen-generated files. I'm not sure about clients in LLVM since I
don't do much work there.
This would have to introduce a dependency in llvm/Support/Casting.h on
some library for string concatenation; preferably <string> but a
lower-level interface could be used it someone objects (or it could be
done manually, but that seems horrible).
An example of what this would be like is:
// Before cast<> in llvm/Support/Casting.h
const char *DebugTypeName(void*) {
}
// In the header for the type at some reasonable point before cast<> is
// instatiated for that type
const char *DebugTypeName(Foo*) {
return "Foo";
}
The pointer is only for ADL purposes and will always be 0.
Sean
Hi,> This would have to introduce a dependency in llvm/Support/Casting.h on > some library for string concatenation; preferably <string> but a > lower-level interface could be used it someone objects (or it could be > done manually, but that seems horrible).Wouldn't StringRef make more sense? Cheers, James> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Hunt > Sent: 22 June 2011 03:55 > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Improving cast<> failure messages. > > Would anyone object to an attempt to improve cast<> error messages by > outputting the expected type and the type received? > > The interface I'm thinking of is to use ADL to do visitor-style lookup, > so we don't need to change every client. In particular, for clients in > clang, we can just create these functions implicitly from our > TableGen-generated files. I'm not sure about clients in LLVM since I > don't do much work there. > > This would have to introduce a dependency in llvm/Support/Casting.h on > some library for string concatenation; preferably <string> but a > lower-level interface could be used it someone objects (or it could be > done manually, but that seems horrible). > > An example of what this would be like is: > > // Before cast<> in llvm/Support/Casting.h > const char *DebugTypeName(void*) { > } > > // In the header for the type at some reasonable point before cast<> is > // instatiated for that type > const char *DebugTypeName(Foo*) { > return "Foo"; > } > > The pointer is only for ADL purposes and will always be 0. > > Sean > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Depends a lot on the details, but this would be really really useful! -Chris On Jun 21, 2011, at 7:54 PM, Sean Hunt wrote:> Would anyone object to an attempt to improve cast<> error messages by > outputting the expected type and the type received? > > The interface I'm thinking of is to use ADL to do visitor-style lookup, > so we don't need to change every client. In particular, for clients in > clang, we can just create these functions implicitly from our > TableGen-generated files. I'm not sure about clients in LLVM since I > don't do much work there. > > This would have to introduce a dependency in llvm/Support/Casting.h on > some library for string concatenation; preferably <string> but a > lower-level interface could be used it someone objects (or it could be > done manually, but that seems horrible). > > An example of what this would be like is: > > // Before cast<> in llvm/Support/Casting.h > const char *DebugTypeName(void*) { > } > > // In the header for the type at some reasonable point before cast<> is > // instatiated for that type > const char *DebugTypeName(Foo*) { > return "Foo"; > } > > The pointer is only for ADL purposes and will always be 0. > > Sean > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev