You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Typedefs can have multi-decls like typedef int *A, *B;, and Clang reports two TypedefDecls with source ranges that both start at the beginning of the statement and end at the respective names, just as Clang does for variable multi-decls like int *a, *b;. For variables, 3C recognizes that the overlapping source ranges indicate a multi-decl, and DeclRewriter::rewriteMultiDecl rewrites it properly. But the analogous behavior is not implemented for typedefs, so 3C may try to replace each TypedefDecl in a multi-decl independently and produce invalid output. For example, the following:
typedef_Ptr<int>B; // A is missing!voidfoo(Aa, Bb) {}
typedef_Ptr<int>C, *D; // D became a double pointer!voidbar(Cc, Dd) {
d= (D)1;
}
This problem currently rarely comes up because the common use case for a typedef multi-decl is something like typedef struct { ... } FOO, *PFOO;, and 3C sees that the type of each TypedefDecl is an inline struct and refuses to modify the TypedefDecl at all. But ideally we should remove this limitation on rewriting typedefs containing inline structs (I assume I'll do it along with #542 and won't bother to file a separate issue for it), and then the multi-decl will become a problem.
The text was updated successfully, but these errors were encountered:
Typedefs can have multi-decls like
typedef int *A, *B;
, and Clang reports twoTypedefDecl
s with source ranges that both start at the beginning of the statement and end at the respective names, just as Clang does for variable multi-decls likeint *a, *b;
. For variables, 3C recognizes that the overlapping source ranges indicate a multi-decl, andDeclRewriter::rewriteMultiDecl
rewrites it properly. But the analogous behavior is not implemented for typedefs, so 3C may try to replace eachTypedefDecl
in a multi-decl independently and produce invalid output. For example, the following:converts to:
This problem currently rarely comes up because the common use case for a typedef multi-decl is something like
typedef struct { ... } FOO, *PFOO;
, and 3C sees that the type of eachTypedefDecl
is an inline struct and refuses to modify theTypedefDecl
at all. But ideally we should remove this limitation on rewriting typedefs containing inline structs (I assume I'll do it along with #542 and won't bother to file a separate issue for it), and then the multi-decl will become a problem.The text was updated successfully, but these errors were encountered: