dotnet / dotnet/android

Add generator output unit tests for trimmable typemap (attribute-shape verification)

Open
#11,140 0 comments 0 reactions 0 assignees View on GitHub
Area: Unit Tests enhancement needs-triage trimmable-type-map
Dominant language
C#
Stars
2.1k
Forks
579
Avg merge
1d 19h
Merged PRs (30d)
252

Description

## Problem

The CoreCLRTrimmable lane failure investigated in PR #11091 had a single root cause: the trimmable typemap source generator emitted proxy classes that were missing the self-application `[JavaPeerProxy]` attribute needed for AOT-safe instantiation via `proxyType.GetCustomAttribute()`.

This bug shipped because `tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests/` verifies **generator inputs and high-level structure** but does not verify that each emitted proxy type has the attribute shape runtime lookup depends on. The bug would have been caught instantly by a test like "for every emitted proxy type, `Type.GetCustomAttribute()` returns an instance pointing at that same type."

## Proposal

Extend `tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests/` with attribute-shape verification:

1. **Self-application attribute test:** For every generated `JavaPeerProxy`-derived type, assert:
- `type.GetCustomAttribute (inherit: false)` is non-null.
- The attribute's `TargetType` equals the type itself (or the expected target).
- `JniName` matches the expected JNI name for the bound Java type.

2. **Generated-vs-expected attribute matrix:** For a curated set of inputs (`Java.Lang.Object`, `Android.Widget.Button`, an interface with invoker, a managed-only subclass, a desugar-annotated type), snapshot the expected attribute set on the generated proxy and assert it matches.

3. **Compile-and-load verification:** Actually emit the generator output, compile the resulting `.dll`, load it, enumerate `JavaPeerProxy`-derived types, and run the above assertions on the loaded metadata (not just the source text).

## Acceptance criteria

- [ ] Tests exist in `tests/Microsoft.Android.Sdk.TrimmableTypeMap.Tests/` that would have failed against the generator state that caused PR #11091's CoreCLRTrimmable failures.
- [ ] Tests run as part of the standard `dotnet test` flow (already wired into CI).
- [ ] Coverage includes at least: concrete class, interface with invoker, abstract class, managed-only subclass, `Desugar`-prefixed type.

## Discovered during

PR #11091 — the CoreCLRTrimmable lane was failing because generated proxies lacked self-application `[JavaPeerProxy]` attributes. The generator source *looked* correct; the bug was only visible by decompiling the emitted `.dll`.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.