Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 340611 - [xbase] [compiler] problem deriving return type when void involved
Summary: [xbase] [compiler] problem deriving return type when void involved
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.0.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: M7   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-21 17:47 EDT by Knut Wannheden CLA
Modified: 2017-09-19 17:44 EDT (History)
2 users (show)

See Also:
sven.efftinge: indigo+

Attachments
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 Knut Wannheden CLA 2011-03-21 17:47:11 EDT 
The following Xtend2 example produces invalid Java:

class Test {
	dispatch foo (String o) {
		o
	}
	dispatch foo (Object o) {
		null
	}
}

The following is generated:

  public String _foo(final String o) {
    return o;
  }
  
  public Void _foo(final Object o) {
    return null;
  }
  
  public String foo(final Object o) {
    if ((o instanceof String)) {
      return _foo((String)o);
    } else if ((o instanceof Object)) {
      return _foo((Object)o); // COMPILE ERROR
    } else {
      throw new IllegalArgumentException();
    }
  }

Now there is a compile error with the following message: "Type mismatch: cannot convert from Void to String".

I think the return type of the dispatch method should be Object or Comparable<? extends Object>.

A related use case with basically the same error:

class Test {
	dispatch foo (String o) {
		o
	}
	dispatch foo (Void o) {
		o
	}
}
Comment 1 Sven Efftinge CLA 2011-03-21 21:56:26 EDT 
I think it should generate:

public String foo(final Object o) {
    if ((o instanceof String)) {
      return _foo((String)o);
    } else if ((o instanceof Object)) {
      _foo((Object)o);
      return null;
    } else {
      throw new IllegalArgumentException();
    }
  }
Comment 2 Sebastian Zarnekow CLA 2011-03-22 03:42:07 EDT 
I'd prefer it to infer return type String for the dispatch methods. Otherwise it would be rather impossible for subtypes to provide another implementation for foo(Object).
Comment 3 Knut Wannheden CLA 2011-03-22 10:58:19 EDT 
I agree. So should possibly all the generated _foo() methods also have String as return type?
Comment 4 Sven Efftinge CLA 2011-03-22 21:22:14 EDT 
That makes sense.
Comment 5 Sven Efftinge CLA 2011-03-25 10:03:28 EDT 
(In reply to comment #3)
> I agree. So should possibly all the generated _foo() methods also have String
> as return type?

Dispatch methods from super types or explicitly declared return types shouldn't be changed.
Comment 6 Sebastian Zarnekow CLA 2011-04-04 11:12:25 EDT 
Pushed to master.
Comment 7 Karsten Thoms CLA 2017-09-19 17:32:49 EDT 
Closing all bugs that were set to RESOLVED before Neon.0
Comment 8 Karsten Thoms CLA 2017-09-19 17:44:01 EDT 
Closing all bugs that were set to RESOLVED before Neon.0