manifold-systems / manifold

Manifold is a Java compiler plugin, its features include Metaprogramming, Properties, Extension Methods, Operator Overloading, Templates, a Preprocessor, and more.
http://manifold.systems/
Apache License 2.0
2.43k stars 125 forks source link

[BUG] Unexpected behavior around generic types in extension method's `@This` parameter #498

Closed CC007 closed 1 year ago

CC007 commented 1 year ago

Describe the bug Wrong method is attempted to get called, due to generics being ignored in an extension method.

To Reproduce Steps to reproduce the behavior:

  1. Create streamIndexed and filterIndexed extension method in the IterableExt class (see screenshot)
  2. Create map extension method with @This Stream<Indexed<T>> and IndexedFunction<T, R> parameter in StreamExt (see last screenshot)
  3. Use the map extension method (see first screenshot)

Expected behavior The ability to use the extension method without error, The method I'm expecting to call is Stream<R> map(IndexedFunction<Boolean, R> mapper), rather than Stream<R> map(IndexedFunction<Indexed<Boolean>, R> mapper)

Screenshots afbeelding afbeelding afbeelding afbeelding afbeelding afbeelding

Desktop (please complete the following information):

Additional context Indexed<T> is defined like this: afbeelding

Workaround As a workaround, I can define a Function<Indexed<T>,R> rather than an IndexedFunction<T, R> and call the normal Stream.map(...) method instead of my extension method, however it would be nice if the extension method worked too.

CC007 commented 1 year ago

To make sure that this wasn't an issue with overloading the existing Stream.map(Function<T, R> mapper) method, I renamed the extension method (for instance to mapIt(...). The issue still persisted.

rsmckinney commented 1 year ago

@CC007 this is a known issue. I should carve some time out and implement this, relatively simple to implement.

Duplicate of https://github.com/manifold-systems/manifold/issues/7

CC007 commented 1 year ago

I also noticed that I have to use the same generic type name as was used in the original class definition (so T for Iterable and E for Set), otherwise I'd get a compilation error. Does that also have to do with #7?