WIP: RFC FS-1043: Extension members participate in SRTP constraint resolution#19396
Draft
WIP: RFC FS-1043: Extension members participate in SRTP constraint resolution#19396
Conversation
- Add LanguageFeature.ExtensionConstraintSolutions mapped to preview version - Gate FS1215 (tcMemberOperatorDefinitionInExtrinsic) behind the feature flag - With --langversion:preview, extension operator definitions no longer warn - Add FSComp.txt entry and xlf translations for the feature description
…with traitCtxt field - Add ITraitAccessorDomain marker interface to TypedTree - Add ITraitContext interface with SelectExtensionMethods and AccessRights - Extend TTrait with 8th field: traitCtxt: ITraitContext option - Add TraitContext member and traitCtxtNone helper - Make AccessorDomain implement ITraitAccessorDomain - Update all TTrait pattern matches across the compiler (8 files) - Pickling: traitCtxt is not serialized; deserialized as None - No behavioral change: all trait contexts are None Sprint 2 of RFC FS-1043 (extension method SRTP resolution)
…functions - Add traitCtxt: ITraitContext option parameter to CopyTyparConstraints, FixupNewTypars, FreshenAndFixupTypars, FreshenTypeInst, FreshMethInst, FreshenMethInfo, FreshenTypars, CopyAndFixupTypars, FreshenPossibleForallTy, LightweightTcValForUsingInBuildMethodCall, FreshenTyconRef, FreshenTyconRef2, FreshenAbstractSlot, FreshenObjectArgType - CopyTyparConstraints stamps traitCtxt onto MayResolveMember constraints when the original has None - TcEnv implements ITraitContext with SelectExtensionMethods and AccessRights - Add SelectExtensionMethInfosForTrait to NameResolution.fs - Thread traitCtxtNone through all call sites (no behavioral change)
…l sites with TcEnv in scope - TTrait construction sites in TcPseudoMemberSpec and TcImplicitOpItemThen now use env.TraitContext instead of None - All 28 freshening call sites in CheckExpressions.fs use env.TraitContext (or envinner.TraitContext where the variable is named envinner) - CheckDeclarations.fs call sites use env/envForTycon/tcEnv.TraitContext - CheckExpressionsOps.fs CompilePatternForMatch uses env.TraitContext - CopyTyparConstraints traitCtxt propagation is no longer dead code
- GetRelevantMethodsForTrait: collect extension methods from trait context when ExtensionConstraintSolutions feature is enabled - SolveMemberConstraint: compute traitAD from trait context for accessibility - Use traitAD in CalledMeth, ResolveOverloading, TryFindIntrinsicNamedItemOfType - Use traitCtxt (not traitCtxtNone) in FreshenMethInfo calls - Built-in rules use intrinsicMinfos in match pattern; when clauses use full minfos so extension methods properly defer built-in resolution - traitsAEquiv already ignores traitCtxt field (verified)
… tests - Change typecheck to compileAndRun in 'Extension operator on string resolves with langversion preview' test to validate runtime behavior - Add test: FS1215 warning fires for extension operator without langversion preview - Add test: FS1215 warning does not fire with langversion preview Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ring optimization When FSharp.Core inline operators are expanded, the resulting trait calls have no ITraitContext (it's not serialized in metadata). This prevented extension methods defined in the current compilation unit from being found during optimization/codegen, causing Error 193 type mismatches. Changes: - ConstraintSolver: Add guard preventing built-in mul/div rule from firing for concrete non-numeric types when ExtensionConstraintSolutions is enabled - ConstraintSolver: Add CreateImplFileTraitContext that walks the expression tree bindings (not CcuThunk module type) to find extension member Val objects with correct stamps matching IlxGen's bound vals - Optimizer: Add traitCtxt field to cenv, supply fallback trait context in OptimizeTraitCall when trait's original context is None Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Test B5: Multiple extension operators with different signatures resolve correctly - Test B6: Intrinsic operator takes priority over extension with same name and signature Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add 5 new tests covering: - Extension operator resolves via SRTP alongside IWSAM types (B7) - Extension wins over IWSAM interface impl for same operator (B7) - Extension operator not visible without opening defining module (B9) - Inline SRTP resolves using consumer's scope for extensions (B9) - Internal record field resolves via SRTP within same compilation unit (B10) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Test 1: True optional extension on System.String (*) across assemblies. Documents that cross-assembly extension resolution fails (Error 193) because TTrait.traitCtxt deserializes as None from pickled metadata. - Test 2: Intrinsic augmentation Widget (+) across assemblies. Confirms intrinsic operators work cross-assembly (for contrast). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Remove three tests that were near-identical duplicates exercising the same 'define record + extension (+) + inline add' pattern: - 'Inline SRTP function uses extension method on custom type' (duplicate of 1910) - 'Extension operator resolves via SRTP alongside IWSAM types' (duplicate, misleading name) - 'Extension operator on custom type typechecks in separate module' (subset of Intrinsic method priority test) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add defensive type-test assertions replacing unsafe obj downcasts in CheckBasics.fs (InfoReader), ConstraintSolver.fs (AccessorDomain, MethInfo) - Hoist ExtensionConstraintSolutions feature flag check to local binding in SolveMemberConstraint and GetRelevantMethodsForTrait - Extract SelectExtMethInfosForType shared helper in NameResolution.fs and refactor SelectExtensionMethInfosForTrait to use it Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… resolution Define AllowOverloadOnReturnTypeAttribute in FSharp.Core and wire it into the compiler's overload resolution and uniqueness checking. When any applicable overload carries this attribute, the return type is considered during overload resolution, generalizing the existing op_Explicit/op_Implicit mechanism to arbitrary methods. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…eftover files Update FSharp.Core surface area baseline to include the new AllowOverloadOnReturnTypeAttribute type. Remove leftover code review artifact files that were accidentally committed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…InfosForType Extract SelectIndexedExtMethInfosForType helper for indexed-only extension member lookup. Refactor ExtensionMethInfosOfTypeInScope to use SelectExtMethInfosForType for the root type (both indexed and unindexed members) and SelectIndexedExtMethInfosForType for base types in the hierarchy (indexed only), removing the duplicated tryTcrefOfAppTy / eIndexedExtensionMembers.Find / SelectMethInfosFromExtMembers pattern. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…sForType Eliminate code duplication by having SelectExtMethInfosForType delegate its indexed lookup to SelectIndexedExtMethInfosForType instead of duplicating the tryTcrefOfAppTy/Find/SelectMethInfosFromExtMembers pattern. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ions Skip SRTP constraint canonicalization for inline bindings when the ExtensionConstraintSolutions feature is enabled (--langversion:preview). This implements RFC FS-1043 claim #6: weak resolution should not force inline code to collapse generic SRTP constraints to concrete types. Changes: - CheckExpressions.fs: Skip CanonicalizePartialInferenceProblem for inline bindings in TcLetBinding, TcObjectExprBinding, and TcIncrementalLetRecGeneralization when ExtensionConstraintSolutions is on. - IWSAMsAndSRTPsTests.fs: Add 6 tests covering inline DateTime generics, non-inline unaffected, backward compat with langversion 8.0, and built-in numeric operators. Non-inline code is completely unaffected. Gated behind langversion:preview. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Enhance CreateImplFileTraitContext to search referenced CCU module types for extension member Vals, not just local impl file bindings. This enables cross-assembly SRTP constraint resolution during optimization/codegen when extension operators are defined in a referenced assembly. Changes: - ConstraintSolver.CreateImplFileTraitContext: accept CcuThunk list, walk referenced CCU module types to collect extension members - Optimizer.IncrementalOptimizationEnv: add referencedCcus field populated by BindCcu - Optimizer.OptimizeImplFile: pass referencedCcus to CreateImplFileTraitContext - Tests: change cross-assembly test from shouldFail to compileAndRun/shouldSucceed, remove TODO comment, add transitive A→B→C test Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Remove Skip from 'AllowOverloadOnReturnType resolves overloads by return type' test now that AllowOverloadOnReturnTypeAttribute is available in FSharp.Core. Add test for ambiguity error when no type annotation is present. Add test for mixed attributed/non-attributed overloads. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add 4 tests covering SRTP weak resolution behavior with langversion preview: - FSharpPlus-style InvokeMap/InvokeApply pattern compiles with preview - Type annotation workaround for InvokeMap pattern compiles - Non-inline code canonicalization unaffected by ExtensionConstraintSolutions - Inline numeric operators with multiple overloads stay generic Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…nType assertions - Remove duplicate 'Non-inline DateTime addition still resolves concretely' test (identical to 'Non-inline code canonicalization is unaffected') - Fix 'AllowOverloadOnReturnType resolves overloads by return type' to assert shouldFail (attribute not yet functional for return-type disambiguation) - Fix 'AllowOverloadOnReturnType mixed' to assert shouldFail (attribute type not yet defined in FSharp.Core) All 227 IWSAM/SRTP tests pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add 4 tests covering instance extension methods with SRTP constraints: - Instance extension method resolves via SRTP - Instance extension method with parameter resolves via SRTP - Instance extension does not satisfy static SRTP constraint - Intrinsic instance method takes priority over instance extension Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replace 3 failwith calls with error(InternalError(...)) in ITraitContext downcast code paths to produce proper compiler diagnostics instead of opaque exceptions: - CheckBasics.fs: SelectExtensionMethods InfoReader cast - ConstraintSolver.fs: SolveMemberConstraint AccessorDomain cast - ConstraintSolver.fs: GetRelevantMethodsForTrait MethInfo cast Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add 4 new tests covering accessibility-domain scenarios for SRTP: - Internal type extension in same assembly resolves via SRTP - SRTP constraints from different accessibility domains flow together - Internal record field resolves via SRTP within same assembly - Cross-assembly internal extension is not visible via SRTP Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rename _collectionSettings back to collectionSettings and add early-exit check after rootResults to skip expensive type hierarchy lookup when only one result is needed (AtMostOneResult). This restores the perf optimization that was lost during RFC FS-1043 refactoring. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Document extension members for operators and SRTP constraints in preview release notes - Add SRTP guide covering extension constraints, priority rules, scope capture, weak resolution changes, and workarounds - Feature flag: ExtensionConstraintSolutions (--langversion:preview) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Remove false 'known limitation' about cross-assembly resolution from release notes and srtp-guide.md (cross-assembly resolution works) - Clarify AllowOverloadOnReturnType: attribute allows defining overloads, but full call-site disambiguation is not yet implemented - Add cross-assembly resolution as an explicit feature bullet in release notes - Fix stale test comment about AllowOverloadOnReturnType not being in FSharp.Core Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add AllowOverloadOnReturnTypeAttribute to all surface area baselines (debug ns2.0, debug ns2.1, release ns2.0 were missing the entry) - Add withErrorCode to all 7 shouldFail tests without error verification: - Extension operator not visible: error 1 - AllowOverloadOnReturnType overloads by return type: error 41 - Overloads without AllowOverloadOnReturnType: error 41 - AllowOverloadOnReturnType with no annotation: error 41 - Instance extension does not satisfy static SRTP: error 1 - Cross-assembly internal extension not visible: error 43 - Fix mixed overloads test: overloads with different param types (string vs int) resolve without ambiguity — changed to shouldSucceed - Remove AllowOverloadOnReturnType attribute from shouldFail tests since the attribute is not available in the test runtime's FSharp.Core - Parameterize DateTime addition/subtraction tests into a single Theory - Extract stringRepeatExtLib helper to eliminate duplicated string extension operator library definitions Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…nition - Merge 'AllowOverloadOnReturnType resolves overloads by return type' and 'Overloads without AllowOverloadOnReturnType produce ambiguity error' into single 'Overloads differing only by return type produce ambiguity error' test (identical source and assertions) - Extract stringRepeatExtDef [<Literal>] constant for inline string repeat extension definition, reducing 5 inline duplicates to 1 - Update stringRepeatExtLib to reuse stringRepeatExtDef Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
16 tasks
# Conflicts: # docs/release-notes/.Language/preview.md # global.json # src/Compiler/FSComp.txt # src/Compiler/Facilities/LanguageFeatures.fs # src/Compiler/Facilities/LanguageFeatures.fsi # src/Compiler/TypedTree/TcGlobals.fs # src/Compiler/TypedTree/TcGlobals.fsi # tests/FSharp.Compiler.ComponentTests/CompilerOptions/fsc/FscOptionTests.fs # tests/FSharp.Compiler.ComponentTests/CompilerOptions/fsc/misc/PublicSign.fs # tests/FSharp.Compiler.ComponentTests/Conformance/Types/TypeConstraints/IWSAMsAndSRTPs/IWSAMsAndSRTPsTests.fs # tests/projects/CompilerCompat/CompilerCompatApp/Program.fs # tests/projects/CompilerCompat/CompilerCompatLib/Library.fs # vsintegration/src/FSharp.Editor/Hints/FSharpInlayHintsService.fs
…augmentations Two user-reported bugs (gusty, PR #19396): 1. Array extension operator (++): type 'T [] with static member (++) crashes with 'BuildFSharpMethodCall: unexpected List.length mismatch' during optimization 2. Option extension operator (|>>): Option<'T> with static member (|>>) crashes with the same error Both crash in GenWitnessExpr -> BuildFSharpMethodCall during the optimizer's trait call resolution. The enclosing generic type's type parameters are not accounted for when constructing the method call. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…solution Root cause: BuildFSharpMethodCall double-counted enclosing type parameters for extension members. For extension members, AnalyzeTypeOfMemberVal treats ALL type parameters as 'method typars' (FormalMethodTypars returns all of them). The SRTP solver stores these in FSMethSln.minst. But BuildFSharpMethodCall also extracted enclosing type args via argsOfAppTy, causing a length mismatch crash. Additionally, for extension methods whose body introduces extra type parameters (e.g. Option.map introduces 'b), the fresh type variables for enclosing type params were never solved during trait matching — only method-body typars got constrained. This left unsolved typars in the expression tree, crashing IlxGen. Fix: For extension members, take enclosing type args from argsOfAppTy g ty (which are concrete), skip them in minst, and append the remaining method-specific args. This correctly maps all GeneralizedType parameters to concrete types. Why existing tests didn't catch this: All prior extension SRTP tests used custom types defined in the same compilation unit (intrinsic extensions where IsExtensionMember=false), or used types with matching type parameter counts. The user-reported cases used extrinsic extensions on BCL/FSharp.Core generic types (Array, Option) where the extension/augmentation distinction matters. Fixes: Extension operator (++) on 'T[] and (|>>) on Option<'T> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
T-Gro
added a commit
that referenced
this pull request
Apr 13, 2026
…augmentations Two user-reported bugs (gusty, PR #19396): 1. Array extension operator (++): type 'T [] with static member (++) crashes with 'BuildFSharpMethodCall: unexpected List.length mismatch' during optimization. 2. Option extension operator (|>>): same crash on Option<'T> with static member (|>>). Root cause: enclosing type's type parameters not accounted for in GenWitnessExpr. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
❗ Release notes requiredCaution No release notes found for the changed paths (see table below). Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format. The following format is recommended for this repository:
If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request. You can open this PR in browser to add release notes: open in github.dev
Warning No PR link found in some release notes, please consider adding it.
|
T-Gro
force-pushed
the
feature-operators-extensions
branch
from
fe73b0f to
1d9a2b2
Compare
10 tests covering the dimensions that the original test suite missed: Cross-assembly (library + app consumer): - option<'T> extension operator (reported bug) - 'T[] extension operator (reported bug) - list<'T> extension operator - Result<'T,'E> extension operator (multi-param FSharp.Core type) - System.Collections.Generic.List<'T> (BCL generic type) - Map<'K,'V> with constrained type params - User-defined Box<'T> across three assemblies (type in A, ext in B, consumer in C) - option<'T> with --optimize+ (optimizer code path) - Extension with extra method type param beyond enclosing type's params Multi-module same compilation: - Extension in module A, consumer in module B All prior tests used intrinsic extensions (same module as type def) or non-generic types, which never hit the IsExtensionMember=true path in BuildFSharpMethodCall. These tests ensure extrinsic extensions on generic types from other assemblies/modules are exercised. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Remove 3 duplicate PackageReference lines in FSharp.Test.Utilities.fsproj that caused NU1504 errors (System.Collections.Immutable, Microsoft.CodeAnalysis.Workspaces.Common, Microsoft.CodeAnalysis.CSharp) - Apply fantomas formatting to TypeHierarchy.fsi, NameResolution.fsi, TypedTree.fsi Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add 7 tests verifying that C#-style extension methods (ILMeth path) participate in SRTP constraint resolution during typechecking. Tests cover: concrete non-generic types (int), open generic arrays (T[]), unconstrained generics (T), multiple type parameters, nullable value types, reference types (object), and concrete generic instantiations (List<int>). Uses typecheckResults to exercise SRTP resolution while avoiding a known codegen ICE in IlxGen where the optimizer fails to find the extension method as an actual instance member on the type. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…lication - Extract optionMapExtDef/Lib, arrayAppendExtLib, listAppendExtLib as shared library definitions (following the existing stringRepeatExtLib pattern) - Extract shouldTypecheckWithCSharpExtension helper for C#-style tests - Fix naming inconsistency: add 'extrinsic' to extra-type-param test name - Net reduction: ~48 lines of duplicated boilerplate removed Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
T-Gro
force-pushed
the
feature-operators-extensions
branch
from
4e8c792 to
eb96aac
Compare
Root cause: GenWitnessExpr resolved the IL method reference against the apparent/extended type (e.g., System.String) instead of the declaring static helper class (e.g., StringExtensions) for C#-style extension methods. The extOpt field in ILMethSln already carried the declaring type reference but it was only used for CreateILExtensionMeth, not for resolveILMethodRef. Fix: When extOpt is Some (C#-style extension), resolve mref against the declaring type's metadata (actualTyconRef.ILTyconRawMetadata) instead of the apparent type. This enables 5 of 8 C#-style extension SRTP tests to run end-to-end with compileAndRun. The remaining 3 (value-type receivers: int, Nullable<T>, unconstrained generic T) produce InvalidProgramException due to a separate IlxGen issue with constrained calls on value types — these remain as typecheck-only tests documenting the gap. Why existing tests didn't catch this: Prior to RFC FS-1043, C#-style extension methods never participated in SRTP constraint resolution, so GenWitnessExpr's ILMethSln path was never exercised with extOpt=Some. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ss-taking Three fixes for C#-style extension methods resolved via SRTP: 1. GenWitnessExpr ILMethSln (MethodCalls.fs:2200-2216): resolve IL method reference against the declaring static helper class (extOpt) instead of the apparent/extended type. Previously crashed with 'no method named X found in type Y'. 2. BuildILMethInfoCall isStruct (MethodCalls.fs:1036-1043): for C#-style extensions, set isStruct=false since the declaring type is always a reference-type static class. Previously produced wrong boxity (AsValue) in the IL method spec when extending value types. 3. GenWitnessExpr address-taking (MethodCalls.fs:2274): skip struct receiver address-taking for C#-style extensions since they are static in IL and take the receiver by value, not by reference. These fixes enable 5 of 8 C#-style extension SRTP tests to run end-to-end (reference-type receivers: array, object, List, Select, Safe). The remaining 3 (value-type receivers: int, Nullable<T>, unconstrained T) produce InvalidProgramException requiring deeper IlxGen investigation — kept as typecheck-only tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…rpStyleExtensionMember Root cause: C#-style extensions are treated as instance methods by F#'s type system (ILMethInfo.IsInstance=true). For struct receivers, the type checker address-takes the receiver (LAddrOf). But C#-style extensions are static in IL and expect a by-value argument, causing InvalidProgramException. Three fixes: 1. GenWitnessExpr ILMethSln: Pass Some priority (not None) when creating ILExtensionMeth so IsCSharpStyleExtensionMember returns true. 2. GenWitnessExpr receiver: Strip LAddrOf from receiver expressions when the method is a C#-style extension (both direct LAddrOf(x) and let tmp = e in &tmp forms). 3. Tests: Upgrade 7/8 C#-style tests to full compileAndRun. The unconstrained generic T case (Stringify) remains typecheck-only — its address-taking form requires further investigation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Two root causes for the unsolved-typar issue in C#-style extension methods: 1. In MemberConstraintSolutionOfMethInfo (ConstraintSolver.fs): fresh type variables in minst had their solutions undone by FilterEachThenUndo but were stored as-is. Fix: strip typar indirections via stripTyEqnsAndMeasureEqns at the point of recording (catches solved-then-undone typars). 2. In GenWitnessExpr ILMethSln (MethodCalls.fs): for C#-style extensions where method type parameters appear only in the 'this' parameter (e.g., Stringify<T>(this T value)), GetParamTypes drops the 'this' param so CanMemberSigsMatchUpToCheck never equates T with the concrete receiver type. Fix: when minst has unsolved typars, derive them from origTy (the apparent enclosing type which IS the concrete receiver type). Also strips LAddrOf from C#-style extension receivers more generally, handling both direct LAddrOf(x), let tmp = e in &tmp, and any remaining byref forms via LByrefGet dereference. All 8 C#-style extension SRTP tests now run compileAndRun end-to-end, including Stringify<T> on value-type receivers. No remaining gaps. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…omments Fixes from expert review: - Remove debug System.IO.File.AppendAllText writes from MethodCalls.fs and IlxGen.fs - Remove duplicate GenExpr call in GenTraitCall (critical: would emit IL twice) - Clarify comment on unsolved typar substitution explaining why origTy is safe for all unsolved typars (only 'this'-exclusive typars remain unsolved) - Add comment on byref→value dereference fallback explaining the transform Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… analysis Instead of substituting ALL unsolved typars with origTy (unsafe for methods like Convert<T,U>(this T, U) where U has no relation to the receiver), now only substitute typars whose IL type variable index appears in the method's first (this) parameter type. Uses IL-level type inspection to collect type variable indices from the first parameter. This makes the fix safe for hypothetical multi-param extensions where non-this type parameters could remain unsolved independently. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Tests from adversarial review (opus-4.6 across 3 waves: RFC analysis, test-vs-RFC, whitebox implementation analysis): 1. C#-style extension on user-defined struct receiver (byref stripping path) 2. Extension operator on DU type (unique type representation) 3. Mixed built-in + extension constraints in single function 4. Non-inline wrapper of SRTP function (weak resolution / GenTraitCall) 5. Extension operator in task computation expression (state machine codegen) 6. Cross-assembly with --optimize- (debug codegen path) 7. Signature file consistency with extension-widened inline function 305 tests, 0 failures. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add cross-module same-compilation test covering non-generic, single-generic, and multi-generic intrinsic extension operators (3 matrix gaps in 1 test) - Remove duplicate optimize-minus option test (default path already covered) - Clarify optimization test comment as regression test 305 tests, 0 failures. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…patterns Main split TypedTreeOps.fs into 7 focused files (#19521) and added CloneWithFreshSolution/WithMemberKind to TraitConstraintInfo (#19471). Resolved by: - Removing old TypedTreeOps.fs (replaced by split files) - Updating all TTrait patterns in split files to 8 params (adding traitCtxt) - Adapting CloneWithFreshSolution to 8-param TTrait - Keeping both our TraitContext member and main's new members Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… on value types Resolved conflicts: - MethodCalls.fs: merged main's broader needsAddrTaken condition (IsStruct OR ComputeConstrainedCallInfo) with our IsCSharpStyleExtensionMember skip - IWSAMsAndSRTPsTests.fs: kept our 305 tests + added main's 5 new #8098 tests Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… suppress warning 52 4 CI failures fixed: 1. neg116.bsl/neg117.bsl: These tests expected 'ilxgen error FS0041' but now compile successfully. The RFC FS-1043 constraint solver changes fix a pre-existing codegen bug where trait calls failed to resolve at IL generation. Updated baselines to empty (compilation succeeds, ILVerify passes). 2. IWSAM extension wins test: Uses 'static abstract member' (IWSAM) which is not available on .NET Framework (net48). Added #if !NETCOREAPP Skip. 3. DateTime plus y test: Warning 52 (defensive copy of value type) treated as error on net48. Added --nowarn:52. 4. Gate stripTyEqnsAndMeasureEqns behind ExtensionConstraintSolutions feature flag to avoid changing observable semantics for non-preview langversions. Why not spotted locally: neg116/neg117 are legacy tests skipped on macOS/Linux. IWSAM/DateTime tests pass on net10.0 but fail on net48 (CI-only configuration). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
T-Gro
force-pushed
the
feature-operators-extensions
branch
from
8980f19 to
11ce1e2
Compare
T-Gro
force-pushed
the
feature-operators-extensions
branch
from
15917fb to
7561f83
Compare
10 verbose LLM-style comments replaced with concise compiler-style comments: - ConstraintSolver.fs: 7 comments (traitAD, intrinsicMinfos, built-in rule guard, stripTyEqns, extension append, AllowOverloadOnReturnType, CanonicalizeForExtensions) - MethodCalls.fs: 2 comments (receiver stripping, ILMethSln minst) - CheckExpressions.fs: 1 comment (FS1215 suppression) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
6 tests covering highest-priority gaps: 1. FS1215 + --warnaserror: verifies warning→error under langversion:8.0, suppressed under preview 2. True extrinsic extension cross-assembly: System.String extension via inline SRTP across assemblies 3. Multi-support (^T or ^U): op_Implicit extension satisfying multi-type SRTP 4. Inline fold + generic active pattern with extension operators 5. Optimize+ vs optimize- produce identical results for extension SRTP 6. Unsolvable SRTP on concrete type correctly fails to compile 316 tests, 0 failures (net10.0/macOS). NOT PUSHED — CI validation pending. Co-authored-by: Copilot <223556219+Copilot@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.
Implements RFC FS-1043. Gated behind
--langversion:preview.See docs/RFC_Changes.md for implementation-specific amendments to the RFC (interop, diagnostics, compatibility, binary compat).
1. Extension members solve SRTP constraints
Extrinsic extension members (operators, named methods, properties) in scope at an inline function's definition site are now captured in the SRTP constraint and considered during overload resolution. Built-in primitive operator solutions retain priority when types match precisely.
2. Weak resolution deferred for inline code
Inline SRTP functions no longer eagerly collapse to a concrete type.
let inline f1 (x: DateTime) y = x + ystays generic (DateTime -> ^a -> ^b when ...). Breaking: signature files and monomorphic bindings may need updating.3.
[<AllowOverloadOnReturnType>]New FSharp.Core attribute enables return-type-based overload resolution for any method, extending behavior previously reserved for
op_Explicit/op_Implicit.