Conversation
…guments Previously, when decoding custom attribute blobs containing System.Type arguments, the type name string was parsed but then discarded, returning null for every Type argument. This fixes two TODO comments (lines 6751 and 6756 in the original) by: 1. Adding a 'resolveILType: ILType -> Type' parameter to decodeILCustomAttribData so callers can provide a type resolver. 2. Using ILTypeSigParser to parse the stored type name string into an ILType, then resolving it via the provided resolver. 3. Falling back to null gracefully if resolution fails (e.g. the type is not available in the target context). 4. Passing 'txILType ([||], [||])' at the call site so types are resolved via the existing target-assembly translation layer. This means that attributes like DebuggerTypeProxyAttribute, which pass a System.Type to their constructor, now decode correctly when read from binary assemblies via the target assembly reader. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2 tasks
dsyme
approved these changes
Apr 1, 2026
dsyme
pushed a commit
that referenced
this pull request
Apr 20, 2026
…ase 8.7.0 (#506) 🤖 *This is an automated pull request from Repo Assist.* ## Summary Adds `GenerativeCustomAttributeTests.fs` — 5 regression tests for custom attribute encoding in the generative IL writer. These cover attribute targets and argument types not previously exercised by the existing tests in `BasicGenerativeProvisionTests.fs` (which only tested attributes on *properties*). Also updates `RELEASE_NOTES.md` with a new `8.7.0` entry covering this and the previously-merged `GenerativeMethodsTests` (#505). ## New tests | Test | What it verifies | |------|-----------------| | `Custom attribute on a generative type round-trips correctly` | `ObsoleteAttribute(string, bool)` placed on the *type definition itself* | | `Custom attribute with bool constructor argument round-trips correctly` | `bool` values survive the ECMA-335 encode/decode path | | `Custom attribute with enum constructor argument round-trips correctly` | `DebuggerBrowsableAttribute(DebuggerBrowsableState.Never)` — enum arg decoded as underlying int | | `Multiple custom attributes on a single generative method are all preserved` | `defineCustomAttrs` writes **all** attributes, not just the first | | `Custom attribute on a generative method has correct string argument` | `DescriptionAttribute(string)` on an instance method | ## Root cause / motivation Several custom-attribute encoding bugs were fixed in earlier PRs (`#432`, `#490`, `#501`). This PR adds focused regression tests for the remaining un-covered paths: - attributes on **types** (not just members) - attributes on **methods** (not just properties) - **bool** and **enum** constructor argument encoding - multiple attributes on a single member ## Test Status ``` Passed! - Failed: 0, Passed: 147, Skipped: 0, Total: 147, Duration: 7 s ``` All 147 tests pass (142 pre-existing + 5 new). > Generated by 🌈 Repo Assist, see [workflow run](https://github.com/fsprojects/FSharp.TypeProviders.SDK/actions/runs/24617397828). [Learn more](https://github.com/githubnext/agentics/blob/main/docs/repo-assist.md). > > To install this [agentic workflow](https://github.com/githubnext/agentics/blob/97143ac59cb3a13ef2a77581f929f06719c7402a/workflows/repo-assist.md), run > ``` > gh aw add githubnext/agentics@97143ac > ``` <!-- gh-aw-agentic-workflow: Repo Assist, engine: copilot, model: auto, id: 24617397828, workflow_id: repo-assist, run: https://github.com/fsprojects/FSharp.TypeProviders.SDK/actions/runs/24617397828 --> <!-- gh-aw-workflow-id: repo-assist --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 This PR was created by Repo Assist, an automated AI assistant.
Summary
Fixes a long-standing TODO in
decodeILCustomAttribDatawhere custom attribute arguments of typeSystem.Typewere silently decoded asnullinstead of the actualTypeobject.Root Cause
In ECMA-335, custom attribute constructors store
System.Typearguments as serialised strings (the assembly-qualified type name) in the attribute blob — not asTypeRef/TypeDeftable indices. The existing code parsed the type name string correctly viaILTypeSigParser, but then discarded the result and returnednull:Fix
resolveILType: ILType -> Typeparameter todecodeILCustomAttribDataso the caller provides a type resolver.System.Typebranch now uses the parsedILTypeand resolves it via the provided resolver.nullif resolution fails (e.g. the type is not present in the target context).txCustomAttributesDatum, passestxILType ([||], [||])— the existing target-assembly type translator — as the resolver.Impact
Custom attributes like
DebuggerTypeProxyAttribute(constructor takesType) that are read from binary reference assemblies via the target assembly reader now return the correctTypevalue instead ofnull. This improves the accuracy ofGetCustomAttributesData()for target-context types.Test Status
✅ All 126 tests pass locally (
dotnet test tests/FSharp.TypeProviders.SDK.Tests.fsproj -c Release)A dedicated test for this specific path would require finding a reference assembly type with a
System.Typecustom attribute argument and verifying it resolves non-null — feasible but deferred to a follow-up as it requires navigating the target context fixture.