This adds the name of the referenced decl, in addition to its USR, to the saved data, so that the backend can look at an info in isolation and still be able to construct a human-readable name for it.
Details
Diff Detail
Event Timeline
clang-doc/BitcodeWriter.cpp | ||
---|---|---|
278 |
| |
clang-doc/BitcodeWriter.h | ||
34 | Looking at the changes, may want to bump the version. | |
62–64 | General observation: you could keep BI_LAST element as the last one in the enum (just like the rest, |
Global question: you are using NamedDecl::getNameAsString(), and passing it as StringRef.
You have looked at this with ASAN, and it's ok?
Also, have you considered using the NamedDecl::getName(), which already returns StringRef.?
clang-doc/Serialize.cpp | ||
---|---|---|
184 | This change from InfoType::IT_record is intentional? | |
201–217 | This very closely matches the parseFields(), with a few changes (I.Params vs I.Members, |
clang-doc/BitcodeWriter.cpp | ||
---|---|---|
382 | Hm, looking at those two functions, not sure NamedDecl::getName() will work here. |
Addressing a fixme and updating tests
clang-doc/BitcodeWriter.cpp | ||
---|---|---|
382 | The field stores it as a string? So the name string is copied into the info data structure itself -- this is so that the backend need have no knowledge of the AST to do its job. | |
clang-doc/Serialize.cpp | ||
201–217 | So the fixme in parseFields was the main difference -- I fixed it, and they are subtly different (that is, parseFields adds a MemberTypeInfo with an access attached to it, where as parseParameters adds a FieldTypeInfo without the access attached). Also, the way to get the information we want from a ParmVarDecl is slightly different from how you get it from a FieldDecl. |
clang-doc/BitcodeWriter.cpp | ||
---|---|---|
382 | One more thing to consider, then: does it always receive std::string? If yes, maybe it would be simpler, more efficient (Since you could std::move() it, |
Looking at the changes, may want to bump the version.