Bug 567801 - Lambda expression evaluation failed due to unexpected argument types
Summary: Lambda expression evaluation failed due to unexpected argument types
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 4.18   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 4.19 M3   Edit
Assignee: Gayan Perera CLA
QA Contact:
URL:
Whiteboard:
Keywords: regression
Depends on: 570793 571271
Blocks: 571213
  Show dependency tree
 
Reported: 2020-10-12 05:09 EDT by Martin Coufal CLA
Modified: 2021-02-18 02:17 EST (History)
7 users (show)

See Also:


Attachments
TestClass.java (340 bytes, text/x-java)
2020-10-12 05:09 EDT, Martin Coufal CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Coufal CLA 2020-10-12 05:09:12 EDT
Created attachment 284425 [details]
TestClass.java

Expression 'lotteryNumbers.stream().anyMatch(a -> a >= 42)' used with enclosed code example used to evaluate without any errors, but now I get an error:

'The operator >= is undefined for the argument type(s) Object, int'

How to reproduce:
1) have a clean Eclipse
2) create new Java project with a new class (see attachment TestClass.java)
3) set up breakpoint on the last line of the for loop
4) debug as Java application
5) open Expressions view
6) add new expression 'lotteryNumbers.stream().anyMatch(a -> a >= 42)'

My Configuration:
Eclipse Platform I20201010-1800
org.eclipse.jdt.feature.group 3.18.600.v20201010-1800

Note: the evaluation works fine with JDT 3.18.500.v20200902-1800.
Comment 1 Vaclav Kadlcik CLA 2021-01-29 08:29:05 EST
Adding Alex and Mat to CC. I somehow missed this regression and didn't raise it in time. It went all the way down to the 4.18 release :-(

FTR, it was a new feature brought in by 4.15: https://www.eclipse.org/eclipse/news/4.15/jdt.php#functional-expressions-in-debug
Comment 2 Andrey Loskutov CLA 2021-01-29 08:49:49 EST
(In reply to Vaclav Kadlcik from comment #1)
> Adding Alex and Mat to CC. I somehow missed this regression and didn't raise
> it in time. It went all the way down to the 4.18 release :-(

Do you mean, it is a regression in 4.18, and 4.17 is OK?

(In reply to Martin Coufal from comment #0)
> Note: the evaluation works fine with JDT 3.18.500.v20200902-1800.

Not sure which release that is, could you please say which *Eclipse* version is good / broken for you?
Comment 3 Vaclav Kadlcik CLA 2021-01-29 10:49:10 EST
(In reply to Andrey Loskutov from comment #2)
> (In reply to Vaclav Kadlcik from comment #1)
> > Adding Alex and Mat to CC. I somehow missed this regression and didn't raise
> > it in time. It went all the way down to the 4.18 release :-(
> 
> Do you mean, it is a regression in 4.18, and 4.17 is OK?

Yes, I mean exactly this

> (In reply to Martin Coufal from comment #0)
> > Note: the evaluation works fine with JDT 3.18.500.v20200902-1800.
> 
> Not sure which release that is, could you please say which *Eclipse* version
> is good / broken for you?

Martin is off so I try to answer for him. He followed development builds of Eclipse 4.18 (Platform, JDT and other components as well) and found this regression. In the report he mentioned where exactly it appeared: between  

 * Eclipse Platform 4.18 build I20201010-1800 with org.eclipse.jdt.feature.group 3.18.500.v20200902-1800

and

 * Eclipse Platform 4.18 build I20201010-1800 with org.eclipse.jdt.feature.group 3.18.600.v20201010-1800

(Is the number "3.18" in these JDT's feature versions what's confusing here? They don't follow Eclipse's version but that's true for many features and plugins...)
Comment 4 Gayan Perera CLA 2021-01-29 11:30:04 EST
Can we have a stack trace of the issue which might help to trace down the problem. And may be a sample code which reproduce this.
Comment 5 Gayan Perera CLA 2021-01-29 11:31:53 EST
I spoke too soon. I think we have sample code. Sorry for my early comment
Comment 6 Andrey Loskutov CLA 2021-01-29 11:48:30 EST
(In reply to Vaclav Kadlcik from comment #3)
> Martin is off so I try to answer for him. He followed development builds of
> Eclipse 4.18 (Platform, JDT and other components as well) and found this
> regression. In the report he mentioned where exactly it appeared: between  
> 
>  * Eclipse Platform 4.18 build I20201010-1800 with
> org.eclipse.jdt.feature.group 3.18.500.v20200902-1800
> 
> and
> 
>  * Eclipse Platform 4.18 build I20201010-1800 with
> org.eclipse.jdt.feature.group 3.18.600.v20201010-1800
> 
> (Is the number "3.18" in these JDT's feature versions what's confusing here?
> They don't follow Eclipse's version but that's true for many features and
> plugins...)

If the SDK build I20201010-1800 is same, how he managed to have different JDT version installed? Was this some kind of in-place update of JDT?
Comment 7 Gayan Perera CLA 2021-01-29 16:11:23 EST
I can reproduce this in 4.19 I20210126-1800. I will dig in more in the weekend and see if this can be fixed. 

Seems like the variable for remote evaluation which is passed in doesn't carry the correct type information. Thats my assumption, since i have spend fair amount of time digging in for another bug while back.
Comment 8 Vaclav Kadlcik CLA 2021-01-29 23:52:05 EST
(In reply to Andrey Loskutov from comment #6)
...
> If the SDK build I20201010-1800 is same, how he managed to have different
> JDT version installed? Was this some kind of in-place update of JDT?

No one mentioned SDK. Only Platform. Platform doesn't have JDK.
Comment 9 Sarika Sinha CLA 2021-01-30 00:44:51 EST
(In reply to Vaclav Kadlcik from comment #8)
> (In reply to Andrey Loskutov from comment #6)
> ...
> > If the SDK build I20201010-1800 is same, how he managed to have different
> > JDT version installed? Was this some kind of in-place update of JDT?
> 
> No one mentioned SDK. Only Platform. Platform doesn't have JDK.

From where did you take the Platform build which does not have JDT?
Comment 10 Vaclav Kadlcik CLA 2021-01-30 00:53:06 EST
(In reply to Sarika Sinha from comment #9)
...
> From where did you take the Platform build which does not have JDT?

From the respective build download page.
Look at e.g.:
  https://download.eclipse.org/eclipse/downloads/drops4/I20210129-1800/
You can see both the SDK and Platform tarballs.
Comment 11 Gayan Perera CLA 2021-01-30 06:04:43 EST
I think the problem might be due the generated snippet which is

  static void ___run(  java.lang.String[] args,  java.util.List lotteryNumbers) throws Throwable {
    return lotteryNumbers.stream().anyMatch(a -> a >= 10);
  }

As you can see the List doesn't have correct type arguments. So basically when evaluating the expression "lotteryNumbers.stream().anyMatch(a -> a >= 10)" the variable "a" becomes an Object type variable which result in the compilation problem in the CompilationUnit
Comment 12 Gayan Perera CLA 2021-01-30 10:06:26 EST
This is a regression issue from Bug560392. I will try to push a patch ASAP.
Comment 13 Gayan Perera CLA 2021-01-30 10:14:00 EST
It seems the problem has raised with the fix we gave to https://bugs.eclipse.org/bugs/show_bug.cgi?id=564801
Comment 14 Gayan Perera CLA 2021-01-30 10:25:39 EST
I see the problem now. Before removing type arguments we should check if the signature represents a proper Type or a generic type parameter. I’m really embarrassed right now because I didn’t see this aspect when i fixed the issue.
Comment 15 Eclipse Genie CLA 2021-01-31 15:11:11 EST
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/175555
Comment 17 Sarika Sinha CLA 2021-02-03 08:10:08 EST
Thanks Gayan!
Comment 18 Martin Coufal CLA 2021-02-12 04:10:39 EST
Verified on:
Eclipse Platform 4.19 (I20210210-1800)
org.eclipse.jdt.feature.group 3.18.700.v20210210-1909

Thanks!