[PATCH] D41102: Setup clang-doc frontend framework

Roman Lebedev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Feb 23 15:02:01 PST 2018


lebedev.ri added a comment.

Could you please add a bit more tests? In particular, i'd like to see how blocks-in-blocks work.
I.e. class-in-class, class-in-function, ...

Is there some (internal to `BitstreamWriter`) logic that would 'assert()' if trying to output some recordid
which is, according to the `BLOCKINFO_BLOCK`, should not be there?
E.g. outputting `VERSION` in `BI_COMMENT_BLOCK_ID`?



================
Comment at: clang-doc/BitcodeWriter.cpp:30
+
+static void IntAbbrev(std::shared_ptr<llvm::BitCodeAbbrev> &Abbrev) {
+  Abbrev->Add(llvm::BitCodeAbbrevOp(llvm::BitCodeAbbrevOp::Fixed,
----------------
Ok, these three functions still look off, how about this?
```
// Yes, not by reference, https://godbolt.org/g/T52Vcj
static void AbbrevGen(std::shared_ptr<llvm::BitCodeAbbrev> &Abbrev,
                      const std::initializer_list<llvm::BitCodeAbbrevOp> Ops) {
  for(const auto &Op : Ops)
    Abbrev->Add(Op);
}

static void IntAbbrev(std::shared_ptr<llvm::BitCodeAbbrev> &Abbrev) {
  AbbrevGen(Abbrev, {
    // 0. Fixed-size integer
    {llvm::BitCodeAbbrevOp::Fixed, BitCodeConstants::IntSize}});
}

static void StringAbbrev(std::shared_ptr<llvm::BitCodeAbbrev> &Abbrev) {
  AbbrevGen(Abbrev, {
    // 0. Fixed-size integer (length of the following string)
    {llvm::BitCodeAbbrevOp::Fixed, BitCodeConstants::StringLengthSize},
    // 1. The string blob
    {llvm::BitCodeAbbrevOp::Blob}});
}

// Assumes that the file will not have more than 65535 lines.
static void LocationAbbrev(std::shared_ptr<llvm::BitCodeAbbrev> &Abbrev) {
  AbbrevGen(Abbrev, {
    // 0. Fixed-size integer (line number)
    {llvm::BitCodeAbbrevOp::Fixed, BitCodeConstants::LineNumberSize},
    // 1. Fixed-size integer (length of the following string (filename))
    {llvm::BitCodeAbbrevOp::Fixed, BitCodeConstants::StringLengthSize},
    // 2. the string blob
    {llvm::BitCodeAbbrevOp::Blob}});
}
```
Though i bet clang-format will mess-up the formatting again :/


================
Comment at: clang-doc/BitcodeWriter.cpp:108
+          {COMMENT_CLOSENAME, {"CloseName", &StringAbbrev}},
+          {COMMENT_SELFCLOSING, {"SelfClosing", &IntAbbrev}},
+          {COMMENT_EXPLICIT, {"Explicit", &IntAbbrev}},
----------------
Some of these `IntAbbrev`'s are actually `bool`s.
Would it make sense to already think about being bitcode-size-conservative and introduce `BoolAbbrev` from the get go?
```
static void BoolAbbrev(std::shared_ptr<llvm::BitCodeAbbrev> &Abbrev) {
  AbbrevGen(Abbrev, {
    // 0. Fixed-size boolean
    {llvm::BitCodeAbbrevOp::Fixed, BitCodeConstants::BoolSize}});
}
```
where `BitCodeConstants::BoolSize` = `1U`
 ?
Or is there some internal padding that would make that pointless?


================
Comment at: clang-doc/BitcodeWriter.cpp:156
+                                                 unsigned AbbrevID) {
+  assert(RecordIdNameMap[RID] && "Unknown Abbreviation");
+  assert(Abbrevs.find(RID) == Abbrevs.end() && "Abbreviation already added.");
----------------
Uh, oh, i'm sorry, all(?) these `"Unknown Abbreviation"` are likely copypaste gone wrong.
I'm not sure why i wrote that comment. `"Unknown RecordId"` might make more sense?


================
Comment at: clang-doc/BitcodeWriter.cpp:240
+  if (!prepRecordData(ID, Val)) return;
+  assert(Val < (1U << BitCodeConstants::IntSize));
+  Record.push_back(Val);
----------------
Ok, now that i think about it, it can't be that easy.
Maybe
```
FIXME: assumes 8 bits per byte
assert(llvm::APInt(8U*sizeof(Val), Val, /*isSigned=*/true).getBitWidth() <= BitCodeConstants::IntSize));
```
Not sure whether `getBitWidth()` is really the right function to ask though.
(Not sure how this all works for negative numbers)


================
Comment at: clang-doc/BitcodeWriter.h:53
+  BI_LAST = BI_COMMENT_BLOCK_ID
+};
+
----------------
juliehockett wrote:
> lebedev.ri wrote:
> > So what *exactly* does `BitCodeConstants::SubblockIDSize` mean?
> > ```
> > static_assert(BI_LAST < (1U << BitCodeConstants::SubblockIDSize), "Too many block id's!");
> > ```
> > ?
> It's the current abbrev id width for the block (described [[ https://llvm.org/docs/BitCodeFormat.html#enter-subblock-encoding | here ]]), so it's the max id width for the block's abbrevs.
So in other words that `static_assert()` is doing the right thing?
Add it after the `enum BlockId{}` then please, will both document things, and ensure that things remain in a sane state.


================
Comment at: clang-doc/BitcodeWriter.h:172
+    AbbreviationMap() : Abbrevs(RecordIdCount) {}
+    void add(RecordId RID, unsigned AbbrevID);
+    unsigned get(RecordId RID) const;
----------------
Newline after constructor


================
Comment at: clang-doc/BitcodeWriter.h:216
+
+  // Emission of different abbreviation types
+  void emitAbbrev(RecordId ID, BlockId Block);
----------------
`// Emission of appropriate abbreviation type`


https://reviews.llvm.org/D41102





More information about the cfe-commits mailing list