================
@@ -497,6 +499,15 @@ til::SExpr *SExprBuilder::translateCXXThisExpr(const
CXXThisExpr *TE,
return SelfVar;
}
+til::SExpr *
+SExprBuilder::translateCThisExpr(const CThisExpr *CE,
+ CallingContext *Ctx) {
+ // CThisExpr appears in attribute arguments referencing a sibling
+ // field of the enclosing record (typically in C). Substitute the current
+ // SelfArg the exact same way we do for CXXThisExpr.
----------------
ojhunt wrote:
Yes -- for context look at the quantity and size of comments. Most large ones
are either quoting the specification, or extremely complex.
Comments in code aren't free: they get in the way of reading the actual code,
and the code is what actually determines what happens, not the comment. That
means there could be a bug in the code, but a large comment that is not to the
point can obscure the difference between what the comment is intending to
communicate and what the code actually does, and simple code drift changes
behavior and the larger the comment the more likely it is that the behavior of
the code an comment will drift.
Comments that simply describe what the code clearly does are not helpful: the
code says that already
Comments that are large have the problems above and they break up the actual
code, making it difficult to read code when the comment interrupts control flow.
Basically comments should be used only when they're saying something useful:
they're not repeating what the code already says, they should basically be used
to provide a concise summary of behavior that is complex, subtle, or has
non-obvious constraints. Look at other code in clang to get an idea of how much
code is commented, the size and conciseness of the comments when present
(outside of API docs).
https://github.com/llvm/llvm-project/pull/199241
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
