ILLink: dataflow doesn't track killed hoisted locals

Open
#117,155 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
csharp
Domain
tooling

Research direction

Start with ILLink's hoisted-local dataflow handling and compare it with the Roslyn analyzer behavior described in the issue, including the referenced design commit. Done means an overwritten hoisted local is treated like other locals, so later reads see the latest definition rather than merged earlier writes, and the behavior no longer differs between the tools.

Written by the indexing model from the issue text.

Description

area-Tools-ILLink

ILLink analyzes hoisted locals by inspecting all writes to a local, and using the merged value as the virtual "annotation" for the compiler-generated field. This produces dataflow warnings for any reads with conflicting requirements:

// Trimmer tracks all assignments of hoisted locals, so this produces warnings.
[ExpectedWarning("IL2072", nameof(GetWithPublicMethods), nameof(DataFlowTypeExtensions.RequiresPublicFields), Tool.Trimmer | Tool.NativeAot, "", CompilerGeneratedCode = true)]
[ExpectedWarning("IL2072", [nameof(GetWithPublicFields), nameof(DataFlowTypeExtensions.RequiresPublicMethods)], Tool.Trimmer | Tool.NativeAot, "", CompilerGeneratedCode = true)]
static IEnumerable<int> NoFlowAcrossYieldReturn()
{
    Type t = GetWithPublicMethods();
    t.RequiresPublicMethods();
    yield return 0;
    t = GetWithPublicFields();
    t.RequiresPublicFields();
}

The Roslyn analyzer treats these like other locals and tracks the overwriting definition, so that a later read only sees the latest definition.

This was by design in https://github.com/dotnet/linker/commit/bc46e445deb1411cc597019d693ddc5b4e5e24f4, but leads to a difference in behavior between the tools.

Dominant language
C#
Stars
18.3k
Forks
5.6k
PR metrics pending

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/runtime

All issues in dotnet/runtime

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.