Bug 267561 - [evaluation] LocalEvaluationEngine does not accept primitive types
Summary: [evaluation] LocalEvaluationEngine does not accept primitive types
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4.1   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: 3.6 M3   Edit
Assignee: Ayushman Jain CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-08 19:50 EDT by Nikola Mihajloviæ CLA
Modified: 2011-01-25 11:05 EST (History)
3 users (show)

See Also:


Attachments
Same as DisplayAction but uses LocalEE (4.96 KB, text/plain)
2009-03-08 19:51 EDT, Nikola Mihajloviæ CLA
no flags Details
patch (2.17 KB, patch)
2009-09-18 14:18 EDT, Darin Wright CLA
no flags Details | Diff
alternative fix (1.28 KB, patch)
2009-09-18 14:31 EDT, Ayushman Jain CLA
no flags Details | Diff
plugin project to reproduce bug (9.84 KB, application/zip)
2009-09-22 12:16 EDT, Ayushman Jain CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikola Mihajloviæ CLA 2009-03-08 19:50:09 EDT
Build ID: M20080911-1700

LocalEvaluationEngine reports an error when a stack frame contains local variables of primitive types. The error message is: "<primitive type> cannot be resolved to a type". It is reported to the LocalEvaluationEngine through the acceptProblem method. 

I have attached a class which can be used to reproduce the problem. It is an action to be contributed to the DisplayView. It does the same thing as DisplayAction (actually it extends it), but it uses LocalEvaluationEngine instead of AST EE (Yes, I know it's missing engine.dispose() but I don't have time to fix it)

Now, everything works normally except when performing an evaluation against the stack frame which contains the described local variables.
Comment 1 Nikola Mihajloviæ CLA 2009-03-08 19:51:06 EDT
Created attachment 127974 [details]
Same as DisplayAction but uses LocalEE
Comment 2 Darin Wright CLA 2009-03-09 12:09:47 EDT
The issue appears to be with the implementation of IEvaluationContext on jdt.core. It is not accepting "int" or "I" as a type name. Jerome, what should be used to specify primitive type names when using this API on IEvaluationContext?

evaluateCodeSnippet(String, String[], String[], int[], IType, boolean, boolean, ICodeSnippetRequestor, IProgressMonitor)
Comment 3 Jerome Lanneluc CLA 2009-03-19 09:45:33 EDT
In theory, "int" should work. However looking at the code, it appears that it tries to resolve it as a regular type name. I think this bug should be moved to JDT/Core.
Comment 4 Darin Wright CLA 2009-03-19 09:51:34 EDT
Thanks Jerome. Moving to JCore.
Comment 5 Olivier Thomann CLA 2009-08-25 21:26:43 EDT
Ayushman, please investigate.
Comment 6 Darin Wright CLA 2009-09-18 14:18:08 EDT
Created attachment 147587 [details]
patch

This was blocking progress on bug 289798 (just an experiment), but I did come up with the this patch that solved my problem. Needs some JCore eyes.
Comment 7 Ayushman Jain CLA 2009-09-18 14:31:33 EDT
Created attachment 147588 [details]
alternative fix

@Darin

What do you think of this one. The problem is simply that even primitives are being wrapped into a QualifiedTypeReference- which causes a problem at the time of resolution of bindings. So all we need to do is wrap primitives into SingleTypeReference.
Comment 8 Darin Wright CLA 2009-09-18 14:41:11 EDT
Looks fine - I just didn't konw enough about the compiler to know if a SingleTypeReference applies to all types names without a '.', or just primitive type names.
Comment 9 Olivier Thomann CLA 2009-09-18 14:53:05 EDT
Darin, do you need the fix today ?
Ayushman, I would like a regression test to be available.

I tried to reproduce the pb on my side. I tried to define a scrapbook page, but I keep getting problem about the class file version being not supported.
Comment 10 Darin Wright CLA 2009-09-18 15:00:05 EDT
(In reply to comment #9)
> Darin, do you need the fix today ?

No rush, I don't need a fix today. I can run with the patch in HEAD. I'm just experimenting with using JDT's evaluation context for non-scrapbook evaluations.
Comment 11 Olivier Thomann CLA 2009-09-22 11:34:09 EDT
Released for 3.6M3.
Ayushman, please provide the steps you used to reproduce the issue.
Comment 12 Ayushman Jain CLA 2009-09-22 12:16:28 EDT
Created attachment 147794 [details]
plugin project to reproduce bug

Here's the plugin project that was used to reproduce the issue. The verifier can use this to comfirm that the bug is no longer reproduced. The plugin contributes an action to the extension point org.eclipse.ui.editorActions.

Steps to reproduce:
1) Import the project into your workspace.
2) Check out org.eclipse.jdt.debug.ui into the workspace
3) Make sure the errors/warnings setting for forbidden reference(access rules)/discouraged reference(access rules) is set to either warn or ignore.
4) Run as eclipse application. Open the display view. Right clicking on the display view will show a new action "My Own Action"(although inactive).
5) Create a sample program, and put a breakpoint after some local declarations and assignment statements containing primitive types. Debug your code, and when the breakpoint is hit, type some expression in the display view. Selecting the expression and clicking on My Own Action should activate the evaluation which was earlier causing an exception. If everything is ok, you would now no longer get an exception.
Comment 13 Ayushman Jain CLA 2009-09-22 12:19:20 EDT
PS: Please mark out "patch" as obsolete.
Comment 14 Olivier Thomann CLA 2011-01-25 11:05:27 EST
Verified.