Import: Don't walk non-F# assemblies when labelling trait constraint sources - #20090
Open
auduchinok wants to merge 2 commits into
Open
Import: Don't walk non-F# assemblies when labelling trait constraint sources#20090auduchinok wants to merge 2 commits into
auduchinok wants to merge 2 commits into
Conversation
This was referenced Jul 28, 2026
T-Gro
approved these changes
Aug 3, 2026
T-Gro
left a comment
Member
There was a problem hiding this comment.
🤖 AI review (@expert-reviewer): no significant issues found. Please verify independently.
Reviewed the change to addConstraintSources in CompilerImports.fs. The fix is correct and well-scoped:
- The guard
ia.FSharpViewOfMetadata.IsFSharpis cheap —IsFSharpis a plainboolfield onCcuData(TypedTree.fs:5854), so reading it does not forceDerefto materialize the namespace tree, which is the whole point of the optimization. - The inner
addConstraintSourcesis a non-recursiveletthat shadows and wraps the outer function;addConstraintSources iain its body correctly refers to the outer definition. This is subtle but works as intended. - The guard is semantically sound: only F# assemblies produce
TyparConstraint.MayResolveMemberconstraints to label, so skipping IL-only assemblies cannot change diagnostic output. FSharp.Core and F# references (IsFSharp = true) are still walked, so error messages are unchanged.
No correctness, security, or error-handling concerns.
T-Gro
self-requested a review
August 3, 2026 19:10
`addConstraintSources` (added in dotnet#16304, so that a failed member constraint names the member it came from) is applied to every imported assembly, and recurses through `e.ModuleOrNamespaceType` for every module and namespace entity it finds. For an assembly imported from IL there is nothing to find: the walk only reads `AllValsAndMembers`, and `ImportILTypeDefs` gives every namespace and type entity an empty val list; only an F# trait constraint produces a `TyparConstraint.MayResolveMember` to label in the first place. Meanwhile the recursion forces each namespace entity's `ModuleOrNamespaceType`, which imports that namespace - so referencing an assembly ends up importing every namespace in it, and reading every type definition, whether or not the code touches it. Skip the CCUs that aren't F#. FSharp.Core and F# references are still walked, so the error messages are unchanged. Measured with FSharpChecker.ParseAndCheckProject, keeping the results alive so the imported assembly structures stay on the heap (averages of 3 runs, one per process): a 486-reference F# project retains 1319.2 -> 952.1 MB (-27.8%), and a 168-reference console project 77.7 -> 69.8 MB (-10.2%). Checking FSharp.Compiler.Service itself (124 references, 397 sources) goes 2301.7 -> 2298.0 MB, i.e. within the noise at that size - what the imports cost there is dwarfed by the trees of the project's own code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
auduchinok
force-pushed
the
skip-constraint-sources-for-il-assemblies
branch
from
August 10, 2026 10:14
e991f3a to
4b348b5
Compare
Contributor
❗ Release notes requiredYou can open this PR in browser to add release notes: open in github.dev
|
Member
Author
|
This is ready. |
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
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.
Prevents eager reading of all types in referenced non-F# assemblies, saving memory on projects with many references.
AI-generated summary:
addConstraintSources(added in #16304, so that a failed member constraint names the member it came from) is applied to every imported assembly, and recurses throughe.ModuleOrNamespaceTypefor every module and namespace entity it finds.For an assembly imported from IL there is nothing to find: the walk only reads
AllValsAndMembers, andImportILTypeDefsgives every namespace and type entity an empty val list; only an F# trait constraint produces aTyparConstraint.MayResolveMemberto label in the first place. Meanwhile the recursion forces each namespace entity'sModuleOrNamespaceType, which imports that namespace - so referencing an assembly ends up importing every namespace in it, and reading every type definition, whether or not the code touches it.Skip the CCUs that aren't F#. FSharp.Core and F# references are still walked, so the error messages are unchanged.
Measured with FSharpChecker.ParseAndCheckProject, keeping the results alive so the imported assembly structures stay on the heap (averages of 3 runs, one per process): a 486-reference F# project retains 1319.2 -> 952.1 MB (-27.8%), and a 168-reference console project 77.7 -> 69.8 MB (-10.2%). Checking FSharp.Compiler.Service itself (124 references, 397 sources) goes 2301.7 -> 2298.0 MB, i.e. within the noise at that size - what the imports cost there is dwarfed by the trees of the project's own code.