Bug 576829 - Conditional breakpoints fail when recursive generics are involved
Summary: Conditional breakpoints fail when recursive generics are involved
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 4.21   Edit
Hardware: PC Windows 10
: P3 normal with 1 vote (vote)
Target Milestone: 4.22 M3   Edit
Assignee: Gayan Perera CLA
QA Contact:
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: 572782
  Show dependency tree
 
Reported: 2021-10-21 19:21 EDT by Katrin Straßl CLA
Modified: 2021-11-10 12:55 EST (History)
2 users (show)

See Also:

Attachments
example project (2.19 KB, application/x-zip-compressed)
2021-10-21 19:21 EDT, Katrin Straßl CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Straßl CLA 2021-10-21 19:21:09 EDT 
Created attachment 287375 [details]
example project

When evaluating a conditional breakpoint that involves an object that itself uses recursive generics, eclipse cannot evaluate the breakpoint and reports that the condition has compilation errors.

Here is an example code (a project is attached):

public class Main {

	public static void main(String[] args) {
		MyClass<?> cls = new MyClass<>();
		System.out.println("x"); // add conditional breakpoint here (e.g. "cls.getBoolean()")
	}
	
	private static class MyClass<T extends MyClass<T>> {
		
		public boolean getBoolean() {
			return false;
		}
	}
}

Notice the recursive generic parameter of class MyClass. A conditional breakpoint like the one stated in the comment fails during debugging with the following error message:

"Conditional breakpoint has compilation error(s). 

Reason:
Evaluations must contain either an expression or a block of well-formed statements"

The error log further contains the following warning:
"Compile error during code evaluation: Bound mismatch: The type Object is not a valid substitute for the bounded parameter <T extends Main.MyClass<T>> of the type Main.MyClass<T>"

No stack trace is available.

Conditional breakpoints worked in situations like above at least until eclipse 4.15.
Comment 1 Sarika Sinha CLA 2021-10-27 11:17:21 EDT 
Thanks Katrin for reporting.

@Gayan,
Can you look at this as this looks like a regression from the fix of Bug 572782.
Comment 2 Gayan Perera CLA 2021-10-27 12:31:25 EDT 
Sure i can have a look for M3. Is that ok ?
Comment 3 Sarika Sinha CLA 2021-10-27 13:54:04 EDT 
(In reply to Gayan Perera from comment #2)
> Sure i can have a look for M3. Is that ok ?

Yes! 
Thanks.
Comment 4 Gayan Perera CLA 2021-10-27 14:34:48 EDT 
Its not really same as previous bug, not sure if it was cause by that given the changes, the problem seems to be the parameters on the eval method doesn't carry the correct generic signature.

The variable type in CU is MyClass<?>, but the variable type extracted from the Debug Frame is MyClass<Object>.

I have a solution to replace the correct this variable types while traversing the CU on snippet source generator. I need to test more for different scenarios where we could find shadowing variables and how that will effect the logic.

Will try to push the patch by end of this week.
Comment 5 Eclipse Genie CLA 2021-10-28 13:57:48 EDT 
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/187132
Comment 7 Sarika Sinha CLA 2021-11-01 15:09:32 EDT 
Thanks Gayan for quickly fixing this.
Comment 8 Sebastian Zarnekow CLA 2021-11-02 08:12:58 EDT 
Does the solution work for more than one type parameter?

static class MyClass<C1 extends MyClass<C1, C2>, C2 extends MyClass<C1, C2>> {}
MyClass<?, ?> cls = new MyClass<>();

Or with doubly-nested recursive type args

class MyClass<C extends MyClass<? extends MyClass<C>>> {}
Comment 9 Eclipse Genie CLA 2021-11-02 13:35:43 EDT 
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.debug/+/187240
Comment 11 Sarika Sinha CLA 2021-11-10 12:55:55 EST 
I20211109-1800