juliehockett added inline comments.
================ Comment at: clang-doc/BitcodeWriter.cpp:382 + emitRecord(R.USR, REFERENCE_USR); + emitRecord(R.Name, REFERENCE_NAME); + emitRecord((unsigned)R.RefType, REFERENCE_TYPE); ---------------- lebedev.ri wrote: > >>! In D46281#1083806, @lebedev.ri wrote: > > 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`.? > > Hm, looking at those two functions, not sure `NamedDecl::getName()` will work > here. > Alternatively, have you considered just making this `Name` field store > `DeclarationName`, > and call `getNameAsString()` only here? 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. ================ Comment at: clang-doc/Serialize.cpp:200-217 static void parseParameters(FunctionInfo &I, const FunctionDecl *D) { for (const ParmVarDecl *P : D->parameters()) { - SymbolID Type; - std::string Name; - InfoType RefType; if (const auto *T = getDeclForType(P->getOriginalType())) { - Type = getUSRForDecl(T); - if (dyn_cast<EnumDecl>(T)) - RefType = InfoType::IT_enum; - else if (dyn_cast<RecordDecl>(T)) - RefType = InfoType::IT_record; - I.Params.emplace_back(Type, RefType, P->getQualifiedNameAsString()); - } else { - Name = P->getOriginalType().getAsString(); - I.Params.emplace_back(Name, P->getQualifiedNameAsString()); + if (const auto *N = dyn_cast<EnumDecl>(T)) { + I.Params.emplace_back(getUSRForDecl(N), N->getNameAsString(), + InfoType::IT_enum, P->getQualifiedNameAsString()); + continue; ---------------- lebedev.ri wrote: > This very closely matches the `parseFields()`, with a few changes (`I.Params` > vs `I.Members`, > `getUSRForDecl(T)` vs `getUSRForDecl(N)`, `F->getQualifiedNameAsString()` vs > `P->getQualifiedNameAsString()`). > If it makes sense, it might be a good idea to refactor them together? 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. https://reviews.llvm.org/D46281 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits