This is an archive of the discontinued LLVM Phabricator instance.

PrettyStackTrace guards around ASTReader
AbandonedPublic

Authored by jordan_rose on Nov 5 2014, 11:57 AM.

Details

Summary

What do you think about adding a very trivial PrettyStackTrace guard around the entry points to ASTReader, to remind compiler developers to clear their module cache when they hit a crash here? Would this be the right way to do that?

Diff Detail

Event Timeline

jordan_rose retitled this revision from to PrettyStackTrace guards around ASTReader.
jordan_rose updated this object.
jordan_rose edited the test plan for this revision. (Show Details)
jordan_rose added reviewers: rsmith, benlangmuir.
jordan_rose added subscribers: Unknown Object (MLST), doug.gregor, gottesmm.
rsmith edited edge metadata.Nov 13 2014, 5:42 PM

Yeah, seems like a good idea to me. It's interesting that the places you added this aren't the same places we construct Deserializing objects. I wonder if there are good reasons for the differences.

lib/Serialization/ASTReader.cpp
70

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.

7521

This function doesn't do any reading from the AST file.

7560

This function doesn't do any reading from the AST file.

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.

lib/Serialization/ASTReader.cpp
70

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.

jordan_rose abandoned this revision.Nov 19 2014, 2:33 PM

I thought about how hard it would be to just fix the CMake build and ended up just doing that instead. That drops this down to only being an issue for people actively working on ASTReader, as you said originally, at which point the normal backtrace is probably enough of a hint. Abandoning.