Open hartmair opened 4 months ago
We decided to not support this in the first iteration of inlining, since the source syntax of external methods is not always available (e.g. if it is part of another assembly). However, this could be improved and inlining could always happen if the source syntax is available.
I have tried to provide a PR for this, but struggle as PartialImplementationPart
is always null
. Furthermore, even having the PartialImplementationPart
would not be enough as Mapperly uses multi-statement bodies by default. Do you have any guidance how to get around this?
Failing Unit-Test:
namespace Riok.Mapperly.Tests.Mapping;
public class QueryableProjectionExternalTest
{
[Fact]
public Task UseStaticMapperInlinedExpression()
{
var source = TestSourceBuilder.CSharp(
$$"""
using System;
using System.Linq;
using System.Collections.Generic;
using Riok.Mapperly.Abstractions;
using Riok.Mapperly.Abstractions.ReferenceHandling;
[Mapper]
[UseStaticMapper(typeof(OtherMapper))]
public partial class Mapper
{
private partial IQueryable<B> Map(IQueryable<A> source);
}
[Mapper]
static partial class OtherMapper
{
public static partial D MapToD(C v);
}
class A { public string StringValue { get; set; } public C NestedValue { get; set; } }
class B { public string StringValue { get; set; } public D NestedValue { get; set; } }
class C { public string Value { get; set; } }
class D { public string Value { get; set; } }
"""
);
return TestHelper.VerifyGenerator(source);
}
}
P.S. While debugging Mapperly #1422 happened as a side-effect.
Thanks for your efforts!
PartialImplementationPart
is probably null
because it is compiled in another assembly / compilation reference or it is another Mapperly generated method body (which is not yet available in the current compilation as it's only being generated) and therefore not visible to the current compilation. This is where it gets complicated and this is also the reason why we didn't implement it in the first place. For some cases it may work with https://github.com/riok/mapperly/pull/1418 (compilation references)...
One approach for Mapperly generated methods in the same assembly would be to re-generate the body based on the configuration and inline it directly (this could be explored, not sure how complex this would be...). Other than that I can't really think of a reasonable approach to implement this. But maybe someone out there has a brilliant idea on how to implement this, would be very interested in alternative approaches 😊
Is your feature request related to a problem? Please describe. When having mappings defined in different classes/files, I get RMG068: Cannot inline user implemented queryable expression mapping. In contrast, when I move the two mapper definitions into one class, the mapping gets propertly inlined.
Describe the solution you'd like A clear and concise description of what you want to happen including a proposal on the API surface and the matching generated code.
Describe alternatives you've considered Copying all dependend configurations into one class works as ugly workaround.
Additional context Mapperly v3.6.0