[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-dev] Refactorings that operate in regions with preprocessor directives might discard those directives
|
Hi
(Cross-posting on cdt-dev and ptp-dev since this probably interests both groups)
I am trying to implement some refactorings for OpenMP (see http://dev.eclipse.org/mhonarc/lists/ptp-dev/msg04520.html) using PTP. I am using the CDT ASTRewrite (org.eclipse.cdt.core.dom.rewrite.ASTRewrite) to create the changes. The problem is that ASTRewrite discards directives in the source code under certain situations. I know that it happens when I try to use insertBefore(...) and the statement to be inserted is in a block that contains a preprocessor directive in it. I have not tried it with replace(...) or remove(...) yet to see if this problem also occurs there.
I observe the same problem when using "Extract Local Variable" refactoring in CDT.
Here is an example:
======================
Before refactoring
======================
float a[100];
void function() {
int i;
getConstant(); // <----------- Select this statement for "Extract Local Variable"
#pragma omp parallel for
for (i = 0; i < 100; i++) {
a[i] += 1.4142;
}
}
int getConstant() {
return 42;
}
======================
After refactoring
======================
float a[100];
void function() {
int i;
int extractedLocalVariable = getConstant();
extractedLocalVariable;
for (i = 0; i < 100; i++) { //<--------------- Notice that the #pragma omp directive is gone
a[i] += 1.4142;
}
}
int getConstant() {
return 42;
}
In the example, the parameters to insertBefore(...) would be something like
insertBefore(
parent // The IASTCompoundStatement of function()
insertionPoint // The original function call to getConstant();
node // The extractedLocalVariable
textEditGroup // Assume it's null
);
As you can see, the #pragma omp is contained within the parent node and is discarded during the refactoring process.
Am I missing something with the way I am using ASTRewrite or is it a known limitation? Is there a way to get around this limitation since it affects any refactoring that has to operate for OpenMP?
Thanks!
--
Nick Chen