Skip to content

Issues with DeclRewriter::buildDeclVar handling of existing bounds / itypes #694

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mattmccutchen-cci opened this issue Aug 31, 2021 · 0 comments
Labels

Comments

@mattmccutchen-cci
Copy link
Member

mattmccutchen-cci commented Aug 31, 2021

Some issues with the following code:

SourceRange Range = PVD->getSourceRange();
if (PVD->hasBoundsExpr())
Range.setEnd(PVD->getBoundsExpr()->getEndLoc());
if (Range.isValid() && !inParamMultiDecl(PVD)) {
Type = getSourceText(Range, *Context);
if (!Type.empty()) {
IType = getExistingIType(CV->getExternal()) + BoundsStr;
return;
}
}

(Update 2021-09-08: The getCheckedCAnnotationsEnd function being factored out in #702 might help.)

Duplication of bounds / itypes: 3C rewrites the following:

void foo_i(int *a, int *b : itype(_Array_ptr<int>)) { b = (int *)1; }
void foo_b(int *a, int *b : count(1)) { b = (int *)1; }
void foo_ib(int *a, int *b : itype(_Array_ptr<int>) count(1)) { b = (int *)1; }
void foo_bi(int *a, int *b : count(1) itype(_Array_ptr<int>)) { b = (int *)1; }

to:

void foo_i(_Ptr<int> a, int *b : itype(_Ptr<int>)) { b = (int *)1; }
void foo_b(_Ptr<int> a, int *b : count(1) : count(1)) { b = (int *)1; }
void foo_ib(_Ptr<int> a, int *b : itype(_Array_ptr<int>) count(1) : itype(_Array_ptr<int>) count(1)) { b = (int *)1; }
void foo_bi(_Ptr<int> a, int *b : count(1) : itype(_Array_ptr<int>) count(1)) { b = (int *)1; }

Unnecessary macro expansion: Currently, 3C fails an assertion if an existing itype is inside a macro. #693 will change 3C to regenerate the itype from the AST. But as seen in a test case there, this may unnecessarily expand a macro:

#define macro1 : itype(_Ptr<int>)
void fn(int *b macro1, int *c) {
//CHECK: void fn(int *b : itype(_Ptr<int>), _Ptr<int> c) {
  b = 1;
}

The expansion could be avoided at least in this case by reading a source range for the parameter that is extended to include the itype instead of adding the itype separately, as the code tries to do for the bounds; here's a proof of concept. But this might cause other problems.

john-h-kastner added a commit that referenced this issue Sep 2, 2021
Fixes an assertion failure (#594) when
attempting to extract the string representation of an itype expression from the
original source code if the itype expression is inside a macro. The string
representation for itypes in macros is now re-generated from the AST.

The fix in its current form leads to some unnecessary expansion of macros. This
is discussed in #694.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant