Bug 237828 - AssertionError: Method parameter without PARAMETER flag
AssertionError: Method parameter without PARAMETER flag
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Compiler
8.0
All All
: P2 (vote)
: 8.0.1
Assigned To: Dusan Balek
issues@java
EXCEPTIONS_REPORT
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-30 20:46 UTC by michbarsinai
Modified: 2014-08-01 02:09 UTC (History)
14 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
stacktrace (6.08 KB, text/plain)
2013-10-30 20:47 UTC, michbarsinai
Details
stacktrace (7.46 KB, text/plain)
2013-12-17 23:40 UTC, janario
Details
stacktrace (4.86 KB, text/plain)
2014-01-08 13:33 UTC, aldobrucale
Details
stacktrace (5.37 KB, text/plain)
2014-01-18 12:09 UTC, Exceptions Reporter
Details
stacktrace (6.65 KB, text/plain)
2014-01-23 04:39 UTC, michbarsinai
Details
stacktrace (6.73 KB, text/plain)
2014-01-23 18:27 UTC, chuprin
Details
stacktrace (7.09 KB, text/plain)
2014-02-20 21:55 UTC, Michel Graciano
Details
stacktrace (7.09 KB, text/plain)
2014-02-21 10:40 UTC, Michel Graciano
Details
stacktrace (4.95 KB, text/plain)
2014-07-22 22:49 UTC, Jesse Glick
Details
Possible fixes (2.77 KB, patch)
2014-07-29 16:10 UTC, Svata Dedic
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description michbarsinai 2013-10-30 20:46:59 UTC
Build: NetBeans IDE Dev (Build 201310250001)
VM: Java HotSpot(TM) 64-Bit Server VM, 24.0-b48, Java(TM) SE Runtime Environment, 1.7.0_40-ea-b29
OS: Mac OS X

User Comments:
michbarsinai: Working on java code, inside a try/catch block. Note that the block was not complete, it had the try { ... } but not the catch clause. The "try {" was marked with an error.




Stacktrace: 
java.lang.AssertionError: Method parameter without PARAMETER flag
   at com.sun.tools.javac.util.Assert.error(Assert.java:133)
   at com.sun.tools.javac.util.Assert.check(Assert.java:94)
   at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitMethodDef(Flow.java:1774)
   at com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitMethodDef(Flow.java:2546)
   at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:778)
   at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
Comment 1 michbarsinai 2013-10-30 20:47:01 UTC
Created attachment 141720 [details]
stacktrace
Comment 2 janario 2013-12-17 23:40:07 UTC
Created attachment 143281 [details]
stacktrace

coding. Adding another parameter in a method
Comment 3 aldobrucale 2014-01-08 13:33:42 UTC
Created attachment 143711 [details]
stacktrace

added a semicolon between a parameter type and its name
Comment 4 Exceptions Reporter 2014-01-18 12:09:50 UTC
Created attachment 144100 [details]
stacktrace

Exception after javadoc template insertion.
Comment 5 michbarsinai 2014-01-23 04:39:54 UTC
Created attachment 144277 [details]
stacktrace

During code completion that included enums, and was for a parameter of another method.
Comment 6 chuprin 2014-01-23 18:27:56 UTC
Created attachment 144316 [details]
stacktrace

Hi all. I added method with code completion and change "Object" to specified variable name
Comment 7 Michel Graciano 2014-02-20 21:55:36 UTC
Created attachment 145453 [details]
stacktrace

Coping some classes with refactoring activated (Lombok active)
Comment 8 Michel Graciano 2014-02-21 10:40:40 UTC
Created attachment 145463 [details]
stacktrace

Coping some class files from a package to another (Lombok active). It does not happens at 7.4
Comment 9 Michel Graciano 2014-02-21 10:42:31 UTC
It looks like to be a regression since I can't reproduce it at 7.4.
Comment 10 Dusan Balek 2014-02-21 11:27:25 UTC
Could you please create a simple reproducible test case and attach it to the issue? Thanks.
Comment 11 Alexander Simon 2014-02-21 18:23:30 UTC
21 reports => P2
Comment 12 Jan Lahoda 2014-02-21 20:21:41 UTC
Which exact Lombok version is that? I think Lombok was fixed to include the PARAMETER flag on some places some time ago. A testcase to reproduce would help to determine whether that was sufficient to cover this situation or not.
Comment 13 Michel Graciano 2014-02-22 20:18:21 UTC
I will check the Lombok version we are using, but AFAIR it is the latest one. So far, I was unable to create a sample to reproduce it. The only think I was able to reproduce was issue #242191. Monday I will check this issue as soon as I get back to work.

Regards
Comment 14 Michel Graciano 2014-03-05 14:38:08 UTC
We have been using Lombok 1.12.4. I am not able to reproduce it yet.
Comment 15 MackSix 2014-07-18 04:02:06 UTC
I don't know if this is helpful, but I have a freeform project that got messed up by Inspect & Transform and if I open a file from the project, this AssertionError is thrown every time.

1. Unzip the freeform project (jEdit) that can be found at http://deadlock.netbeans.org/hudson/job/upload/ws/
2. Run NetBeans.
3. You don't have to open project, just open the file BufferHistory.java located in package org.gjt.sp.jedit.
4. Scroll down.

By now this AssertionError should be thrown. 

Product Version: NetBeans IDE Dev (Build nbms-and-javadoc-1921-on-20140717)
Java: 1.8.0_11; Java HotSpot(TM) 64-Bit Server VM 25.11-b03
Runtime: Java(TM) SE Runtime Environment 1.8.0_11-b12
System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
Comment 16 MackSix 2014-07-18 04:27:30 UTC
It may not be helpful because the file was made uncompilable, but curious that no errors show in the editor.
Comment 17 Jesse Glick 2014-07-22 22:49:28 UTC
Created attachment 148222 [details]
stacktrace

Changing parameters of an (overridden) method, did not yet import the type of one of the modified parameters.
Comment 18 sedlakf 2014-07-24 14:43:53 UTC
This error happens to me without using Lombok.
Comment 19 Svata Dedic 2014-07-29 16:09:37 UTC
I was working with the example attached in Comment#15; I've found out that VarSymbols that correspond to method parameters are created with 0 PARAMETER flag only as a part of error recovery from PostAttrAnalyzer *and* from some Lambda translation code (sorry I didn't yet fully decipher its function).

A possible fix would be that PostAttrAnalyzer properly uses PARAMETER flag when visiting method's variable.

Second possible fix is to add a condition to the Assert clause that prevents Asserting on erroneous symbols (owner == noSymbol). May be less intrusive because PostAttrAnalyzer creates very rudimentary symbols with no flags at all. 

Please check the attached diff (both approaches are present).

Note: the fix in Attr.java, line 4891 is a NPE which appears when opening the attached project. The md is also an errorenous method with no restype at all.
Comment 20 Svata Dedic 2014-07-29 16:10:11 UTC
Created attachment 148387 [details]
Possible fixes
Comment 21 Dusan Balek 2014-07-30 13:06:08 UTC
Fixed in jet-main. Thanks for the patch.

http://hg.netbeans.org/jet-main/rev/79b30f18dab0
http://hg.netbeans.org/nb-javac/rev/bc997355c91a
Comment 22 Quality Engineering 2014-08-01 02:09:52 UTC
Integrated into 'main-silver', will be available in build *201408010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/79b30f18dab0
User: Dusan Balek <dbalek@netbeans.org>
Log: Issues #152386 and #237828 fixed.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo