Allow qualified metadata references in the Update item operation

[cdmihai]

Resolves #1655411 , #1649689

This allows users to import and map metadata between two or more item types.

• Example:

   <I Update="@(Foo);*.cs;@(Bar)" M1="%(Foo.M1)" M2="%(Bar.X2)">
      <M3 Condition="'%(Foo.M3)'' == 'something' ">%(M1)</M3>
   </I>

• Each matching item (i.e. each item that needs uptading) now carries a context of captured item instances from all matching referenced item types in the Update expression.
• Unqualified metadata (%(M)) binds to the operation item type (i.e. type that gets updated). Qualified metadata (%(Foo.M)) binds inside the set of captured item types from the Update expression.
• If an item matches multiple times within and between multiple referenced items:
  • The last occurrence from each containing item type gets captured (so one captured item per item type)
  • This matches the behaviour of task item batching under targets. If we ever unify batching between evaluation and target items, there will hopefully be no semantic conflicts with this new form of Update.
• Where one can put %() references:
  • Metadata
  • Metadata conditions
• Breaking changes

    <ItemGroup>
        <OldUpdateBehaviour Include="a" M1="1" M2="x"/>
        <Subset Include="a" M1="newM1"/>
        <OldUpdateBehaviour Update="@(Subset)" M1="%(Subset.M1)" M2="%(Subset.M1)"/>
    </ItemGroup>
    <Target Name="Build">
        <Message Importance="High" Text="@(OldUpdateBehaviour) : M1 = [%(M1)] M2 = [%(M2)]"/>
    </Target>

Today this outputs:
a : M1 = [] M2 = []
After the change it will output:
a : M1 = [newM1] M2 = [newM1]

TODO:

• investigate perf
• finish some of the code todos

[cdmihai]

FYI @jeffkl

[jeffkl]

Thanks @cdmihai! How does perf look so far?

/cc @cristinamanum

[cdmihai]

@jeffkl

How does perf look so far?

RPS passed, so I didn't (observably) regress anything.

I also measured (via msbuild.exe /profileEvaluation) a simulated scenario (500 PackageVersion includes, 10 PackageReference includes (which match the PackageVersion items evenly)). I compared a master release build to this branch, on release. All the syntax from this PR is valid in master msbuild too, it just resolves to empty strings. So the difference is literally just the overhead of this change.

• for one update, item evaluation went up from 130ms to 162ms
• for 1000 updates (simulating 1000 projects) item evaluation went up from 14106ms to 28216ms

I'll work on some obvious optimizations. Beyond that, we need to define what's good enough.

[cdmihai]

I made some optimizations to reduce the overhead.

• the 1000 updates scenario from above is now 300ms slower instead of twice as slow. At the existing 14 seconds, I think 300ms is acceptable
• I also ensured that total evaluation time for OrchardCore is unchanged. Prior to this optimization the new update made it 1 second slower (which makes me suspect RPS does not test any .net core scenarios)

[cdmihai]

@rainersigwald this probably warrants a mention in the docs, right?

[rainersigwald]

This definitely deserves a mention in the docs. Can you draft a PR for that too? I think it'll help contextualize the change.

[rainersigwald]

@cristinamanum fyi, this went in. It should be available in VS soonish.