I originally considered putting it into the Deserializing RAII, but decided against it, mainly because Deserializing can stack but I only really wanted one message in the trace. It's more about "this problem might just be the module cache" than actually providing a trace. There are also a few points where I added a trace where we don't bother setting up a Deserializing object, like selectors.
================ Comment at: lib/Serialization/ASTReader.cpp:70 @@ +69,3 @@ + "\n\n*** Crashed while deserializing from an AST file (e.g. PCH or PCM)." + "\n*** Consider clearing your module cache.\n"; + public: ---------------- rsmith wrote: > I'm not sure I like this as a user-facing message; the revision number is > supposed to be part of the configuration, so the 'clear your module cache' > advice really only applies to people actively hacking on Clang. But I'm fine > with the change with or without this line. The revision number thing hasn't worked for a long time, at least not for git. You're still right that it only applies to compiler devs, but this means there are a lot of people building tools on top of Clang (in our case the Swift compiler) that break when things are updated and don't know anything about modules. I keep meaning to fix the revision thing but not getting around to it. The requirement last time I tried (years ago) was that it has to not do work on null builds. http://reviews.llvm.org/D6138 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
