Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 358721

Summary:	[xtend2] null-safe feature call creates illegal java
Product:	[Modeling] TMF	Reporter:	Stephan Herrmann <stephan.herrmann>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	sebastian.zarnekow
Version:	2.0.0	Flags:	sebastian.zarnekow: indigo+
Target Milestone:	SR2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Stephan Herrmann

2011-09-23 09:45:46 EDT

Recently I tried the nice concept of null-safe feature calls:

  o?.f

The Xtend2 validator seemed content, but then the Java compiler complained
about this (quoted from memory):

  (o == null ? (boolean)null : o.getF())

Maybe this should be detected a bit earlier in the pipeline?
:)

Comment 1 Sebastian Zarnekow

2011-09-23 10:13:13 EDT

I assume the expression o?.f was used in a context where a boolean was expected?

Comment 2 Stephan Herrmann

2011-09-26 08:35:57 EDT

(In reply to comment #1)
> I assume the expression o?.f was used in a context where a boolean was
> expected?

I don't remember the exact situation, but yes, "if (o?.f)" is a good way
to reproduce.

BTW: in comment 0 I spoke of detecting an error earlier in the pipeline,
but now I wonder whether it shouldn't actually be supported?

  if (o?.f)
is just much more convenient than the omnipresent
  if (o != null && o.f)

I think it would be obvious, that o == null renders the whole expression 
false, no?

I realize that this would require special handling of boolean, because
the same pattern wouldn't be equally obvious for other basic types.
E.g., what's the valua of o?.c if the expected type is char and o == null?
Doesn't make much sense probably.

Comment 3 Sebastian Zarnekow

2011-09-28 11:41:00 EDT

This one was already fixed.

Comment 4 Stephan Herrmann

2011-09-29 14:11:33 EDT

(In reply to comment #3)
> This one was already fixed.

Great.
Fixed as in "error is now reported" or as in "creates valid code now"?

On a similar note just the other day I saw code produced by the
xtend2 compiler that looked something like:

   if (new Integer(val) == null)

(again quoted from memory but I hope you get the idea).

Not quite as bad, but why bother to compile (and test) code that's
so obviously wrong?

I know basic types in Java are a pita but your users will thank you
if you catch more bogus programs and report what's wrong.

Comment 5 Sebastian Zarnekow

2011-09-29 14:42:08 EDT

(In reply to comment #4)
> (In reply to comment #3)
> > This one was already fixed.
> 
> Great.
> Fixed as in "error is now reported" or as in "creates valid code now"?

Fixed as in "creates valid code now".

> On a similar note just the other day I saw code produced by the
> xtend2 compiler that looked something like:
> 
>    if (new Integer(val) == null)
> 
> (again quoted from memory but I hope you get the idea).
> 
> Not quite as bad, but why bother to compile (and test) code that's
> so obviously wrong?
> 
> I know basic types in Java are a pita but your users will thank you
> if you catch more bogus programs and report what's wrong.

Equalitiy is checked by means of ObjectExtensions.operator_equals by default but clients are allowed to provide other implemenations. Currently we don't have concrete plans to allow for optimizated compiler strategies for such extension methods.

Comment 6 Karsten Thoms

2017-09-19 17:13:11 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 7 Karsten Thoms

2017-09-19 17:24:41 EDT

Closing all bugs that were set to RESOLVED before Neon.0