This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Error in rewriting of UnaryTree | ||
|---|---|---|---|
| Product: | java | Reporter: | tronicek <tronicek> |
| Component: | Source | Assignee: | Rastislav Komara <moonko> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | fommil |
| Priority: | P3 | Keywords: | NETFIX |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
test case, no fix yet
(updated, bug in previous) test case, no fix yet added second failing test case 2 test cases and proposed fix |
||
. Created attachment 81866 [details]
test case, no fix yet
I'd like to NetFIX [1] this bug. Is it possible? [1] http://wiki.netbeans.org/NetFIX Probably yes. Look at handling diff of unary expression in CasualDiff. Created attachment 81926 [details]
(updated, bug in previous) test case, no fix yet
I believe the bug is on the line int[] argBounds = getBounds(oldT.arg); in CasualDiff.diffUnary. It appears to be returning the wrong argBounds[0], being off by one. The oldT.arg refers to "-x" in this case, not "--x". Some additional logic is required. OK, I think I found *another* problem with the Unary differ... it doesn't handle cases where the unary operator changes left/right ordering. A UnaryTree can have pre and post operators. e.g. --c, c++. I'm attaching a new diff which includes a new failing test case. Hmm... here's a dumb question, but why do we go to all this effort to write out what a Tree means, when the toString() methods already do all the work for us? Is it because the toString() is ill-defined? If so, that's a bit of a poor excuse, because there are lots of examples of precedent (especially in the hinter) where the toString() method of Trees are used. Created attachment 82159 [details]
added second failing test case
Created attachment 82238 [details]
2 test cases and proposed fix
I believe java.source-158150-4.patch fixes this bug! :-) Ready for review. The problem was that the current code forgot that the operator can be on either side of the expression, forgetting that (most!) unary operators are actually on the left of the expression, hence inappropriate copyTo calls. ACCEPTED jet-main #5e5aa9deaa08 Integrated into 'main-golden', will be available in build *200905230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/5e5aa9deaa08 User: Rastislav Komara <moonko@netbeans.org> Log: #158150: Error in rewriting of UnaryTree |
I am trying to rewrite - - x to + x: UnaryTree node2 = (UnaryTree) node; UnaryTree original = (UnaryTree) node2.getExpression(); modified = make.Unary(Kind.UNARY_PLUS, original.getExpression()); System.out.println("original: " + node); System.out.println("modified: " + modified); wc.rewrite(node, modified); The log contains what I expected: original: --x modified: +x But the source is changed from int y = - - x; to int y + - x;