Community
Participate
Working Groups
Created attachment 210541 [details] EDT project (requires RUI and Dojo widget projects) I installed the nightly build on 2/4 (I believe it said it was the 2/2 build). I then created a new 'Web client with services' project and stared copying .egl files from an RBD 8 project into the new EDT project. I would expect to see hundreds of errors being reported in the Problems view since these .egl files should be failing during compilation for all sorts of reasons (using invalid stereotypes like SQLRecord, package name doesn't match directory structure, etc), but I am not. Also, if I open one of the .egl files in the EGL source editor, no errors are shown until I 'touch' the file (i.e. type a letter into the editor). Attached is my EDT project. As mentioned previously, it should have hundreds of errors in it ..
I am using 0.8.0.v201202022101
Will, does this still appear to be happening for you? Note that our first successful build in a while is from 2/8 at 9AM. I pasted the following record into an editor, and red squiggles appear: record Rec1 type SQLRecord itemName string; end
I installed the latest nightly build (0.8.0.v201202082102) and see the same issue. Try importing the attached project into a new workspace (note: you'll need to pull in the RUI widgets and Dojo project). You should see the same issues: * No error markers in the Project Explorer view on EGL files that have errors * No EGL errors shown in the Problems view * I have one file that has multiple [invalid] SQLRecords within it (see CommonRecords.egl). The first 2 record definitions show lots of errors in the editor, but the other records are incorrectly shown as being valid (see attached screen shot)
Created attachment 210769 [details] Screen shot showing errors (or lack thereof) in the EGL source editor, etc
Created attachment 210770 [details] .log file See attached .log file. This was created by deleting the old .log, restarting the workbench, and doing a Project > Clean (all).
Hi Will, I did some investigate for the problem you mentioned.It turns out that edt build will clear all previous Markers if a import project was never built successful. And create "EDT Build Problem" as whole If you create another project and copy "CommonRecords.egl" into the new project. All those errors can be show in problem view,project explorer view and egl source editor. I think it might work as design which will just show a "EDT Build Problem" marker when a import project never built successful. We need to consider if current design can be accepted.
The current behavior is not acceptable, primarily because I as a developer have no idea where to start fixing problems since error markers appear seemingly at random.
This is working correctly, with one problem that I see. Xiao Bin is correct that when a fatal builder error occurs (in this case, the compiler is blowing up instead of gracefully showing a compile error on bad syntax or semantics, but another type would be an invalid EGL build path). The project in this case is given a single EGL error marker stating that the project cannot be built. JDT does the same thing. As for missing error markers from the dynamic red squiggles, they aren't "being missed", it's that our problem requestor has a cap of 40 errors (and has been for many years). If you comment out some of the errors in your screenshot you will then see errors below it that are new. I do not know why the cap is set to 40 errors, maybe Brian or Paul know. Here's the compiler stack trace in my log that should be looked at by someone: Caused by: java.lang.UnsupportedOperationException at org.eclipse.edt.compiler.binding.NotFoundBinding.getKind(NotFoundBinding.java:56) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofBase.mofTypeFor(Egl2MofBase.java:920) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofExpression.visit(Egl2MofExpression.java:301) at org.eclipse.edt.compiler.internal.egl2mof.Egl2Mof.visit(Egl2Mof.java:1) at org.eclipse.edt.compiler.core.ast.FieldAccess.accept(FieldAccess.java:52) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofExpression.visit(Egl2MofExpression.java:179) at org.eclipse.edt.compiler.internal.egl2mof.Egl2Mof.visit(Egl2Mof.java:1) at org.eclipse.edt.compiler.core.ast.ArrayLiteral.accept(ArrayLiteral.java:38) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofExpression.visit(Egl2MofExpression.java:217) at org.eclipse.edt.compiler.internal.egl2mof.Egl2Mof.visit(Egl2Mof.java:1) at org.eclipse.edt.compiler.core.ast.Assignment.accept(Assignment.java:111) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofExpression.processSettings(Egl2MofExpression.java:912) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofExpression.visit(Egl2MofExpression.java:805) at org.eclipse.edt.compiler.internal.egl2mof.Egl2Mof.visit(Egl2Mof.java:1) at org.eclipse.edt.compiler.core.ast.NewExpression.accept(NewExpression.java:89) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofExpression.visit(Egl2MofExpression.java:217) at org.eclipse.edt.compiler.internal.egl2mof.Egl2Mof.visit(Egl2Mof.java:1) at org.eclipse.edt.compiler.core.ast.Assignment.accept(Assignment.java:111) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofStatement.visit(Egl2MofStatement.java:106) at org.eclipse.edt.compiler.internal.egl2mof.Egl2Mof.visit(Egl2Mof.java:1) at org.eclipse.edt.compiler.core.ast.AssignmentStatement.accept(AssignmentStatement.java:36) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofPart.handleEndVisitPart(Egl2MofPart.java:521) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofPart.defaultHandleVisitPart(Egl2MofPart.java:386) at org.eclipse.edt.compiler.internal.egl2mof.Egl2MofPart.visit(Egl2MofPart.java:199) at org.eclipse.edt.compiler.internal.egl2mof.Egl2Mof.visit(Egl2Mof.java:1) at org.eclipse.edt.compiler.core.ast.Handler.accept(Handler.java:55) at org.eclipse.edt.compiler.internal.egl2mof.Egl2Mof.convert(Egl2Mof.java:160) at org.eclipse.edt.ide.core.internal.builder.AbstractProcessingQueue.createIRFromBoundAST(AbstractProcessingQueue.java:245) at org.eclipse.edt.ide.core.internal.builder.AbstractProcessingQueue.processCompiledPart(AbstractProcessingQueue.java:221) at org.eclipse.edt.ide.core.internal.builder.AbstractProcessingQueue.level03Compile(AbstractProcessingQueue.java:164) at org.eclipse.edt.compiler.internal.core.builder.AbstractProcessingQueue.process(AbstractProcessingQueue.java:169) ... 17 more
Paul, please review the stack trace in comment 8. When that issue is resolved, you can assign this back to me.
Paul needs to review the stack trace, and I don't believe that this is a regression. Deferring to I3.
Created attachment 211429 [details] Patch for builder problems when creating IRs I have found the problem that was causing the exception to be thrown. I am attaching a patch that contains this fix. Additionally, I put in some code that will catch this type of runtime exception and update the .log file with the stack trace and put an error on the part that was being processed when the exception was thrown. This change will enable the builder to continue running after an unexpected event happens when computing the IR. This will hopefully prevent the kind of confusing occurrance that prompted this bug. Justin and Brian please review the patch and let me know if you think this could cause problems in the ide/sdk compilers. A simlar try/catch is used when validating a part. This is also used when binding a part, but the exception is propagated if the part is not fully bound (this is probabably because it could cause a build loop if the builder continues to run).
The patch looks ok to me. Will, once the patch is committed, go ahead and run your test case again and see if the results look better.
I have committed the patch. See patch for changed files
