Executive summary
fable-compiler/Fable scores 69 out of 100 and is rated Adequate, while five of its seven lenses score higher still: Event Sourcing at 100 and Architecture at 91, both rated Exemplary, Performance at 78 and Maturity at 73, both rated Strong, and Security and Compliance at 73, rated Adequate.
The score is lower than those five because the weakest lens counts most, and here that is Production Readiness, which scores 64 and is rated Adequate. Its weakest dimension is Deployment & Rollback, which scores 5 out of 10. The first actions are to resolve the 1 Test suite declares a test script but contains no test files finding(s) in Test Reliability and to resolve the 30 Outdated (npm) finding(s) in Dependency Hygiene, and if Production Readiness rose to 70, the score would rise from 69 to about 71.
105 findings are critical: 90 in Static Analysis (SAST), eight in Knowledge Freshness, four in Change Coupling, one in Circular Imports, one in Dependency Vulnerabilities and one in Test Reliability.
Watchdog couldn't measure 35 dimensions in this code, among them Cyclomatic Complexity, Cognitive Complexity and Code Duplication, so they are left out of the score. The product code is 390,372 lines, which would take an estimated 4.5 person-years, around €660,000, to rebuild.
If Production Readiness rose from 64 to 70, the lowest score rated Strong, the score would rise from 69 to about 71.
New since the last survey: 26 findings
- God Classes · FileTooLong: fable-library-beam/Seq.fs src/fable-library-beam/Seq.fs
- God Classes · FileTooLong: src/Main.fs src/fable-standalone/src/Main.fs
- God Classes · TooManyFunctions: fable_async src/fable-library-beam/fable_async.erl
- Churn × Complexity Hotspots · Hotspot: src/fable-standalone/src/Main.fs src/fable-standalone/src/Main.fs
- Churn × Complexity Hotspots · Hotspot: src/Fable.Transforms/Php/Fable2Php.fs src/Fable.Transforms/Php/Fable2Php.fs
- Churn × Complexity Hotspots · Hotspot: src/Fable.Compiler/MSBuildCrackerResolver.fs src/Fable.Compiler/MSBuildCrackerResolver.fs
- Churn × Complexity Hotspots · Hotspot: src/Fable.Cli/Entry.fs src/Fable.Cli/Entry.fs
- Churn × Complexity Hotspots · Hotspot: src/fable-compiler-js/src/app.fs src/fable-compiler-js/src/app.fs
- Churn × Complexity Hotspots · Repeated repair: src/fable-library-py/fable_library/async_.py src/fable-library-py/fable_library/async_.py
- Churn × Complexity Hotspots · Repeated repair: src/fable-library-ts/Async.ts src/fable-library-ts/Async.ts
- Churn × Complexity Hotspots · Repeated repair: src/Fable.Transforms/State.fs src/Fable.Transforms/State.fs
- Churn × Complexity Hotspots · Repeated repair: src/fable-library-py/fable_library/async_builder.py src/fable-library-py/fable_library/async_builder.py
- Churn × Complexity Hotspots · Repeated repair: src/Fable.Transforms/Rust/AST/Rust.AST.Helpers.fs src/Fable.Transforms/Rust/AST/Rust.AST.Helpers.fs
- Churn × Complexity Hotspots · Repeated repair: src/fable-library-py/fable_library/mailbox_processor.py src/fable-library-py/fable_library/mailbox_processor.py
- Churn × Complexity Hotspots · Repeated repair: src/fable-library-ts/AsyncBuilder.ts src/fable-library-ts/AsyncBuilder.ts
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Code Duplication · Duplicated block (12 lines × 2 locations) src/fable-library-ts/Encoding.ts
- Code Duplication · Duplicated block (9 lines × 2 locations) src/fable-library-ts/AsyncBuilder.ts
- Code Duplication · Duplicated block (7 lines × 2 locations) src/fable-library-ts/lib/big.js
- Cyclomatic Complexity · Complex function (anonymous) (cyclomatic 61, cognitive 104) REDACTED
- Cyclomatic Complexity · Complex function divide (cyclomatic 34, cognitive 78) src/fable-library-ts/lib/big.js
- Cyclomatic Complexity · Complex function round (cyclomatic 32, cognitive 33) src/fable-library-ts/lib/big.js
- Cyclomatic Complexity · Complex function sub (cyclomatic 21, cognitive 34) src/fable-library-ts/lib/big.js
- Large Files · src/fable-library-ts/lib/big.js: 879 lines of code src/fable-library-ts/lib/big.js
- Large Files · REDACTED: 702 lines of code REDACTED
Fixed since the last survey: 23 findings
- Dependency Hygiene · Deprecated: XUnit
- Churn × Complexity Hotspots · Hotspot: src/Fable.Transforms/Beam/Fable2Beam.Reflection.fs src/Fable.Transforms/Beam/Fable2Beam.Reflection.fs
- Churn × Complexity Hotspots · Hotspot: src/Fable.Transforms/QuotationEmitter.fs src/Fable.Transforms/QuotationEmitter.fs
- Churn × Complexity Hotspots · Hotspot: src/Fable.Transforms/Python/Fable2Python.Annotation.fs src/Fable.Transforms/Python/Fable2Python.Annotation.fs
- Churn × Complexity Hotspots · Hotspot: src/fable-library-py/src/native_array.rs src/fable-library-py/src/native_array.rs
- Churn × Complexity Hotspots · Hotspot: src/Fable.Cli/Pipeline.fs src/Fable.Cli/Pipeline.fs
- Churn × Complexity Hotspots · Hotspot: src/fable-library-py/src/array.rs src/fable-library-py/src/array.rs
- Churn × Complexity Hotspots · Hotspot: src/fable-library-rust/src/Map.fs src/fable-library-rust/src/Map.fs
- Churn × Complexity Hotspots · Repeated repair: src/Fable.Transforms/FSharp2Fable.fs src/Fable.Transforms/FSharp2Fable.fs
- Churn × Complexity Hotspots · Repeated repair: src/fable-library-py/src/ints.rs src/fable-library-py/src/ints.rs
- Churn × Complexity Hotspots · Repeated repair: src/fable-library-beam/fable_async.erl src/fable-library-beam/fable_async.erl
- Dependency Vulnerabilities · Critical CVE: [GHSA redacted] REDACTED
- Code Duplication · Duplicated block (19 lines × 2 locations) src/fable-library-ts/Encoding.ts
- Code Duplication · Duplicated block (8 lines × 2 locations) src/fable-library-ts/Encoding.ts
- Code Duplication · Duplicated block (7 lines × 3 locations) src/fable-library-ts/BitConverter.ts
- Code Duplication · Duplicated block (5 lines × 2 locations) REDACTED
- Code Duplication · Duplicated block (5 lines × 14 locations) src/fable-library-ts/Util.ts
- Cyclomatic Complexity · Complex function (anonymous) (cyclomatic 58, cognitive 99) REDACTED
- Cyclomatic Complexity · Complex function div (cyclomatic 33, cognitive 75) src/fable-library-ts/lib/big.js
- Cyclomatic Complexity · Complex function round (cyclomatic 33, cognitive 35) src/fable-library-ts/lib/big.js
- Cyclomatic Complexity · Complex function sub (cyclomatic 22, cognitive 35) src/fable-library-ts/lib/big.js
- Large Files · src/fable-library-ts/lib/big.js: 844 lines of code src/fable-library-ts/lib/big.js
- Large Files · REDACTED: 698 lines of code REDACTED
Rebuild cost: about €660,000 · Estimate
| Cost to rebuild | €220,000 to €1,100,000, for 3,656 to 11,597 hours of work, about 4.5 person-years for 2 to 9 engineers |
|---|---|
| Difficulty of the problem | Standard, judged from the kind of software and how it is built. Code that solves a harder problem, such as payments or medical bookings, costs more per line to write. |
| Quality factor | ×1.0 at a score of 69. Better code takes more work to write, so the factor is ×1.0 at a score of 70, lower below it and higher above it. |
| Size | Large: 390,372 lines of product code |
Top priorities
Diagnosis: what the measurements show together
Architecture — bounded-context dependency graph
Architecture: which parts of the code depend on which
| uses → | 1 (global) | 2 System.Collections | 3 System.Collections.Generic | 4 fable_library_rust.LrcPtr | 5 fable_library_rust.Mutable.NonSyncCell | 6 System | 7 FSharp.Compiler.Text | 8 Fable.AST | 9 Fable.Transforms.Rust.AST.Types | 10 Internal.Utilities.Collections.Tagged | 11 Internal.Utilities.Library | 12 Util.Testing | 13 FSharp.Compiler.AbstractIL.IL | 14 FSharp.Compiler.Syntax | 15 Fable.AST.Fable | 16 Fable.Transforms.Python.AST | 17 Internal.Utilities.Text.Lexing | 18 FSharp.Compiler.TypedTree | 19 FSharp.Compiler.TcGlobals | 20 FSharp.Compiler.Import | 21 FSharp.Compiler.InfoReader | 22 FSharp.Compiler.NameResolution | 23 FSharp.Compiler.Symbols | 24 FSharp.Compiler.Diagnostics | 25 FSharp.Compiler.DiagnosticsLogger | 26 FSharp.Compiler.CompilerConfig | 27 FSharp.Compiler.TypedTreeOps | 28 FSharp.Compiler.Infos | 29 FSharp.Compiler.AccessibilityLogic | 30 FSharp.Compiler.ConstraintSolver | 31 FSharp.Compiler.EditorServices | 32 FSharp.Compiler.CheckBasics | 33 FSharp.Compiler.CodeAnalysis | 34 FSharp.Compiler.CheckExpressions | 35 Fable | 36 Fable.Transforms.FSharp2Fable | 37 Fable.Transforms.Printer | 38 Fable.Transforms.State | 39 Fable.Compiler.Util | 40 Fable.Standalone.Main |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 (global) | ||||||||||||||||||||||||||||||||||||||||
| 2 System.Collections | ||||||||||||||||||||||||||||||||||||||||
| 3 System.Collections.Generic | 5 | 2 | ||||||||||||||||||||||||||||||||||||||
| 4 fable_library_rust.LrcPtr | 1 | |||||||||||||||||||||||||||||||||||||||
| 5 fable_library_rust.Mutable.NonSyncCell | 1 | |||||||||||||||||||||||||||||||||||||||
| 6 System | 2 | 2 | ||||||||||||||||||||||||||||||||||||||
| 7 FSharp.Compiler.Text | 8 | 6 | ||||||||||||||||||||||||||||||||||||||
| 8 Fable.AST | 14 | 21 | ||||||||||||||||||||||||||||||||||||||
| 9 Fable.Transforms.Rust.AST.Types | 159 | 213 | ||||||||||||||||||||||||||||||||||||||
| 10 Internal.Utilities.Collections.Tagged | 2 | 3 | 2 | |||||||||||||||||||||||||||||||||||||
| 11 Internal.Utilities.Library | 3 | 6 | 2 | |||||||||||||||||||||||||||||||||||||
| 12 Util.Testing | 1 | 2 | 1 | |||||||||||||||||||||||||||||||||||||
| 13 FSharp.Compiler.AbstractIL.IL | 98 | 2 | 106 | 6 | ||||||||||||||||||||||||||||||||||||
| 14 FSharp.Compiler.Syntax | 28 | 19 | 66 | |||||||||||||||||||||||||||||||||||||
| 15 Fable.AST.Fable | 73 | 4 | 108 | 7 | ||||||||||||||||||||||||||||||||||||
| 16 Fable.Transforms.Python.AST | 73 | 85 | 21 | |||||||||||||||||||||||||||||||||||||
| 17 Internal.Utilities.Text.Lexing | 2 | 1 | 2 | 2 | ||||||||||||||||||||||||||||||||||||
| 18 FSharp.Compiler.TypedTree | 48 | 2 | 46 | 22 | 2 | 3 | 26 | 32 | ||||||||||||||||||||||||||||||||
| 19 FSharp.Compiler.TcGlobals | 2 | 2 | 1 | 5 | ||||||||||||||||||||||||||||||||||||
| 20 FSharp.Compiler.Import | 2 | 1 | 7 | 6 | 1 | |||||||||||||||||||||||||||||||||||
| 21 FSharp.Compiler.InfoReader | 2 | 2 | 2 | 10 | 2 | 2 | 11 | 2 | ||||||||||||||||||||||||||||||||
| 22 FSharp.Compiler.NameResolution | 28 | 25 | 13 | 2 | 4 | 31 | 4 | 2 | 3 | 7 | 12 | 3 | ||||||||||||||||||||||||||||
| 23 FSharp.Compiler.Symbols | 4 | 2 | 2 | 14 | 2 | 23 | 6 | 1 | 1 | 1 | 1 | 1 | ||||||||||||||||||||||||||||
| 24 FSharp.Compiler.Diagnostics | 5 | 5 | 3 | 1 | 2 | |||||||||||||||||||||||||||||||||||
| 25 FSharp.Compiler.DiagnosticsLogger | 22 | 13 | 15 | 1 | 2 | |||||||||||||||||||||||||||||||||||
| 26 FSharp.Compiler.CompilerConfig | 30 | 1 | 24 | 7 | 9 | 1 | 2 | 2 | 4 | 6 | ||||||||||||||||||||||||||||||
| 27 FSharp.Compiler.TypedTreeOps | 15 | 4 | 15 | 5 | 2 | 1 | 12 | 11 | 72 | 5 | 1 | |||||||||||||||||||||||||||||
| 28 FSharp.Compiler.Infos | 5 | 5 | 10 | 23 | 2 | 52 | 11 | 8 | 1 | |||||||||||||||||||||||||||||||
| 29 FSharp.Compiler.AccessibilityLogic | 1 | 1 | 8 | 2 | 1 | 6 | ||||||||||||||||||||||||||||||||||
| 30 FSharp.Compiler.ConstraintSolver | 3 | 2 | 5 | 19 | 1 | 1 | 30 | 5 | 2 | 2 | 1 | 16 | 1 | 1 | ||||||||||||||||||||||||||
| 31 FSharp.Compiler.EditorServices | 1 | 51 | 40 | 18 | 2 | 1 | 2 | 3 | 7 | 2 | 2 | |||||||||||||||||||||||||||||
| 32 FSharp.Compiler.CheckBasics | 2 | 1 | 2 | 2 | 1 | 4 | 22 | 1 | 1 | 1 | 3 | 1 | 1 | 2 | 1 | 2 | ||||||||||||||||||||||||
| 33 FSharp.Compiler.CodeAnalysis | 1 | 10 | 1 | 6 | 7 | 1 | 1 | 9 | 2 | 8 | 13 | 4 | 6 | 1 | 2 | 8 | ||||||||||||||||||||||||
| 34 FSharp.Compiler.CheckExpressions | 34 | 16 | 46 | 1 | 32 | 66 | 2 | 1 | 6 | 31 | 1 | 1 | 2 | 24 | ||||||||||||||||||||||||||
| 35 Fable | 13 | 1 | 21 | 2 | 13 | 1 | 1 | |||||||||||||||||||||||||||||||||
| 36 Fable.Transforms.FSharp2Fable | 2 | 3 | 3 | 1 | 39 | 14 | 2 | |||||||||||||||||||||||||||||||||
| 37 Fable.Transforms.Printer | 2 | 5 | 2 | 2 | ||||||||||||||||||||||||||||||||||||
| 38 Fable.Transforms.State | 10 | 1 | 13 | 2 | 5 | 8 | 2 | 12 | ||||||||||||||||||||||||||||||||
| 39 Fable.Compiler.Util | 5 | 4 | 4 | 1 | ||||||||||||||||||||||||||||||||||||
| 40 Fable.Standalone.Main | 1 | 3 | 1 | 1 | 1 | 2 | 1 | 6 | 5 | 2 | 1 | 6 |
3→2 System.Collections.Generic uses System.Collections✕
- Connections
- 5 pairs of types, where a type in System.Collections.Generic uses a type in System.Collections.
- The types involved
System.Collections.Generic.IEnumerable`1→System.Collections.IEnumerableSystem.Collections.Generic.IEnumerator`1→System.Collections.IEnumeratorSystem.Collections.Generic.LinkedList`1→System.Collections.IEnumeratorSystem.Collections.Generic.Queue`1→System.Collections.IEnumeratorSystem.Collections.Generic.Stack`1→System.Collections.IEnumerator
- Direction
- System.Collections.Generic uses System.Collections, so a change to System.Collections can break System.Collections.Generic, while a change to System.Collections.Generic can't break System.Collections.
- Position
- Below the diagonal: System.Collections.Generic uses a module listed above it, which is the healthy direction.
3→6 System.Collections.Generic uses System part of a loop✕
- Connections
- 2 pairs of types, where a type in System.Collections.Generic uses a type in System.
- The types involved
System.Collections.Generic.IEnumerator`1→System.IDisposableSystem.Collections.Generic.KeyNotFoundException→System.Exception
- Direction
- System.Collections.Generic uses System, so a change to System can break System.Collections.Generic, while a change to System.Collections.Generic can't break System.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
4→1 fable_library_rust.LrcPtr uses (global)✕
- Connections
- 1 pair of types, where a type in fable_library_rust.LrcPtr uses a type in (global).
- The types involved
fable_library_rust.LrcPtr.LrcPtr→Result
- Direction
- fable_library_rust.LrcPtr uses (global), so a change to (global) can break fable_library_rust.LrcPtr, while a change to fable_library_rust.LrcPtr can't break (global).
- Position
- Below the diagonal: fable_library_rust.LrcPtr uses a module listed above it, which is the healthy direction.
5→1 fable_library_rust.Mutable.NonSyncCell uses (global)✕
- Connections
- 1 pair of types, where a type in fable_library_rust.Mutable.NonSyncCell uses a type in (global).
- The types involved
fable_library_rust.Mutable.NonSyncCell.MutCell→Result
- Direction
- fable_library_rust.Mutable.NonSyncCell uses (global), so a change to (global) can break fable_library_rust.Mutable.NonSyncCell, while a change to fable_library_rust.Mutable.NonSyncCell can't break (global).
- Position
- Below the diagonal: fable_library_rust.Mutable.NonSyncCell uses a module listed above it, which is the healthy direction.
6→2 System uses System.Collections✕
- Connections
- 2 pairs of types, where a type in System uses a type in System.Collections.
- The types involved
System.Exception→System.Collections.IEqualityComparerSystem.Exception→System.Collections.IStructuralEquatable
- Direction
- System uses System.Collections, so a change to System.Collections can break System, while a change to System can't break System.Collections.
- Position
- Below the diagonal: System uses a module listed above it, which is the healthy direction.
6→3 System uses System.Collections.Generic✕
- Connections
- 2 pairs of types, where a type in System uses a type in System.Collections.Generic.
- The types involved
System.StringComparer→System.Collections.Generic.IComparer`1System.StringComparer→System.Collections.Generic.IEqualityComparer`1
- Direction
- System uses System.Collections.Generic, so a change to System.Collections.Generic can break System, while a change to System can't break System.Collections.Generic.
- Position
- Below the diagonal: System uses a module listed above it, which is the healthy direction.
7→2 FSharp.Compiler.Text uses System.Collections✕
- Connections
- 8 pairs of types, where a type in FSharp.Compiler.Text uses a type in System.Collections.
- The types involved
FSharp.Compiler.Text.Joint→System.Collections.IStructuralEquatableFSharp.Compiler.Text.NoResult→System.Collections.IStructuralComparableFSharp.Compiler.Text.NoResult→System.Collections.IStructuralEquatableFSharp.Compiler.Text.NoState→System.Collections.IStructuralComparableFSharp.Compiler.Text.NoState→System.Collections.IStructuralEquatableFSharp.Compiler.Text.NotedSourceConstruct→System.Collections.IStructuralComparableFSharp.Compiler.Text.NotedSourceConstruct→System.Collections.IStructuralEquatableFSharp.Compiler.Text.TextTag→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.Text uses System.Collections, so a change to System.Collections can break FSharp.Compiler.Text, while a change to FSharp.Compiler.Text can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.Text uses a module listed above it, which is the healthy direction.
7→6 FSharp.Compiler.Text uses System✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.Text uses a type in System.
- The types involved
FSharp.Compiler.Text.NoResult→System.IComparableFSharp.Compiler.Text.NoResult→System.IComparable`1FSharp.Compiler.Text.NoState→System.IComparableFSharp.Compiler.Text.NoState→System.IComparable`1FSharp.Compiler.Text.NotedSourceConstruct→System.IComparableFSharp.Compiler.Text.NotedSourceConstruct→System.IComparable`1
- Direction
- FSharp.Compiler.Text uses System, so a change to System can break FSharp.Compiler.Text, while a change to FSharp.Compiler.Text can't break System.
- Position
- Below the diagonal: FSharp.Compiler.Text uses a module listed above it, which is the healthy direction.
8→2 Fable.AST uses System.Collections✕
- Connections
- 14 pairs of types, where a type in Fable.AST uses a type in System.Collections.
- The types involved
Fable.AST.BinaryOperator→System.Collections.IStructuralComparableFable.AST.BinaryOperator→System.Collections.IStructuralEquatableFable.AST.LogicalOperator→System.Collections.IStructuralComparableFable.AST.LogicalOperator→System.Collections.IStructuralEquatableFable.AST.NumberKind→System.Collections.IStructuralComparableFable.AST.NumberKind→System.Collections.IStructuralEquatableFable.AST.Position→System.Collections.IStructuralComparableFable.AST.Position→System.Collections.IStructuralEquatableFable.AST.RegexFlag→System.Collections.IStructuralComparableFable.AST.RegexFlag→System.Collections.IStructuralEquatableFable.AST.SourceLocation→System.Collections.IStructuralComparableFable.AST.SourceLocation→System.Collections.IStructuralEquatableFable.AST.UnaryOperator→System.Collections.IStructuralComparableFable.AST.UnaryOperator→System.Collections.IStructuralEquatable
- Direction
- Fable.AST uses System.Collections, so a change to System.Collections can break Fable.AST, while a change to Fable.AST can't break System.Collections.
- Position
- Below the diagonal: Fable.AST uses a module listed above it, which is the healthy direction.
8→6 Fable.AST uses System✕
- Connections
- 21 pairs of types, where a type in Fable.AST uses a type in System.
- The types involved
Fable.AST.BinaryOperator→System.IComparableFable.AST.BinaryOperator→System.IComparable`1Fable.AST.BinaryOperator→System.IEquatable`1Fable.AST.LogicalOperator→System.IComparableFable.AST.LogicalOperator→System.IComparable`1Fable.AST.LogicalOperator→System.IEquatable`1Fable.AST.NumberKind→System.IComparableFable.AST.NumberKind→System.IComparable`1Fable.AST.NumberKind→System.IEquatable`1Fable.AST.Position→System.IComparableFable.AST.Position→System.IComparable`1Fable.AST.Position→System.IEquatable`1Fable.AST.RegexFlag→System.IComparableFable.AST.RegexFlag→System.IComparable`1Fable.AST.RegexFlag→System.IEquatable`1Fable.AST.SourceLocation→System.IComparableFable.AST.SourceLocation→System.IComparable`1Fable.AST.SourceLocation→System.IEquatable`1Fable.AST.UnaryOperator→System.IComparableFable.AST.UnaryOperator→System.IComparable`1Fable.AST.UnaryOperator→System.IEquatable`1
- Direction
- Fable.AST uses System, so a change to System can break Fable.AST, while a change to Fable.AST can't break System.
- Position
- Below the diagonal: Fable.AST uses a module listed above it, which is the healthy direction.
9→2 Fable.Transforms.Rust.AST.Types uses System.Collections✕
- Connections
- 159 pairs of types, where a type in Fable.Transforms.Rust.AST.Types uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
Fable.Transforms.Rust.AST.Types.AngleBracketedArg→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.AngleBracketedArgs→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.AnonConst→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.Arm→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.AssocItemKind→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.AssocTyConstraint→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.AssocTyConstraintKind→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.Asyncness→System.Collections.IStructuralComparableFable.Transforms.Rust.AST.Types.Asyncness→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.AttrItem→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.AttrKind→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.AttrStyle→System.Collections.IStructuralComparableFable.Transforms.Rust.AST.Types.AttrStyle→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.Attribute→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.BareFnTy→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.BinOpKind→System.Collections.IStructuralComparableFable.Transforms.Rust.AST.Types.BinOpKind→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.BindingMode→System.Collections.IStructuralComparableFable.Transforms.Rust.AST.Types.BindingMode→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.Block→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.BlockCheckMode→System.Collections.IStructuralComparableFable.Transforms.Rust.AST.Types.BlockCheckMode→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.BorrowKind→System.Collections.IStructuralComparableFable.Transforms.Rust.AST.Types.BorrowKind→System.Collections.IStructuralEquatableFable.Transforms.Rust.AST.Types.CaptureBy→System.Collections.IStructuralComparable
- Direction
- Fable.Transforms.Rust.AST.Types uses System.Collections, so a change to System.Collections can break Fable.Transforms.Rust.AST.Types, while a change to Fable.Transforms.Rust.AST.Types can't break System.Collections.
- Position
- Below the diagonal: Fable.Transforms.Rust.AST.Types uses a module listed above it, which is the healthy direction.
9→6 Fable.Transforms.Rust.AST.Types uses System✕
- Connections
- 213 pairs of types, where a type in Fable.Transforms.Rust.AST.Types uses a type in System. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
Fable.Transforms.Rust.AST.Types.AngleBracketedArg→System.IEquatable`1Fable.Transforms.Rust.AST.Types.AngleBracketedArgs→System.IEquatable`1Fable.Transforms.Rust.AST.Types.AnonConst→System.IEquatable`1Fable.Transforms.Rust.AST.Types.Arm→System.IEquatable`1Fable.Transforms.Rust.AST.Types.AssocItemKind→System.IEquatable`1Fable.Transforms.Rust.AST.Types.AssocTyConstraint→System.IEquatable`1Fable.Transforms.Rust.AST.Types.AssocTyConstraintKind→System.IEquatable`1Fable.Transforms.Rust.AST.Types.Asyncness→System.IComparableFable.Transforms.Rust.AST.Types.Asyncness→System.IComparable`1Fable.Transforms.Rust.AST.Types.Asyncness→System.IEquatable`1Fable.Transforms.Rust.AST.Types.AttrItem→System.IEquatable`1Fable.Transforms.Rust.AST.Types.AttrItem→System.Lazy`1Fable.Transforms.Rust.AST.Types.AttrKind→System.IEquatable`1Fable.Transforms.Rust.AST.Types.AttrKind→System.Lazy`1Fable.Transforms.Rust.AST.Types.AttrStyle→System.IComparableFable.Transforms.Rust.AST.Types.AttrStyle→System.IComparable`1Fable.Transforms.Rust.AST.Types.AttrStyle→System.IEquatable`1Fable.Transforms.Rust.AST.Types.Attribute→System.IEquatable`1Fable.Transforms.Rust.AST.Types.BareFnTy→System.IEquatable`1Fable.Transforms.Rust.AST.Types.BinOpKind→System.IComparableFable.Transforms.Rust.AST.Types.BinOpKind→System.IComparable`1Fable.Transforms.Rust.AST.Types.BinOpKind→System.IEquatable`1Fable.Transforms.Rust.AST.Types.BindingMode→System.IComparableFable.Transforms.Rust.AST.Types.BindingMode→System.IComparable`1Fable.Transforms.Rust.AST.Types.BindingMode→System.IEquatable`1
- Direction
- Fable.Transforms.Rust.AST.Types uses System, so a change to System can break Fable.Transforms.Rust.AST.Types, while a change to Fable.Transforms.Rust.AST.Types can't break System.
- Position
- Below the diagonal: Fable.Transforms.Rust.AST.Types uses a module listed above it, which is the healthy direction.
10→2 Internal.Utilities.Collections.Tagged uses System.Collections✕
- Connections
- 2 pairs of types, where a type in Internal.Utilities.Collections.Tagged uses a type in System.Collections.
- The types involved
Internal.Utilities.Collections.Tagged.Map`3→System.Collections.IEnumerableInternal.Utilities.Collections.Tagged.Set`2→System.Collections.IEnumerable
- Direction
- Internal.Utilities.Collections.Tagged uses System.Collections, so a change to System.Collections can break Internal.Utilities.Collections.Tagged, while a change to Internal.Utilities.Collections.Tagged can't break System.Collections.
- Position
- Below the diagonal: Internal.Utilities.Collections.Tagged uses a module listed above it, which is the healthy direction.
10→3 Internal.Utilities.Collections.Tagged uses System.Collections.Generic✕
- Connections
- 3 pairs of types, where a type in Internal.Utilities.Collections.Tagged uses a type in System.Collections.Generic.
- The types involved
Internal.Utilities.Collections.Tagged.Map`3→System.Collections.Generic.IEnumerable`1Internal.Utilities.Collections.Tagged.Set`2→System.Collections.Generic.ICollection`1Internal.Utilities.Collections.Tagged.Set`2→System.Collections.Generic.IEnumerable`1
- Direction
- Internal.Utilities.Collections.Tagged uses System.Collections.Generic, so a change to System.Collections.Generic can break Internal.Utilities.Collections.Tagged, while a change to Internal.Utilities.Collections.Tagged can't break System.Collections.Generic.
- Position
- Below the diagonal: Internal.Utilities.Collections.Tagged uses a module listed above it, which is the healthy direction.
10→6 Internal.Utilities.Collections.Tagged uses System✕
- Connections
- 2 pairs of types, where a type in Internal.Utilities.Collections.Tagged uses a type in System.
- The types involved
Internal.Utilities.Collections.Tagged.Map`3→System.IComparableInternal.Utilities.Collections.Tagged.Set`2→System.IComparable
- Direction
- Internal.Utilities.Collections.Tagged uses System, so a change to System can break Internal.Utilities.Collections.Tagged, while a change to Internal.Utilities.Collections.Tagged can't break System.
- Position
- Below the diagonal: Internal.Utilities.Collections.Tagged uses a module listed above it, which is the healthy direction.
11→2 Internal.Utilities.Library uses System.Collections✕
- Connections
- 3 pairs of types, where a type in Internal.Utilities.Library uses a type in System.Collections.
- The types involved
Internal.Utilities.Library.ResultOrException`1→System.Collections.IStructuralEquatableInternal.Utilities.Library.UndefinedException→System.Collections.IStructuralEquatableInternal.Utilities.Library.ValueOrCancelled`1→System.Collections.IStructuralEquatable
- Direction
- Internal.Utilities.Library uses System.Collections, so a change to System.Collections can break Internal.Utilities.Library, while a change to Internal.Utilities.Library can't break System.Collections.
- Position
- Below the diagonal: Internal.Utilities.Library uses a module listed above it, which is the healthy direction.
11→3 Internal.Utilities.Library uses System.Collections.Generic✕
- Connections
- 6 pairs of types, where a type in Internal.Utilities.Library uses a type in System.Collections.Generic.
- The types involved
Internal.Utilities.Library.DelayInitArrayMap`3→System.Collections.Generic.IDictionary`2Internal.Utilities.Library.IPartialEqualityComparer`1→System.Collections.Generic.IEqualityComparer`1Internal.Utilities.Library.MemoizationTable`2→System.Collections.Generic.IEqualityComparer`1Internal.Utilities.Library.StampedDictionary`2→System.Collections.Generic.IEnumerable`1Internal.Utilities.Library.StampedDictionary`2→System.Collections.Generic.IEqualityComparer`1Internal.Utilities.Library.UniqueStampGenerator`1→System.Collections.Generic.ICollection`1
- Direction
- Internal.Utilities.Library uses System.Collections.Generic, so a change to System.Collections.Generic can break Internal.Utilities.Library, while a change to Internal.Utilities.Library can't break System.Collections.Generic.
- Position
- Below the diagonal: Internal.Utilities.Library uses a module listed above it, which is the healthy direction.
11→6 Internal.Utilities.Library uses System✕
- Connections
- 2 pairs of types, where a type in Internal.Utilities.Library uses a type in System.
- The types involved
Internal.Utilities.Library.LazyWithContextFailure→System.ExceptionInternal.Utilities.Library.ResultOrException`1→System.Exception
- Direction
- Internal.Utilities.Library uses System, so a change to System can break Internal.Utilities.Library, while a change to Internal.Utilities.Library can't break System.
- Position
- Below the diagonal: Internal.Utilities.Library uses a module listed above it, which is the healthy direction.
12→2 Util.Testing uses System.Collections✕
- Connections
- 1 pair of types, where a type in Util.Testing uses a type in System.Collections.
- The types involved
Util.Testing.TestKind→System.Collections.IStructuralEquatable
- Direction
- Util.Testing uses System.Collections, so a change to System.Collections can break Util.Testing, while a change to Util.Testing can't break System.Collections.
- Position
- Below the diagonal: Util.Testing uses a module listed above it, which is the healthy direction.
12→3 Util.Testing uses System.Collections.Generic✕
- Connections
- 2 pairs of types, where a type in Util.Testing uses a type in System.Collections.Generic.
- The types involved
Util.Testing.TestKind→System.Collections.Generic.IEnumerable`1Util.Testing.Testing→System.Collections.Generic.IEnumerable`1
- Direction
- Util.Testing uses System.Collections.Generic, so a change to System.Collections.Generic can break Util.Testing, while a change to Util.Testing can't break System.Collections.Generic.
- Position
- Below the diagonal: Util.Testing uses a module listed above it, which is the healthy direction.
12→6 Util.Testing uses System✕
- Connections
- 1 pair of types, where a type in Util.Testing uses a type in System.
- The types involved
Util.Testing.TestKind→System.IEquatable`1
- Direction
- Util.Testing uses System, so a change to System can break Util.Testing, while a change to Util.Testing can't break System.
- Position
- Below the diagonal: Util.Testing uses a module listed above it, which is the healthy direction.
13→2 FSharp.Compiler.AbstractIL.IL uses System.Collections✕
- Connections
- 98 pairs of types, where a type in FSharp.Compiler.AbstractIL.IL uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.AbstractIL.IL.ILAlignment→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILAlignment→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILArgConvention→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILArgConvention→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILArrayShape→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILArrayShape→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILAssemblyLongevity→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILAssemblyLongevity→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILAttribElem→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILAttribElem→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILAttribute→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILAttribute→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILBasicType→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILBasicType→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILBoxity→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILBoxity→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILCallingConv→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILCallingConv→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILCallingSignature→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILCallingSignature→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILComparisonInstr→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILComparisonInstr→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILConst→System.Collections.IStructuralComparableFSharp.Compiler.AbstractIL.IL.ILConst→System.Collections.IStructuralEquatableFSharp.Compiler.AbstractIL.IL.ILDefaultPInvokeEncoding→System.Collections.IStructuralComparable
- Direction
- FSharp.Compiler.AbstractIL.IL uses System.Collections, so a change to System.Collections can break FSharp.Compiler.AbstractIL.IL, while a change to FSharp.Compiler.AbstractIL.IL can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.AbstractIL.IL uses a module listed above it, which is the healthy direction.
13→3 FSharp.Compiler.AbstractIL.IL uses System.Collections.Generic✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.AbstractIL.IL uses a type in System.Collections.Generic.
- The types involved
FSharp.Compiler.AbstractIL.IL.ILMethodDefs→System.Collections.Generic.IEnumerable`1FSharp.Compiler.AbstractIL.IL.ILTypeDefs→System.Collections.Generic.IEnumerable`1
- Direction
- FSharp.Compiler.AbstractIL.IL uses System.Collections.Generic, so a change to System.Collections.Generic can break FSharp.Compiler.AbstractIL.IL, while a change to FSharp.Compiler.AbstractIL.IL can't break System.Collections.Generic.
- Position
- Below the diagonal: FSharp.Compiler.AbstractIL.IL uses a module listed above it, which is the healthy direction.
13→6 FSharp.Compiler.AbstractIL.IL uses System✕
- Connections
- 106 pairs of types, where a type in FSharp.Compiler.AbstractIL.IL uses a type in System. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.AbstractIL.IL.IL→System.Lazy`1FSharp.Compiler.AbstractIL.IL.ILAlignment→System.IComparableFSharp.Compiler.AbstractIL.IL.ILAlignment→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILArgConvention→System.IComparableFSharp.Compiler.AbstractIL.IL.ILArgConvention→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILArrayShape→System.IComparableFSharp.Compiler.AbstractIL.IL.ILArrayShape→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILAssemblyLongevity→System.IComparableFSharp.Compiler.AbstractIL.IL.ILAssemblyLongevity→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILAssemblyRef→System.IComparableFSharp.Compiler.AbstractIL.IL.ILAttribElem→System.IComparableFSharp.Compiler.AbstractIL.IL.ILAttribElem→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILAttribute→System.IComparableFSharp.Compiler.AbstractIL.IL.ILAttribute→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILBasicType→System.IComparableFSharp.Compiler.AbstractIL.IL.ILBasicType→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILBoxity→System.IComparableFSharp.Compiler.AbstractIL.IL.ILBoxity→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILCallingConv→System.IComparableFSharp.Compiler.AbstractIL.IL.ILCallingConv→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILCallingSignature→System.IComparableFSharp.Compiler.AbstractIL.IL.ILCallingSignature→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILComparisonInstr→System.IComparableFSharp.Compiler.AbstractIL.IL.ILComparisonInstr→System.IComparable`1FSharp.Compiler.AbstractIL.IL.ILConst→System.IComparable
- Direction
- FSharp.Compiler.AbstractIL.IL uses System, so a change to System can break FSharp.Compiler.AbstractIL.IL, while a change to FSharp.Compiler.AbstractIL.IL can't break System.
- Position
- Below the diagonal: FSharp.Compiler.AbstractIL.IL uses a module listed above it, which is the healthy direction.
13→11 FSharp.Compiler.AbstractIL.IL uses Internal.Utilities.Library✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.AbstractIL.IL uses a type in Internal.Utilities.Library.
- The types involved
FSharp.Compiler.AbstractIL.IL.IL→Internal.Utilities.Library.InterruptibleLazy`1FSharp.Compiler.AbstractIL.IL.ILMethodDef→Internal.Utilities.Library.InterruptibleLazy`1FSharp.Compiler.AbstractIL.IL.ILMethodDefs→Internal.Utilities.Library.DelayInitArrayMap`3FSharp.Compiler.AbstractIL.IL.ILTypeDef→Internal.Utilities.Library.InterruptibleLazy`1FSharp.Compiler.AbstractIL.IL.ILTypeDefs→Internal.Utilities.Library.DelayInitArrayMap`3FSharp.Compiler.AbstractIL.IL.MethodBody→Internal.Utilities.Library.InterruptibleLazy`1
- Direction
- FSharp.Compiler.AbstractIL.IL uses Internal.Utilities.Library, so a change to Internal.Utilities.Library can break FSharp.Compiler.AbstractIL.IL, while a change to FSharp.Compiler.AbstractIL.IL can't break Internal.Utilities.Library.
- Position
- Below the diagonal: FSharp.Compiler.AbstractIL.IL uses a module listed above it, which is the healthy direction.
14→2 FSharp.Compiler.Syntax uses System.Collections✕
- Connections
- 28 pairs of types, where a type in FSharp.Compiler.Syntax uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.Syntax.DebugPointAtBinding→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtFinally→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtFor→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtInOrTo→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtLeafExpr→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtSequential→System.Collections.IStructuralComparableFSharp.Compiler.Syntax.DebugPointAtSequential→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtTarget→System.Collections.IStructuralComparableFSharp.Compiler.Syntax.DebugPointAtTarget→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtTry→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtWhile→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.DebugPointAtWith→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.ParserDetail→System.Collections.IStructuralComparableFSharp.Compiler.Syntax.ParserDetail→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.SeqExprOnly→System.Collections.IStructuralComparableFSharp.Compiler.Syntax.SeqExprOnly→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.SynAccess→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.SynBindingKind→System.Collections.IStructuralComparableFSharp.Compiler.Syntax.SynBindingKind→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.SynByteStringKind→System.Collections.IStructuralComparableFSharp.Compiler.Syntax.SynByteStringKind→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.SynMemberKind→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.SynModuleOrNamespaceKind→System.Collections.IStructuralComparableFSharp.Compiler.Syntax.SynModuleOrNamespaceKind→System.Collections.IStructuralEquatableFSharp.Compiler.Syntax.SynStringKind→System.Collections.IStructuralComparable
- Direction
- FSharp.Compiler.Syntax uses System.Collections, so a change to System.Collections can break FSharp.Compiler.Syntax, while a change to FSharp.Compiler.Syntax can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.Syntax uses a module listed above it, which is the healthy direction.
14→6 FSharp.Compiler.Syntax uses System✕
- Connections
- 19 pairs of types, where a type in FSharp.Compiler.Syntax uses a type in System.
- The types involved
FSharp.Compiler.Syntax.DebugPointAtSequential→System.IComparableFSharp.Compiler.Syntax.DebugPointAtSequential→System.IComparable`1FSharp.Compiler.Syntax.DebugPointAtTarget→System.IComparableFSharp.Compiler.Syntax.DebugPointAtTarget→System.IComparable`1FSharp.Compiler.Syntax.ExprAtomicFlag→System.EnumFSharp.Compiler.Syntax.ParserDetail→System.IComparableFSharp.Compiler.Syntax.ParserDetail→System.IComparable`1FSharp.Compiler.Syntax.SeqExprOnly→System.IComparableFSharp.Compiler.Syntax.SeqExprOnly→System.IComparable`1FSharp.Compiler.Syntax.SynBindingKind→System.IComparableFSharp.Compiler.Syntax.SynBindingKind→System.IComparable`1FSharp.Compiler.Syntax.SynByteStringKind→System.IComparableFSharp.Compiler.Syntax.SynByteStringKind→System.IComparable`1FSharp.Compiler.Syntax.SynModuleOrNamespaceKind→System.IComparableFSharp.Compiler.Syntax.SynModuleOrNamespaceKind→System.IComparable`1FSharp.Compiler.Syntax.SynStringKind→System.IComparableFSharp.Compiler.Syntax.SynStringKind→System.IComparable`1FSharp.Compiler.Syntax.TyparStaticReq→System.IComparableFSharp.Compiler.Syntax.TyparStaticReq→System.IComparable`1
- Direction
- FSharp.Compiler.Syntax uses System, so a change to System can break FSharp.Compiler.Syntax, while a change to FSharp.Compiler.Syntax can't break System.
- Position
- Below the diagonal: FSharp.Compiler.Syntax uses a module listed above it, which is the healthy direction.
14→7 FSharp.Compiler.Syntax uses FSharp.Compiler.Text✕
- Connections
- 66 pairs of types, where a type in FSharp.Compiler.Syntax uses a type in FSharp.Compiler.Text. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.Syntax.DebugPointAtBinding→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.DebugPointAtFinally→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.DebugPointAtFor→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.DebugPointAtInOrTo→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.DebugPointAtLeafExpr→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.DebugPointAtTry→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.DebugPointAtWhile→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.DebugPointAtWith→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.Ident→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.NamePatPairField→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.ParsedHashDirective→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.ParsedHashDirectiveArgument→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.ParsedImplFileFragment→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.ParsedInput→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.ParsedScriptInteraction→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.ParsedSigFileFragment→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.QualifiedNameOfFile→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.SynAccess→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.SynArgPats→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.SynAttribute→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.SynAttributeList→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.SynBinding→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.SynBindingReturnInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.SynComponentInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Syntax.SynConst→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.Syntax uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.Syntax, while a change to FSharp.Compiler.Syntax can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.Syntax uses a module listed above it, which is the healthy direction.
15→2 Fable.AST.Fable uses System.Collections✕
- Connections
- 73 pairs of types, where a type in Fable.AST.Fable uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
Fable.AST.Fable.ActionDecl→System.Collections.IStructuralComparableFable.AST.Fable.ActionDecl→System.Collections.IStructuralEquatableFable.AST.Fable.ArrayKind→System.Collections.IStructuralComparableFable.AST.Fable.ArrayKind→System.Collections.IStructuralEquatableFable.AST.Fable.CallInfo→System.Collections.IStructuralComparableFable.AST.Fable.CallInfo→System.Collections.IStructuralEquatableFable.AST.Fable.ClassDecl→System.Collections.IStructuralComparableFable.AST.Fable.ClassDecl→System.Collections.IStructuralEquatableFable.AST.Fable.Constraint→System.Collections.IStructuralComparableFable.AST.Fable.Constraint→System.Collections.IStructuralEquatableFable.AST.Fable.Declaration→System.Collections.IStructuralComparableFable.AST.Fable.Declaration→System.Collections.IStructuralEquatableFable.AST.Fable.EmitInfo→System.Collections.IStructuralComparableFable.AST.Fable.EmitInfo→System.Collections.IStructuralEquatableFable.AST.Fable.EntityPath→System.Collections.IStructuralComparableFable.AST.Fable.EntityPath→System.Collections.IStructuralEquatableFable.AST.Fable.EntityRef→System.Collections.IStructuralComparableFable.AST.Fable.EntityRef→System.Collections.IStructuralEquatableFable.AST.Fable.Expr→System.Collections.IStructuralComparableFable.AST.Fable.Expr→System.Collections.IStructuralEquatableFable.AST.Fable.ExtendedSet→System.Collections.IStructuralComparableFable.AST.Fable.ExtendedSet→System.Collections.IStructuralEquatableFable.AST.Fable.FableError→System.Collections.IStructuralEquatableFable.AST.Fable.FieldInfo→System.Collections.IStructuralComparableFable.AST.Fable.FieldInfo→System.Collections.IStructuralEquatable
- Direction
- Fable.AST.Fable uses System.Collections, so a change to System.Collections can break Fable.AST.Fable, while a change to Fable.AST.Fable can't break System.Collections.
- Position
- Below the diagonal: Fable.AST.Fable uses a module listed above it, which is the healthy direction.
15→3 Fable.AST.Fable uses System.Collections.Generic✕
- Connections
- 4 pairs of types, where a type in Fable.AST.Fable uses a type in System.Collections.Generic.
- The types involved
Fable.AST.Fable.Entity→System.Collections.Generic.IEnumerable`1Fable.AST.Fable.GeneratedMember→System.Collections.Generic.IEnumerable`1Fable.AST.Fable.MemberFunctionOrValue→System.Collections.Generic.IEnumerable`1Fable.AST.Fable.Parameter→System.Collections.Generic.IEnumerable`1
- Direction
- Fable.AST.Fable uses System.Collections.Generic, so a change to System.Collections.Generic can break Fable.AST.Fable, while a change to Fable.AST.Fable can't break System.Collections.Generic.
- Position
- Below the diagonal: Fable.AST.Fable uses a module listed above it, which is the healthy direction.
15→6 Fable.AST.Fable uses System✕
- Connections
- 108 pairs of types, where a type in Fable.AST.Fable uses a type in System. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
Fable.AST.Fable.ActionDecl→System.IComparableFable.AST.Fable.ActionDecl→System.IComparable`1Fable.AST.Fable.ActionDecl→System.IEquatable`1Fable.AST.Fable.ArrayKind→System.IComparableFable.AST.Fable.ArrayKind→System.IComparable`1Fable.AST.Fable.ArrayKind→System.IEquatable`1Fable.AST.Fable.CallInfo→System.IComparableFable.AST.Fable.CallInfo→System.IComparable`1Fable.AST.Fable.CallInfo→System.IEquatable`1Fable.AST.Fable.ClassDecl→System.IComparableFable.AST.Fable.ClassDecl→System.IComparable`1Fable.AST.Fable.ClassDecl→System.IEquatable`1Fable.AST.Fable.Constraint→System.IComparableFable.AST.Fable.Constraint→System.IComparable`1Fable.AST.Fable.Constraint→System.IEquatable`1Fable.AST.Fable.Declaration→System.IComparableFable.AST.Fable.Declaration→System.IComparable`1Fable.AST.Fable.Declaration→System.IEquatable`1Fable.AST.Fable.EmitInfo→System.IComparableFable.AST.Fable.EmitInfo→System.IComparable`1Fable.AST.Fable.EmitInfo→System.IEquatable`1Fable.AST.Fable.EntityPath→System.IComparableFable.AST.Fable.EntityPath→System.IComparable`1Fable.AST.Fable.EntityPath→System.IEquatable`1Fable.AST.Fable.EntityRef→System.IComparable
- Direction
- Fable.AST.Fable uses System, so a change to System can break Fable.AST.Fable, while a change to Fable.AST.Fable can't break System.
- Position
- Below the diagonal: Fable.AST.Fable uses a module listed above it, which is the healthy direction.
15→8 Fable.AST.Fable uses Fable.AST✕
- Connections
- 7 pairs of types, where a type in Fable.AST.Fable uses a type in Fable.AST.
- The types involved
Fable.AST.Fable.Expr→Fable.AST.SourceLocationFable.AST.Fable.Ident→Fable.AST.SourceLocationFable.AST.Fable.OperationKind→Fable.AST.BinaryOperatorFable.AST.Fable.OperationKind→Fable.AST.LogicalOperatorFable.AST.Fable.OperationKind→Fable.AST.UnaryOperatorFable.AST.Fable.Type→Fable.AST.NumberKindFable.AST.Fable.ValueKind→Fable.AST.RegexFlag
- Direction
- Fable.AST.Fable uses Fable.AST, so a change to Fable.AST can break Fable.AST.Fable, while a change to Fable.AST.Fable can't break Fable.AST.
- Position
- Below the diagonal: Fable.AST.Fable uses a module listed above it, which is the healthy direction.
16→2 Fable.Transforms.Python.AST uses System.Collections✕
- Connections
- 73 pairs of types, where a type in Fable.Transforms.Python.AST uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
Fable.Transforms.Python.AST.AST→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Alias→System.Collections.IStructuralComparableFable.Transforms.Python.AST.Alias→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.AnnAssign→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Arg→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Arguments→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Assert→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Assign→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.AsyncFor→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.AsyncFunctionDef→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Attribute→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.BinOp→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.BoolOp→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.BoolOperator→System.Collections.IStructuralComparableFable.Transforms.Python.AST.BoolOperator→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Call→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.ClassDef→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Compare→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.ComparisonOperator→System.Collections.IStructuralComparableFable.Transforms.Python.AST.ComparisonOperator→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Dict→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Emit→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.ExceptHandler→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Expr→System.Collections.IStructuralEquatableFable.Transforms.Python.AST.Expression→System.Collections.IStructuralEquatable
- Direction
- Fable.Transforms.Python.AST uses System.Collections, so a change to System.Collections can break Fable.Transforms.Python.AST, while a change to Fable.Transforms.Python.AST can't break System.Collections.
- Position
- Below the diagonal: Fable.Transforms.Python.AST uses a module listed above it, which is the healthy direction.
16→6 Fable.Transforms.Python.AST uses System✕
- Connections
- 85 pairs of types, where a type in Fable.Transforms.Python.AST uses a type in System. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
Fable.Transforms.Python.AST.AST→System.IEquatable`1Fable.Transforms.Python.AST.Alias→System.IComparableFable.Transforms.Python.AST.Alias→System.IComparable`1Fable.Transforms.Python.AST.Alias→System.IEquatable`1Fable.Transforms.Python.AST.AnnAssign→System.IEquatable`1Fable.Transforms.Python.AST.Arg→System.IEquatable`1Fable.Transforms.Python.AST.Arguments→System.IEquatable`1Fable.Transforms.Python.AST.Assert→System.IEquatable`1Fable.Transforms.Python.AST.Assign→System.IEquatable`1Fable.Transforms.Python.AST.AsyncFor→System.IEquatable`1Fable.Transforms.Python.AST.AsyncFunctionDef→System.IEquatable`1Fable.Transforms.Python.AST.Attribute→System.IEquatable`1Fable.Transforms.Python.AST.BinOp→System.IEquatable`1Fable.Transforms.Python.AST.BoolOp→System.IEquatable`1Fable.Transforms.Python.AST.BoolOperator→System.IComparableFable.Transforms.Python.AST.BoolOperator→System.IComparable`1Fable.Transforms.Python.AST.BoolOperator→System.IEquatable`1Fable.Transforms.Python.AST.Call→System.IEquatable`1Fable.Transforms.Python.AST.ClassDef→System.IEquatable`1Fable.Transforms.Python.AST.Compare→System.IEquatable`1Fable.Transforms.Python.AST.ComparisonOperator→System.IComparableFable.Transforms.Python.AST.ComparisonOperator→System.IComparable`1Fable.Transforms.Python.AST.ComparisonOperator→System.IEquatable`1Fable.Transforms.Python.AST.Dict→System.IEquatable`1Fable.Transforms.Python.AST.Emit→System.IEquatable`1
- Direction
- Fable.Transforms.Python.AST uses System, so a change to System can break Fable.Transforms.Python.AST, while a change to Fable.Transforms.Python.AST can't break System.
- Position
- Below the diagonal: Fable.Transforms.Python.AST uses a module listed above it, which is the healthy direction.
16→8 Fable.Transforms.Python.AST uses Fable.AST✕
- Connections
- 21 pairs of types, where a type in Fable.Transforms.Python.AST uses a type in Fable.AST.
- The types involved
Fable.Transforms.Python.AST.BinOp→Fable.AST.SourceLocationFable.Transforms.Python.AST.BoolOp→Fable.AST.SourceLocationFable.Transforms.Python.AST.Call→Fable.AST.SourceLocationFable.Transforms.Python.AST.ClassDef→Fable.AST.SourceLocationFable.Transforms.Python.AST.Compare→Fable.AST.SourceLocationFable.Transforms.Python.AST.Emit→Fable.AST.SourceLocationFable.Transforms.Python.AST.ExceptHandler→Fable.AST.SourceLocationFable.Transforms.Python.AST.Expression→Fable.AST.SourceLocationFable.Transforms.Python.AST.If→Fable.AST.SourceLocationFable.Transforms.Python.AST.IfExp→Fable.AST.SourceLocationFable.Transforms.Python.AST.Match→Fable.AST.SourceLocationFable.Transforms.Python.AST.Name→Fable.AST.SourceLocationFable.Transforms.Python.AST.NamedExpr→Fable.AST.SourceLocationFable.Transforms.Python.AST.ParamSpecParam→Fable.AST.SourceLocationFable.Transforms.Python.AST.Try→Fable.AST.SourceLocationFable.Transforms.Python.AST.Tuple→Fable.AST.SourceLocationFable.Transforms.Python.AST.TypeAlias→Fable.AST.SourceLocationFable.Transforms.Python.AST.TypeVarParam→Fable.AST.SourceLocationFable.Transforms.Python.AST.TypeVarTupleParam→Fable.AST.SourceLocationFable.Transforms.Python.AST.UnaryOp→Fable.AST.SourceLocationFable.Transforms.Python.AST.While→Fable.AST.SourceLocation
- Direction
- Fable.Transforms.Python.AST uses Fable.AST, so a change to Fable.AST can break Fable.Transforms.Python.AST, while a change to Fable.Transforms.Python.AST can't break Fable.AST.
- Position
- Below the diagonal: Fable.Transforms.Python.AST uses a module listed above it, which is the healthy direction.
17→2 Internal.Utilities.Text.Lexing uses System.Collections✕
- Connections
- 2 pairs of types, where a type in Internal.Utilities.Text.Lexing uses a type in System.Collections.
- The types involved
Internal.Utilities.Text.Lexing.Position→System.Collections.IStructuralComparableInternal.Utilities.Text.Lexing.Position→System.Collections.IStructuralEquatable
- Direction
- Internal.Utilities.Text.Lexing uses System.Collections, so a change to System.Collections can break Internal.Utilities.Text.Lexing, while a change to Internal.Utilities.Text.Lexing can't break System.Collections.
- Position
- Below the diagonal: Internal.Utilities.Text.Lexing uses a module listed above it, which is the healthy direction.
17→3 Internal.Utilities.Text.Lexing uses System.Collections.Generic✕
- Connections
- 1 pair of types, where a type in Internal.Utilities.Text.Lexing uses a type in System.Collections.Generic.
- The types involved
Internal.Utilities.Text.Lexing.LexBuffer`1→System.Collections.Generic.IDictionary`2
- Direction
- Internal.Utilities.Text.Lexing uses System.Collections.Generic, so a change to System.Collections.Generic can break Internal.Utilities.Text.Lexing, while a change to Internal.Utilities.Text.Lexing can't break System.Collections.Generic.
- Position
- Below the diagonal: Internal.Utilities.Text.Lexing uses a module listed above it, which is the healthy direction.
17→6 Internal.Utilities.Text.Lexing uses System✕
- Connections
- 2 pairs of types, where a type in Internal.Utilities.Text.Lexing uses a type in System.
- The types involved
Internal.Utilities.Text.Lexing.Position→System.IComparableInternal.Utilities.Text.Lexing.Position→System.IComparable`1
- Direction
- Internal.Utilities.Text.Lexing uses System, so a change to System can break Internal.Utilities.Text.Lexing, while a change to Internal.Utilities.Text.Lexing can't break System.
- Position
- Below the diagonal: Internal.Utilities.Text.Lexing uses a module listed above it, which is the healthy direction.
17→7 Internal.Utilities.Text.Lexing uses FSharp.Compiler.Text✕
- Connections
- 2 pairs of types, where a type in Internal.Utilities.Text.Lexing uses a type in FSharp.Compiler.Text.
- The types involved
Internal.Utilities.Text.Lexing.LexBuffer`1→FSharp.Compiler.Text.ISourceTextInternal.Utilities.Text.Lexing.LexBuffer`1→FSharp.Compiler.Text.Range
- Direction
- Internal.Utilities.Text.Lexing uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break Internal.Utilities.Text.Lexing, while a change to Internal.Utilities.Text.Lexing can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: Internal.Utilities.Text.Lexing uses a module listed above it, which is the healthy direction.
18→2 FSharp.Compiler.TypedTree uses System.Collections✕
- Connections
- 48 pairs of types, where a type in FSharp.Compiler.TypedTree uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.TypedTree.Accessibility→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.CcuTypeForwarderTable→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.CcuTypeForwarderTree→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.CompilationPath→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.Const→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.Const→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.EntityFlags→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.EntityFlags→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.ForLoopStyle→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.ForLoopStyle→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.InternalUndefinedItemRef→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.LValueOperation→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.LValueOperation→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.NullnessInfo→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.NullnessInfo→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.PublicPath→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.PublicPath→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.RecordConstructionInfo→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.RecordConstructionInfo→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.SequentialOpKind→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.SequentialOpKind→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.SpecialWhileLoopMarker→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.SpecialWhileLoopMarker→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTree.SyntaxAccess→System.Collections.IStructuralComparableFSharp.Compiler.TypedTree.SyntaxAccess→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.TypedTree uses System.Collections, so a change to System.Collections can break FSharp.Compiler.TypedTree, while a change to FSharp.Compiler.TypedTree can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.TypedTree uses a module listed above it, which is the healthy direction.
18→3 FSharp.Compiler.TypedTree uses System.Collections.Generic✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.TypedTree uses a type in System.Collections.Generic.
- The types involved
FSharp.Compiler.TypedTree.FreeTyvars→System.Collections.Generic.IComparer`1FSharp.Compiler.TypedTree.FreeVars→System.Collections.Generic.IComparer`1
- Direction
- FSharp.Compiler.TypedTree uses System.Collections.Generic, so a change to System.Collections.Generic can break FSharp.Compiler.TypedTree, while a change to FSharp.Compiler.TypedTree can't break System.Collections.Generic.
- Position
- Below the diagonal: FSharp.Compiler.TypedTree uses a module listed above it, which is the healthy direction.
18→6 FSharp.Compiler.TypedTree uses System✕
- Connections
- 46 pairs of types, where a type in FSharp.Compiler.TypedTree uses a type in System. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.TypedTree.CcuTypeForwarderTable→System.Lazy`1FSharp.Compiler.TypedTree.CcuTypeForwarderTree→System.Lazy`1FSharp.Compiler.TypedTree.Const→System.IComparableFSharp.Compiler.TypedTree.Const→System.IComparable`1FSharp.Compiler.TypedTree.EntityFlags→System.IComparableFSharp.Compiler.TypedTree.EntityFlags→System.IComparable`1FSharp.Compiler.TypedTree.ForLoopStyle→System.IComparableFSharp.Compiler.TypedTree.ForLoopStyle→System.IComparable`1FSharp.Compiler.TypedTree.LValueOperation→System.IComparableFSharp.Compiler.TypedTree.LValueOperation→System.IComparable`1FSharp.Compiler.TypedTree.NamedDebugPointKey→System.IComparableFSharp.Compiler.TypedTree.NullnessInfo→System.IComparableFSharp.Compiler.TypedTree.NullnessInfo→System.IComparable`1FSharp.Compiler.TypedTree.PublicPath→System.IComparableFSharp.Compiler.TypedTree.PublicPath→System.IComparable`1FSharp.Compiler.TypedTree.RecordConstructionInfo→System.IComparableFSharp.Compiler.TypedTree.RecordConstructionInfo→System.IComparable`1FSharp.Compiler.TypedTree.SequentialOpKind→System.IComparableFSharp.Compiler.TypedTree.SequentialOpKind→System.IComparable`1FSharp.Compiler.TypedTree.SpecialWhileLoopMarker→System.IComparableFSharp.Compiler.TypedTree.SpecialWhileLoopMarker→System.IComparable`1FSharp.Compiler.TypedTree.SyntaxAccess→System.IComparableFSharp.Compiler.TypedTree.SyntaxAccess→System.IComparable`1FSharp.Compiler.TypedTree.TraitWitnessInfo→System.IComparableFSharp.Compiler.TypedTree.TupInfo→System.IComparable
- Direction
- FSharp.Compiler.TypedTree uses System, so a change to System can break FSharp.Compiler.TypedTree, while a change to FSharp.Compiler.TypedTree can't break System.
- Position
- Below the diagonal: FSharp.Compiler.TypedTree uses a module listed above it, which is the healthy direction.
18→7 FSharp.Compiler.TypedTree uses FSharp.Compiler.Text✕
- Connections
- 22 pairs of types, where a type in FSharp.Compiler.TypedTree uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.TypedTree.ArgReprInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.Attrib→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.CheckedImplFile→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.Construct→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.DecisionTree→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.DecisionTreeTest→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.Entity→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.EntityRef→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.Expr→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.Measure→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.ModuleOrNamespaceContents→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.NamedDebugPointKey→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.ObjExprMethod→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.OpenDeclaration→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.RecdField→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.RecdFieldRef→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.Typar→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.TyparConstraint→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.UnionCase→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.UnionCaseRef→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.Val→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTree.ValRef→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.TypedTree uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.TypedTree, while a change to FSharp.Compiler.TypedTree can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.TypedTree uses a module listed above it, which is the healthy direction.
18→10 FSharp.Compiler.TypedTree uses Internal.Utilities.Collections.Tagged✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.TypedTree uses a type in Internal.Utilities.Collections.Tagged.
- The types involved
FSharp.Compiler.TypedTree.FreeTyvars→Internal.Utilities.Collections.Tagged.Set`2FSharp.Compiler.TypedTree.FreeVars→Internal.Utilities.Collections.Tagged.Set`2
- Direction
- FSharp.Compiler.TypedTree uses Internal.Utilities.Collections.Tagged, so a change to Internal.Utilities.Collections.Tagged can break FSharp.Compiler.TypedTree, while a change to FSharp.Compiler.TypedTree can't break Internal.Utilities.Collections.Tagged.
- Position
- Below the diagonal: FSharp.Compiler.TypedTree uses a module listed above it, which is the healthy direction.
18→11 FSharp.Compiler.TypedTree uses Internal.Utilities.Library✕
- Connections
- 3 pairs of types, where a type in FSharp.Compiler.TypedTree uses a type in Internal.Utilities.Library.
- The types involved
FSharp.Compiler.TypedTree.Construct→Internal.Utilities.Library.LazyWithContext`2FSharp.Compiler.TypedTree.Entity→Internal.Utilities.Library.LazyWithContext`2FSharp.Compiler.TypedTree.ModuleOrNamespaceType→Internal.Utilities.Library.LayeredMultiMap`2
- Direction
- FSharp.Compiler.TypedTree uses Internal.Utilities.Library, so a change to Internal.Utilities.Library can break FSharp.Compiler.TypedTree, while a change to FSharp.Compiler.TypedTree can't break Internal.Utilities.Library.
- Position
- Below the diagonal: FSharp.Compiler.TypedTree uses a module listed above it, which is the healthy direction.
18→13 FSharp.Compiler.TypedTree uses FSharp.Compiler.AbstractIL.IL✕
- Connections
- 26 pairs of types, where a type in FSharp.Compiler.TypedTree uses a type in FSharp.Compiler.AbstractIL.IL. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.TypedTree.Accessibility→FSharp.Compiler.AbstractIL.IL.ILMemberAccessFSharp.Compiler.TypedTree.Accessibility→FSharp.Compiler.AbstractIL.IL.ILTypeDefAccessFSharp.Compiler.TypedTree.AnonRecdTypeInfo→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.TypedTree.AttribKind→FSharp.Compiler.AbstractIL.IL.ILMethodRefFSharp.Compiler.TypedTree.CcuData→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.TypedTree.CcuThunk→FSharp.Compiler.AbstractIL.IL.ILModuleDefFSharp.Compiler.TypedTree.CcuThunk→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.TypedTree.CompilationPath→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.TypedTree.CompiledTypeRepr→FSharp.Compiler.AbstractIL.IL.ILBoxityFSharp.Compiler.TypedTree.CompiledTypeRepr→FSharp.Compiler.AbstractIL.IL.ILTypeFSharp.Compiler.TypedTree.CompiledTypeRepr→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.TypedTree.Construct→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.TypedTree.Construct→FSharp.Compiler.AbstractIL.IL.ILTypeDefFSharp.Compiler.TypedTree.Entity→FSharp.Compiler.AbstractIL.IL.ILTypeDefFSharp.Compiler.TypedTree.Entity→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.TypedTree.EntityRef→FSharp.Compiler.AbstractIL.IL.ILTypeDefFSharp.Compiler.TypedTree.EntityRef→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.TypedTree.ExceptionInfo→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.TypedTree.TILObjectReprData→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.TypedTree.TILObjectReprData→FSharp.Compiler.AbstractIL.IL.ILTypeDefFSharp.Compiler.TypedTree.TOp→FSharp.Compiler.AbstractIL.IL.ILInstrFSharp.Compiler.TypedTree.TOp→FSharp.Compiler.AbstractIL.IL.ILMethodRefFSharp.Compiler.TypedTree.TraitConstraintSln→FSharp.Compiler.AbstractIL.IL.ILMethodRefFSharp.Compiler.TypedTree.TraitConstraintSln→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.TypedTree.TyconRepresentation→FSharp.Compiler.AbstractIL.IL.ILType
- Direction
- FSharp.Compiler.TypedTree uses FSharp.Compiler.AbstractIL.IL, so a change to FSharp.Compiler.AbstractIL.IL can break FSharp.Compiler.TypedTree, while a change to FSharp.Compiler.TypedTree can't break FSharp.Compiler.AbstractIL.IL.
- Position
- Below the diagonal: FSharp.Compiler.TypedTree uses a module listed above it, which is the healthy direction.
18→14 FSharp.Compiler.TypedTree uses FSharp.Compiler.Syntax✕
- Connections
- 32 pairs of types, where a type in FSharp.Compiler.TypedTree uses a type in FSharp.Compiler.Syntax. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.TypedTree.AnonRecdTypeInfo→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.ArgReprInfo→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.Binding→FSharp.Compiler.Syntax.DebugPointAtBindingFSharp.Compiler.TypedTree.CheckedImplFile→FSharp.Compiler.Syntax.QualifiedNameOfFileFSharp.Compiler.TypedTree.CompilationPath→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.Construct→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.Construct→FSharp.Compiler.Syntax.SynTyparFSharp.Compiler.TypedTree.Entity→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.EntityRef→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.Expr→FSharp.Compiler.Syntax.DebugPointAtBindingFSharp.Compiler.TypedTree.Expr→FSharp.Compiler.Syntax.DebugPointAtLeafExprFSharp.Compiler.TypedTree.ObjExprMethod→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.OpenDeclaration→FSharp.Compiler.Syntax.SynOpenDeclTargetFSharp.Compiler.TypedTree.RecdField→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.TOp→FSharp.Compiler.Syntax.DebugPointAtFinallyFSharp.Compiler.TypedTree.TOp→FSharp.Compiler.Syntax.DebugPointAtForFSharp.Compiler.TypedTree.TOp→FSharp.Compiler.Syntax.DebugPointAtInOrToFSharp.Compiler.TypedTree.TOp→FSharp.Compiler.Syntax.DebugPointAtTryFSharp.Compiler.TypedTree.TOp→FSharp.Compiler.Syntax.DebugPointAtWhileFSharp.Compiler.TypedTree.TOp→FSharp.Compiler.Syntax.DebugPointAtWithFSharp.Compiler.TypedTree.TraitConstraintInfo→FSharp.Compiler.Syntax.SynMemberFlagsFSharp.Compiler.TypedTree.TraitConstraintInfo→FSharp.Compiler.Syntax.SynMemberKindFSharp.Compiler.TypedTree.TraitWitnessInfo→FSharp.Compiler.Syntax.SynMemberFlagsFSharp.Compiler.TypedTree.Typar→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTree.Typar→FSharp.Compiler.Syntax.TyparStaticReq
- Direction
- FSharp.Compiler.TypedTree uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.TypedTree, while a change to FSharp.Compiler.TypedTree can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.TypedTree uses a module listed above it, which is the healthy direction.
19→2 FSharp.Compiler.TcGlobals uses System.Collections✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.TcGlobals uses a type in System.Collections.
- The types involved
FSharp.Compiler.TcGlobals.CompilationMode→System.Collections.IStructuralComparableFSharp.Compiler.TcGlobals.CompilationMode→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.TcGlobals uses System.Collections, so a change to System.Collections can break FSharp.Compiler.TcGlobals, while a change to FSharp.Compiler.TcGlobals can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.TcGlobals uses a module listed above it, which is the healthy direction.
19→6 FSharp.Compiler.TcGlobals uses System✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.TcGlobals uses a type in System.
- The types involved
FSharp.Compiler.TcGlobals.CompilationMode→System.IComparableFSharp.Compiler.TcGlobals.CompilationMode→System.IComparable`1
- Direction
- FSharp.Compiler.TcGlobals uses System, so a change to System can break FSharp.Compiler.TcGlobals, while a change to FSharp.Compiler.TcGlobals can't break System.
- Position
- Below the diagonal: FSharp.Compiler.TcGlobals uses a module listed above it, which is the healthy direction.
19→13 FSharp.Compiler.TcGlobals uses FSharp.Compiler.AbstractIL.IL✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.TcGlobals uses a type in FSharp.Compiler.AbstractIL.IL.
- The types involved
FSharp.Compiler.TcGlobals.BuiltinAttribInfo→FSharp.Compiler.AbstractIL.IL.ILTypeRef
- Direction
- FSharp.Compiler.TcGlobals uses FSharp.Compiler.AbstractIL.IL, so a change to FSharp.Compiler.AbstractIL.IL can break FSharp.Compiler.TcGlobals, while a change to FSharp.Compiler.TcGlobals can't break FSharp.Compiler.AbstractIL.IL.
- Position
- Below the diagonal: FSharp.Compiler.TcGlobals uses a module listed above it, which is the healthy direction.
19→18 FSharp.Compiler.TcGlobals uses FSharp.Compiler.TypedTree✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.TcGlobals uses a type in FSharp.Compiler.TypedTree.
- The types involved
FSharp.Compiler.TcGlobals.BuiltinAttribInfo→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.TcGlobals.IntrinsicValRef→FSharp.Compiler.TypedTree.NonLocalEntityRefFSharp.Compiler.TcGlobals.IntrinsicValRef→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.TcGlobals.IntrinsicValRef→FSharp.Compiler.TypedTree.ValLinkageFullKeyFSharp.Compiler.TcGlobals.TcGlobals→FSharp.Compiler.TypedTree.ValRef
- Direction
- FSharp.Compiler.TcGlobals uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.TcGlobals, while a change to FSharp.Compiler.TcGlobals can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.TcGlobals uses a module listed above it, which is the healthy direction.
20→7 FSharp.Compiler.Import uses FSharp.Compiler.Text✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.Import uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.Import.AssemblyLoader→FSharp.Compiler.Text.RangeFSharp.Compiler.Import.Import→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.Import uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.Import, while a change to FSharp.Compiler.Import can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.Import uses a module listed above it, which is the healthy direction.
20→11 FSharp.Compiler.Import uses Internal.Utilities.Library✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Import uses a type in Internal.Utilities.Library.
- The types involved
FSharp.Compiler.Import.AssemblyLoader→Internal.Utilities.Library.CompilationThreadToken
- Direction
- FSharp.Compiler.Import uses Internal.Utilities.Library, so a change to Internal.Utilities.Library can break FSharp.Compiler.Import, while a change to FSharp.Compiler.Import can't break Internal.Utilities.Library.
- Position
- Below the diagonal: FSharp.Compiler.Import uses a module listed above it, which is the healthy direction.
20→13 FSharp.Compiler.Import uses FSharp.Compiler.AbstractIL.IL✕
- Connections
- 7 pairs of types, where a type in FSharp.Compiler.Import uses a type in FSharp.Compiler.AbstractIL.IL.
- The types involved
FSharp.Compiler.Import.AssemblyLoader→FSharp.Compiler.AbstractIL.IL.ILAssemblyRefFSharp.Compiler.Import.Import→FSharp.Compiler.AbstractIL.IL.ILExportedTypesAndForwardersFSharp.Compiler.Import.Import→FSharp.Compiler.AbstractIL.IL.ILGenericParameterDefFSharp.Compiler.Import.Import→FSharp.Compiler.AbstractIL.IL.ILModuleDefFSharp.Compiler.Import.Import→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.Import.Import→FSharp.Compiler.AbstractIL.IL.ILTypeFSharp.Compiler.Import.Import→FSharp.Compiler.AbstractIL.IL.ILTypeRef
- Direction
- FSharp.Compiler.Import uses FSharp.Compiler.AbstractIL.IL, so a change to FSharp.Compiler.AbstractIL.IL can break FSharp.Compiler.Import, while a change to FSharp.Compiler.Import can't break FSharp.Compiler.AbstractIL.IL.
- Position
- Below the diagonal: FSharp.Compiler.Import uses a module listed above it, which is the healthy direction.
20→18 FSharp.Compiler.Import uses FSharp.Compiler.TypedTree✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.Import uses a type in FSharp.Compiler.TypedTree.
- The types involved
FSharp.Compiler.Import.AssemblyLoader→FSharp.Compiler.TypedTree.CcuResolutionResultFSharp.Compiler.Import.Import→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.Import.Import→FSharp.Compiler.TypedTree.CcuTypeForwarderTableFSharp.Compiler.Import.Import→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Import.Import→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Import.Import→FSharp.Compiler.TypedTree.Typar
- Direction
- FSharp.Compiler.Import uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.Import, while a change to FSharp.Compiler.Import can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.Import uses a module listed above it, which is the healthy direction.
20→19 FSharp.Compiler.Import uses FSharp.Compiler.TcGlobals✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Import uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.Import.ImportMap→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.Import uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.Import, while a change to FSharp.Compiler.Import can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.Import uses a module listed above it, which is the healthy direction.
21→2 FSharp.Compiler.InfoReader uses System.Collections✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.InfoReader uses a type in System.Collections.
- The types involved
FSharp.Compiler.InfoReader.FindMemberFlag→System.Collections.IStructuralComparableFSharp.Compiler.InfoReader.FindMemberFlag→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.InfoReader uses System.Collections, so a change to System.Collections can break FSharp.Compiler.InfoReader, while a change to FSharp.Compiler.InfoReader can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.InfoReader uses a module listed above it, which is the healthy direction.
21→6 FSharp.Compiler.InfoReader uses System✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.InfoReader uses a type in System.
- The types involved
FSharp.Compiler.InfoReader.FindMemberFlag→System.IComparableFSharp.Compiler.InfoReader.FindMemberFlag→System.IComparable`1
- Direction
- FSharp.Compiler.InfoReader uses System, so a change to System can break FSharp.Compiler.InfoReader, while a change to FSharp.Compiler.InfoReader can't break System.
- Position
- Below the diagonal: FSharp.Compiler.InfoReader uses a module listed above it, which is the healthy direction.
21→7 FSharp.Compiler.InfoReader uses FSharp.Compiler.Text✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.InfoReader uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.Text.RangeFSharp.Compiler.InfoReader.PropertyCollector→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.InfoReader uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.InfoReader, while a change to FSharp.Compiler.InfoReader can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.InfoReader uses a module listed above it, which is the healthy direction.
21→18 FSharp.Compiler.InfoReader uses FSharp.Compiler.TypedTree✕
- Connections
- 10 pairs of types, where a type in FSharp.Compiler.InfoReader uses a type in FSharp.Compiler.TypedTree.
- The types involved
FSharp.Compiler.InfoReader.HierarchyItem→FSharp.Compiler.TypedTree.TraitConstraintInfoFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.TypedTree.RecdFieldRefFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.TypedTree.UnionCaseRefFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.InfoReader.PropertyCollector→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.InfoReader.PropertyCollector→FSharp.Compiler.TypedTree.ValMemberInfoFSharp.Compiler.InfoReader.PropertyCollector→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.InfoReader.SigOfFunctionForDelegate→FSharp.Compiler.TypedTree.TType
- Direction
- FSharp.Compiler.InfoReader uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.InfoReader, while a change to FSharp.Compiler.InfoReader can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.InfoReader uses a module listed above it, which is the healthy direction.
21→19 FSharp.Compiler.InfoReader uses FSharp.Compiler.TcGlobals✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.InfoReader uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.InfoReader.PropertyCollector→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.InfoReader uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.InfoReader, while a change to FSharp.Compiler.InfoReader can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.InfoReader uses a module listed above it, which is the healthy direction.
21→20 FSharp.Compiler.InfoReader uses FSharp.Compiler.Import✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.InfoReader uses a type in FSharp.Compiler.Import.
- The types involved
FSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.Import.ImportMapFSharp.Compiler.InfoReader.PropertyCollector→FSharp.Compiler.Import.ImportMap
- Direction
- FSharp.Compiler.InfoReader uses FSharp.Compiler.Import, so a change to FSharp.Compiler.Import can break FSharp.Compiler.InfoReader, while a change to FSharp.Compiler.InfoReader can't break FSharp.Compiler.Import.
- Position
- Below the diagonal: FSharp.Compiler.InfoReader uses a module listed above it, which is the healthy direction.
21→28 FSharp.Compiler.InfoReader uses FSharp.Compiler.Infos part of a loop✕
- Connections
- 11 pairs of types, where a type in FSharp.Compiler.InfoReader uses a type in FSharp.Compiler.Infos.
- The types involved
FSharp.Compiler.InfoReader.HierarchyItem→FSharp.Compiler.Infos.EventInfoFSharp.Compiler.InfoReader.HierarchyItem→FSharp.Compiler.Infos.ILFieldInfoFSharp.Compiler.InfoReader.HierarchyItem→FSharp.Compiler.Infos.MethInfoFSharp.Compiler.InfoReader.HierarchyItem→FSharp.Compiler.Infos.PropInfoFSharp.Compiler.InfoReader.HierarchyItem→FSharp.Compiler.Infos.RecdFieldInfoFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.Infos.EventInfoFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.Infos.ILFieldInfoFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.Infos.MethInfoFSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.Infos.PropInfoFSharp.Compiler.InfoReader.PropertyCollector→FSharp.Compiler.Infos.PropInfoFSharp.Compiler.InfoReader.SigOfFunctionForDelegate→FSharp.Compiler.Infos.MethInfo
- Direction
- FSharp.Compiler.InfoReader uses FSharp.Compiler.Infos, so a change to FSharp.Compiler.Infos can break FSharp.Compiler.InfoReader, while a change to FSharp.Compiler.InfoReader can't break FSharp.Compiler.Infos.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
21→29 FSharp.Compiler.InfoReader uses FSharp.Compiler.AccessibilityLogic part of a loop✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.InfoReader uses a type in FSharp.Compiler.AccessibilityLogic.
- The types involved
FSharp.Compiler.InfoReader.InfoReader→FSharp.Compiler.AccessibilityLogic.AccessorDomainFSharp.Compiler.InfoReader.PropertyCollector→FSharp.Compiler.AccessibilityLogic.AccessorDomain
- Direction
- FSharp.Compiler.InfoReader uses FSharp.Compiler.AccessibilityLogic, so a change to FSharp.Compiler.AccessibilityLogic can break FSharp.Compiler.InfoReader, while a change to FSharp.Compiler.InfoReader can't break FSharp.Compiler.AccessibilityLogic.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→2 FSharp.Compiler.NameResolution uses System.Collections✕
- Connections
- 28 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.NameResolution.BulkAdd→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.BulkAdd→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.CheckForDuplicateTyparFlag→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.CheckForDuplicateTyparFlag→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.ExtraDotAfterIdentifier→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.ExtraDotAfterIdentifier→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.FormatStringCheckContext→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.FullyQualifiedFlag→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.FullyQualifiedFlag→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.IndeterminateType→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.ItemOccurrence→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.ItemOccurrence→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.LookupIsInstance→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.LookupIsInstance→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.LookupKind→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.LookupKind→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.PermitDirectReferenceToGeneratedType→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.PermitDirectReferenceToGeneratedType→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.ResultCollectionSettings→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.ResultCollectionSettings→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.ShouldNotifySink→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.ShouldNotifySink→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.TcResultsSink→System.Collections.IStructuralEquatableFSharp.Compiler.NameResolution.TypeNameResolutionFlag→System.Collections.IStructuralComparableFSharp.Compiler.NameResolution.TypeNameResolutionFlag→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.NameResolution uses System.Collections, so a change to System.Collections can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→6 FSharp.Compiler.NameResolution uses System✕
- Connections
- 25 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in System.
- The types involved
FSharp.Compiler.NameResolution.BulkAdd→System.IComparableFSharp.Compiler.NameResolution.BulkAdd→System.IComparable`1FSharp.Compiler.NameResolution.CheckForDuplicateTyparFlag→System.IComparableFSharp.Compiler.NameResolution.CheckForDuplicateTyparFlag→System.IComparable`1FSharp.Compiler.NameResolution.ExtraDotAfterIdentifier→System.IComparableFSharp.Compiler.NameResolution.ExtraDotAfterIdentifier→System.IComparable`1FSharp.Compiler.NameResolution.FullyQualifiedFlag→System.IComparableFSharp.Compiler.NameResolution.FullyQualifiedFlag→System.IComparable`1FSharp.Compiler.NameResolution.ItemOccurrence→System.IComparableFSharp.Compiler.NameResolution.ItemOccurrence→System.IComparable`1FSharp.Compiler.NameResolution.LookupIsInstance→System.IComparableFSharp.Compiler.NameResolution.LookupIsInstance→System.IComparable`1FSharp.Compiler.NameResolution.LookupKind→System.IComparableFSharp.Compiler.NameResolution.LookupKind→System.IComparable`1FSharp.Compiler.NameResolution.NameResolution→System.IDisposableFSharp.Compiler.NameResolution.PermitDirectReferenceToGeneratedType→System.IComparableFSharp.Compiler.NameResolution.PermitDirectReferenceToGeneratedType→System.IComparable`1FSharp.Compiler.NameResolution.ResultCollectionSettings→System.IComparableFSharp.Compiler.NameResolution.ResultCollectionSettings→System.IComparable`1FSharp.Compiler.NameResolution.ShouldNotifySink→System.IComparableFSharp.Compiler.NameResolution.ShouldNotifySink→System.IComparable`1FSharp.Compiler.NameResolution.TypeNameResolutionFlag→System.IComparableFSharp.Compiler.NameResolution.TypeNameResolutionFlag→System.IComparable`1FSharp.Compiler.NameResolution.WarnOnUpperFlag→System.IComparableFSharp.Compiler.NameResolution.WarnOnUpperFlag→System.IComparable`1
- Direction
- FSharp.Compiler.NameResolution uses System, so a change to System can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break System.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→7 FSharp.Compiler.NameResolution uses FSharp.Compiler.Text✕
- Connections
- 13 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.NameResolution.CapturedNameResolution→FSharp.Compiler.Text.PositionFSharp.Compiler.NameResolution.CapturedNameResolution→FSharp.Compiler.Text.RangeFSharp.Compiler.NameResolution.FormatStringCheckContext→FSharp.Compiler.Text.ISourceTextFSharp.Compiler.NameResolution.ITypecheckResultsSink→FSharp.Compiler.Text.ISourceTextFSharp.Compiler.NameResolution.ITypecheckResultsSink→FSharp.Compiler.Text.PositionFSharp.Compiler.NameResolution.ITypecheckResultsSink→FSharp.Compiler.Text.RangeFSharp.Compiler.NameResolution.IndeterminateType→FSharp.Compiler.Text.RangeFSharp.Compiler.NameResolution.Item→FSharp.Compiler.Text.RangeFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.Text.RangeFSharp.Compiler.NameResolution.NoConstructorsAvailableForType→FSharp.Compiler.Text.RangeFSharp.Compiler.NameResolution.TcResultsSinkImpl→FSharp.Compiler.Text.ISourceTextFSharp.Compiler.NameResolution.TcSymbolUseData→FSharp.Compiler.Text.RangeFSharp.Compiler.NameResolution.UpperCaseIdentifierInPattern→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→11 FSharp.Compiler.NameResolution uses Internal.Utilities.Library✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in Internal.Utilities.Library.
- The types involved
FSharp.Compiler.NameResolution.NameResolution→Internal.Utilities.Library.ResultOrException`1FSharp.Compiler.NameResolution.NameResolutionEnv→Internal.Utilities.Library.LayeredMultiMap`2
- Direction
- FSharp.Compiler.NameResolution uses Internal.Utilities.Library, so a change to Internal.Utilities.Library can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break Internal.Utilities.Library.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→14 FSharp.Compiler.NameResolution uses FSharp.Compiler.Syntax✕
- Connections
- 4 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.NameResolution.Item→FSharp.Compiler.Syntax.IdentFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.Syntax.IdentFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.Syntax.SynExprFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.Syntax.TyparStaticReq
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→18 FSharp.Compiler.NameResolution uses FSharp.Compiler.TypedTree✕
- Connections
- 31 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.TypedTree. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.NameResolution.ArgumentContainer→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.NameResolution.ExtensionMember→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.NameResolution.ExtensionMember→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.NameResolution.ITypecheckResultsSink→FSharp.Compiler.TypedTree.OpenDeclarationFSharp.Compiler.NameResolution.ITypecheckResultsSink→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.ActivePatternElemRefFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.AnonRecdTypeInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.ArgReprInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.TraitConstraintInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.TraitConstraintSlnFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.NameResolution.Item→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.ActivePatternElemRefFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.MeasureFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.OpenDeclarationFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.RecdFieldRefFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.TyparDynamicReqFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.TyparKindFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.TyparRigidityFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTree.ValRef
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→19 FSharp.Compiler.NameResolution uses FSharp.Compiler.TcGlobals✕
- Connections
- 4 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.NameResolution.NameResolutionEnv→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.NameResolution.NameResolver→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.NameResolution.TcResultsSinkImpl→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→20 FSharp.Compiler.NameResolution uses FSharp.Compiler.Import✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.Import.
- The types involved
FSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.Import.ImportMapFSharp.Compiler.NameResolution.NameResolver→FSharp.Compiler.Import.ImportMap
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.Import, so a change to FSharp.Compiler.Import can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.Import.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→21 FSharp.Compiler.NameResolution uses FSharp.Compiler.InfoReader✕
- Connections
- 3 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.InfoReader.
- The types involved
FSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.InfoReader.FindMemberFlagFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.InfoReader.InfoReaderFSharp.Compiler.NameResolution.NameResolver→FSharp.Compiler.InfoReader.InfoReader
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.InfoReader, so a change to FSharp.Compiler.InfoReader can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.InfoReader.
- Position
- Below the diagonal: FSharp.Compiler.NameResolution uses a module listed above it, which is the healthy direction.
22→27 FSharp.Compiler.NameResolution uses FSharp.Compiler.TypedTreeOps part of a loop✕
- Connections
- 7 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.TypedTreeOps.
- The types involved
FSharp.Compiler.NameResolution.CapturedNameResolution→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.NameResolution.NameResolutionEnv→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.NameResolution.NameResolutionEnv→FSharp.Compiler.TypedTreeOps.TyconRefMap`1FSharp.Compiler.NameResolution.NameResolutionEnv→FSharp.Compiler.TypedTreeOps.TyconRefMultiMap`1FSharp.Compiler.NameResolution.NoConstructorsAvailableForType→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.NameResolution.TcSymbolUseData→FSharp.Compiler.TypedTreeOps.DisplayEnv
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.TypedTreeOps, so a change to FSharp.Compiler.TypedTreeOps can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.TypedTreeOps.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→28 FSharp.Compiler.NameResolution uses FSharp.Compiler.Infos part of a loop✕
- Connections
- 12 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.Infos.
- The types involved
FSharp.Compiler.NameResolution.ArgumentContainer→FSharp.Compiler.Infos.MethInfoFSharp.Compiler.NameResolution.ExtensionMember→FSharp.Compiler.Infos.MethInfoFSharp.Compiler.NameResolution.FieldResolution→FSharp.Compiler.Infos.RecdFieldInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.Infos.EventInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.Infos.ILFieldInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.Infos.MethInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.Infos.PropInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.Infos.RecdFieldInfoFSharp.Compiler.NameResolution.Item→FSharp.Compiler.Infos.UnionCaseInfoFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.Infos.MethInfoFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.Infos.PropInfoFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.Infos.RecdFieldInfo
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.Infos, so a change to FSharp.Compiler.Infos can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.Infos.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
22→29 FSharp.Compiler.NameResolution uses FSharp.Compiler.AccessibilityLogic part of a loop✕
- Connections
- 3 pairs of types, where a type in FSharp.Compiler.NameResolution uses a type in FSharp.Compiler.AccessibilityLogic.
- The types involved
FSharp.Compiler.NameResolution.CapturedNameResolution→FSharp.Compiler.AccessibilityLogic.AccessorDomainFSharp.Compiler.NameResolution.ITypecheckResultsSink→FSharp.Compiler.AccessibilityLogic.AccessorDomainFSharp.Compiler.NameResolution.NameResolution→FSharp.Compiler.AccessibilityLogic.AccessorDomain
- Direction
- FSharp.Compiler.NameResolution uses FSharp.Compiler.AccessibilityLogic, so a change to FSharp.Compiler.AccessibilityLogic can break FSharp.Compiler.NameResolution, while a change to FSharp.Compiler.NameResolution can't break FSharp.Compiler.AccessibilityLogic.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
23→2 FSharp.Compiler.Symbols uses System.Collections✕
- Connections
- 4 pairs of types, where a type in FSharp.Compiler.Symbols uses a type in System.Collections.
- The types involved
FSharp.Compiler.Symbols.FSharpImplementationFileDeclaration→System.Collections.IStructuralEquatableFSharp.Compiler.Symbols.FSharpInlineAnnotation→System.Collections.IStructuralComparableFSharp.Compiler.Symbols.FSharpInlineAnnotation→System.Collections.IStructuralEquatableFSharp.Compiler.Symbols.FSharpXmlDoc→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.Symbols uses System.Collections, so a change to System.Collections can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→3 FSharp.Compiler.Symbols uses System.Collections.Generic✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.Symbols uses a type in System.Collections.Generic.
- The types involved
FSharp.Compiler.Symbols.FSharpAssemblySignature→System.Collections.Generic.IEnumerable`1FSharp.Compiler.Symbols.FSharpEntity→System.Collections.Generic.IEnumerable`1
- Direction
- FSharp.Compiler.Symbols uses System.Collections.Generic, so a change to System.Collections.Generic can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break System.Collections.Generic.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→6 FSharp.Compiler.Symbols uses System✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.Symbols uses a type in System.
- The types involved
FSharp.Compiler.Symbols.FSharpInlineAnnotation→System.IComparableFSharp.Compiler.Symbols.FSharpInlineAnnotation→System.IComparable`1
- Direction
- FSharp.Compiler.Symbols uses System, so a change to System can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break System.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→7 FSharp.Compiler.Symbols uses FSharp.Compiler.Text✕
- Connections
- 14 pairs of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.Symbols.FSharpActivePatternCase→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpAttribute→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpEntity→FSharp.Compiler.Text.ISourceTextFSharp.Compiler.Symbols.FSharpEntity→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpExpr→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpField→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpGenericParameter→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpMemberOrFunctionOrValue→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpMemberOrFunctionOrValue→FSharp.Compiler.Text.TaggedTextFSharp.Compiler.Symbols.FSharpOpenDeclaration→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpParameter→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpSymbol→FSharp.Compiler.Text.RangeFSharp.Compiler.Symbols.FSharpType→FSharp.Compiler.Text.TaggedTextFSharp.Compiler.Symbols.FSharpUnionCase→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→14 FSharp.Compiler.Symbols uses FSharp.Compiler.Syntax✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.Symbols.FSharpOpenDeclaration→FSharp.Compiler.Syntax.IdentFSharp.Compiler.Symbols.FSharpOpenDeclaration→FSharp.Compiler.Syntax.SynOpenDeclTarget
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→18 FSharp.Compiler.Symbols uses FSharp.Compiler.TypedTree✕
- Connections
- 23 pairs of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.TypedTree.
- The types involved
FSharp.Compiler.Symbols.FSharpAbstractSignature→FSharp.Compiler.TypedTree.SlotSigFSharp.Compiler.Symbols.FSharpAccessibility→FSharp.Compiler.TypedTree.AccessibilityFSharp.Compiler.Symbols.FSharpAccessibilityRights→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.Symbols.FSharpAssembly→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.Symbols.FSharpAssemblyContents→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.Symbols.FSharpAssemblyContents→FSharp.Compiler.TypedTree.CheckedImplFileFSharp.Compiler.Symbols.FSharpAssemblyContents→FSharp.Compiler.TypedTree.ModuleOrNamespaceTypeFSharp.Compiler.Symbols.FSharpAssemblySignature→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.Symbols.FSharpAssemblySignature→FSharp.Compiler.TypedTree.ModuleOrNamespaceTypeFSharp.Compiler.Symbols.FSharpEntity→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Symbols.FSharpField→FSharp.Compiler.TypedTree.RecdFieldRefFSharp.Compiler.Symbols.FSharpField→FSharp.Compiler.TypedTree.UnionCaseRefFSharp.Compiler.Symbols.FSharpGenericParameter→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.Symbols.FSharpImplementationFileContents→FSharp.Compiler.TypedTree.CheckedImplFileFSharp.Compiler.Symbols.FSharpMemberOrFunctionOrValue→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.Symbols.FSharpSymbol→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.Symbols.FSharpSymbol→FSharp.Compiler.TypedTree.ModuleOrNamespaceTypeFSharp.Compiler.Symbols.FSharpType→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.Symbols.FSharpType→FSharp.Compiler.TypedTree.ModuleOrNamespaceTypeFSharp.Compiler.Symbols.FSharpType→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Symbols.FSharpUnionCase→FSharp.Compiler.TypedTree.UnionCaseRefFSharp.Compiler.Symbols.SymbolEnv→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.Symbols.SymbolEnv→FSharp.Compiler.TypedTree.ModuleOrNamespaceType
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→19 FSharp.Compiler.Symbols uses FSharp.Compiler.TcGlobals✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.Symbols.FSharpAssembly→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Symbols.FSharpAssemblyContents→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Symbols.FSharpAssemblySignature→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Symbols.FSharpSymbol→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Symbols.FSharpType→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Symbols.SymbolEnv→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→20 FSharp.Compiler.Symbols uses FSharp.Compiler.Import✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.Import.
- The types involved
FSharp.Compiler.Symbols.SymbolEnv→FSharp.Compiler.Import.ImportMap
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.Import, so a change to FSharp.Compiler.Import can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.Import.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→21 FSharp.Compiler.Symbols uses FSharp.Compiler.InfoReader✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.InfoReader.
- The types involved
FSharp.Compiler.Symbols.SymbolEnv→FSharp.Compiler.InfoReader.InfoReader
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.InfoReader, so a change to FSharp.Compiler.InfoReader can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.InfoReader.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→22 FSharp.Compiler.Symbols uses FSharp.Compiler.NameResolution✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.NameResolution.
- The types involved
FSharp.Compiler.Symbols.FSharpSymbol→FSharp.Compiler.NameResolution.Item
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.NameResolution, so a change to FSharp.Compiler.NameResolution can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.NameResolution.
- Position
- Below the diagonal: FSharp.Compiler.Symbols uses a module listed above it, which is the healthy direction.
23→28 FSharp.Compiler.Symbols uses FSharp.Compiler.Infos part of a loop✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.Infos.
- The types involved
FSharp.Compiler.Symbols.FSharpMemberOrFunctionOrValue→FSharp.Compiler.Infos.MethInfo
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.Infos, so a change to FSharp.Compiler.Infos can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.Infos.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
23→29 FSharp.Compiler.Symbols uses FSharp.Compiler.AccessibilityLogic part of a loop✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Symbols uses a type in FSharp.Compiler.AccessibilityLogic.
- The types involved
FSharp.Compiler.Symbols.FSharpAccessibilityRights→FSharp.Compiler.AccessibilityLogic.AccessorDomain
- Direction
- FSharp.Compiler.Symbols uses FSharp.Compiler.AccessibilityLogic, so a change to FSharp.Compiler.AccessibilityLogic can break FSharp.Compiler.Symbols, while a change to FSharp.Compiler.Symbols can't break FSharp.Compiler.AccessibilityLogic.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
24→2 FSharp.Compiler.Diagnostics uses System.Collections✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.Diagnostics uses a type in System.Collections.
- The types involved
FSharp.Compiler.Diagnostics.FSharpDiagnosticKind→System.Collections.IStructuralComparableFSharp.Compiler.Diagnostics.FSharpDiagnosticKind→System.Collections.IStructuralEquatableFSharp.Compiler.Diagnostics.FSharpDiagnosticOptions→System.Collections.IStructuralEquatableFSharp.Compiler.Diagnostics.FSharpDiagnosticSeverity→System.Collections.IStructuralComparableFSharp.Compiler.Diagnostics.FSharpDiagnosticSeverity→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.Diagnostics uses System.Collections, so a change to System.Collections can break FSharp.Compiler.Diagnostics, while a change to FSharp.Compiler.Diagnostics can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.Diagnostics uses a module listed above it, which is the healthy direction.
24→6 FSharp.Compiler.Diagnostics uses System✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.Diagnostics uses a type in System.
- The types involved
FSharp.Compiler.Diagnostics.DiagnosticsScope→System.IDisposableFSharp.Compiler.Diagnostics.FSharpDiagnosticKind→System.IComparableFSharp.Compiler.Diagnostics.FSharpDiagnosticKind→System.IComparable`1FSharp.Compiler.Diagnostics.FSharpDiagnosticSeverity→System.IComparableFSharp.Compiler.Diagnostics.FSharpDiagnosticSeverity→System.IComparable`1
- Direction
- FSharp.Compiler.Diagnostics uses System, so a change to System can break FSharp.Compiler.Diagnostics, while a change to FSharp.Compiler.Diagnostics can't break System.
- Position
- Below the diagonal: FSharp.Compiler.Diagnostics uses a module listed above it, which is the healthy direction.
24→7 FSharp.Compiler.Diagnostics uses FSharp.Compiler.Text✕
- Connections
- 3 pairs of types, where a type in FSharp.Compiler.Diagnostics uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.Diagnostics.DiagnosticsScope→FSharp.Compiler.Text.RangeFSharp.Compiler.Diagnostics.FSharpDiagnostic→FSharp.Compiler.Text.PositionFSharp.Compiler.Diagnostics.FSharpDiagnostic→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.Diagnostics uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.Diagnostics, while a change to FSharp.Compiler.Diagnostics can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.Diagnostics uses a module listed above it, which is the healthy direction.
24→23 FSharp.Compiler.Diagnostics uses FSharp.Compiler.Symbols✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Diagnostics uses a type in FSharp.Compiler.Symbols.
- The types involved
FSharp.Compiler.Diagnostics.FSharpDiagnostic→FSharp.Compiler.Symbols.SymbolEnv
- Direction
- FSharp.Compiler.Diagnostics uses FSharp.Compiler.Symbols, so a change to FSharp.Compiler.Symbols can break FSharp.Compiler.Diagnostics, while a change to FSharp.Compiler.Diagnostics can't break FSharp.Compiler.Symbols.
- Position
- Below the diagonal: FSharp.Compiler.Diagnostics uses a module listed above it, which is the healthy direction.
24→25 FSharp.Compiler.Diagnostics uses FSharp.Compiler.DiagnosticsLogger part of a loop✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.Diagnostics uses a type in FSharp.Compiler.DiagnosticsLogger.
- The types involved
FSharp.Compiler.Diagnostics.CompilationDiagnosticLogger→FSharp.Compiler.DiagnosticsLogger.DiagnosticsLoggerFSharp.Compiler.Diagnostics.FSharpDiagnostic→FSharp.Compiler.DiagnosticsLogger.PhasedDiagnostic
- Direction
- FSharp.Compiler.Diagnostics uses FSharp.Compiler.DiagnosticsLogger, so a change to FSharp.Compiler.DiagnosticsLogger can break FSharp.Compiler.Diagnostics, while a change to FSharp.Compiler.Diagnostics can't break FSharp.Compiler.DiagnosticsLogger.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
25→2 FSharp.Compiler.DiagnosticsLogger uses System.Collections✕
- Connections
- 22 pairs of types, where a type in FSharp.Compiler.DiagnosticsLogger uses a type in System.Collections.
- The types involved
FSharp.Compiler.DiagnosticsLogger.BuildPhase→System.Collections.IStructuralComparableFSharp.Compiler.DiagnosticsLogger.BuildPhase→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.Deprecated→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.DiagnosticEnabledWithLanguageFeature→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.DiagnosticWithText→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.Experimental→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.InternalError→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.InternalException→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.LibraryUseOnly→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.ObsoleteDiagnostic→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.PhasedDiagnostic→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.PossibleUnverifiableCode→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.ReportedError→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.StopProcessingExn→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.SuppressLanguageFeatureCheck→System.Collections.IStructuralComparableFSharp.Compiler.DiagnosticsLogger.SuppressLanguageFeatureCheck→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.UnresolvedPathReference→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.UnresolvedPathReferenceNoRange→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.UnresolvedReferenceError→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.UnresolvedReferenceNoRange→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.UserCompilerMessage→System.Collections.IStructuralEquatableFSharp.Compiler.DiagnosticsLogger.WrappedError→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.DiagnosticsLogger uses System.Collections, so a change to System.Collections can break FSharp.Compiler.DiagnosticsLogger, while a change to FSharp.Compiler.DiagnosticsLogger can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.DiagnosticsLogger uses a module listed above it, which is the healthy direction.
25→6 FSharp.Compiler.DiagnosticsLogger uses System✕
- Connections
- 13 pairs of types, where a type in FSharp.Compiler.DiagnosticsLogger uses a type in System.
- The types involved
FSharp.Compiler.DiagnosticsLogger.BuildPhase→System.IComparableFSharp.Compiler.DiagnosticsLogger.BuildPhase→System.IComparable`1FSharp.Compiler.DiagnosticsLogger.CompilationGlobalsScope→System.IDisposableFSharp.Compiler.DiagnosticsLogger.DiagnosticsLogger→System.ExceptionFSharp.Compiler.DiagnosticsLogger.DiagnosticsLogger→System.IDisposableFSharp.Compiler.DiagnosticsLogger.InternalException→System.ExceptionFSharp.Compiler.DiagnosticsLogger.OperationResult`1→System.ExceptionFSharp.Compiler.DiagnosticsLogger.PhasedDiagnostic→System.ExceptionFSharp.Compiler.DiagnosticsLogger.ReportedError→System.ExceptionFSharp.Compiler.DiagnosticsLogger.StopProcessingExn→System.ExceptionFSharp.Compiler.DiagnosticsLogger.SuppressLanguageFeatureCheck→System.IComparableFSharp.Compiler.DiagnosticsLogger.SuppressLanguageFeatureCheck→System.IComparable`1FSharp.Compiler.DiagnosticsLogger.WrappedError→System.Exception
- Direction
- FSharp.Compiler.DiagnosticsLogger uses System, so a change to System can break FSharp.Compiler.DiagnosticsLogger, while a change to FSharp.Compiler.DiagnosticsLogger can't break System.
- Position
- Below the diagonal: FSharp.Compiler.DiagnosticsLogger uses a module listed above it, which is the healthy direction.
25→7 FSharp.Compiler.DiagnosticsLogger uses FSharp.Compiler.Text✕
- Connections
- 15 pairs of types, where a type in FSharp.Compiler.DiagnosticsLogger uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.DiagnosticsLogger.Deprecated→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.DiagnosticEnabledWithLanguageFeature→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.DiagnosticWithSuggestions→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.DiagnosticWithText→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.DiagnosticsLogger→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.Experimental→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.InternalError→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.InternalException→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.LibraryUseOnly→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.ObsoleteDiagnostic→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.PossibleUnverifiableCode→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.UnresolvedPathReference→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.UnresolvedReferenceError→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.UserCompilerMessage→FSharp.Compiler.Text.RangeFSharp.Compiler.DiagnosticsLogger.WrappedError→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.DiagnosticsLogger uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.DiagnosticsLogger, while a change to FSharp.Compiler.DiagnosticsLogger can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.DiagnosticsLogger uses a module listed above it, which is the healthy direction.
25→11 FSharp.Compiler.DiagnosticsLogger uses Internal.Utilities.Library✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.DiagnosticsLogger uses a type in Internal.Utilities.Library.
- The types involved
FSharp.Compiler.DiagnosticsLogger.StackGuard→Internal.Utilities.Library.Cancellable`1
- Direction
- FSharp.Compiler.DiagnosticsLogger uses Internal.Utilities.Library, so a change to Internal.Utilities.Library can break FSharp.Compiler.DiagnosticsLogger, while a change to FSharp.Compiler.DiagnosticsLogger can't break Internal.Utilities.Library.
- Position
- Below the diagonal: FSharp.Compiler.DiagnosticsLogger uses a module listed above it, which is the healthy direction.
25→24 FSharp.Compiler.DiagnosticsLogger uses FSharp.Compiler.Diagnostics✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.DiagnosticsLogger uses a type in FSharp.Compiler.Diagnostics.
- The types involved
FSharp.Compiler.DiagnosticsLogger.CapturingDiagnosticsLogger→FSharp.Compiler.Diagnostics.FSharpDiagnosticSeverityFSharp.Compiler.DiagnosticsLogger.DiagnosticsLogger→FSharp.Compiler.Diagnostics.FSharpDiagnosticSeverity
- Direction
- FSharp.Compiler.DiagnosticsLogger uses FSharp.Compiler.Diagnostics, so a change to FSharp.Compiler.Diagnostics can break FSharp.Compiler.DiagnosticsLogger, while a change to FSharp.Compiler.DiagnosticsLogger can't break FSharp.Compiler.Diagnostics.
- Position
- Below the diagonal: FSharp.Compiler.DiagnosticsLogger uses a module listed above it, which is the healthy direction.
26→2 FSharp.Compiler.CompilerConfig uses System.Collections✕
- Connections
- 30 pairs of types, where a type in FSharp.Compiler.CompilerConfig uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.CompilerConfig.AssemblyReference→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.CompilerTarget→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.CompilerTarget→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.CopyFSharpCoreFlag→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.CopyFSharpCoreFlag→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.Directive→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.Directive→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.FileNameNotResolved→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.HashAlgorithm→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.HashAlgorithm→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.LStatus→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.LStatus→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.LoadedSourceNotFoundIgnoring→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.MetadataAssemblyGeneration→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.MetadataAssemblyGeneration→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.PackageManagerLine→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.ParallelReferenceResolution→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.ParallelReferenceResolution→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.ProjectAssemblyDataResult→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.TokenizeOption→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.TokenizeOption→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.TypeCheckingConfig→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.TypeCheckingConfig→System.Collections.IStructuralEquatableFSharp.Compiler.CompilerConfig.TypeCheckingMode→System.Collections.IStructuralComparableFSharp.Compiler.CompilerConfig.TypeCheckingMode→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.CompilerConfig uses System.Collections, so a change to System.Collections can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→3 FSharp.Compiler.CompilerConfig uses System.Collections.Generic✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CompilerConfig uses a type in System.Collections.Generic.
- The types involved
FSharp.Compiler.CompilerConfig.TcConfigBuilder→System.Collections.Generic.IEnumerable`1
- Direction
- FSharp.Compiler.CompilerConfig uses System.Collections.Generic, so a change to System.Collections.Generic can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break System.Collections.Generic.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→6 FSharp.Compiler.CompilerConfig uses System✕
- Connections
- 24 pairs of types, where a type in FSharp.Compiler.CompilerConfig uses a type in System.
- The types involved
FSharp.Compiler.CompilerConfig.CompilerTarget→System.IComparableFSharp.Compiler.CompilerConfig.CompilerTarget→System.IComparable`1FSharp.Compiler.CompilerConfig.CopyFSharpCoreFlag→System.IComparableFSharp.Compiler.CompilerConfig.CopyFSharpCoreFlag→System.IComparable`1FSharp.Compiler.CompilerConfig.Directive→System.IComparableFSharp.Compiler.CompilerConfig.Directive→System.IComparable`1FSharp.Compiler.CompilerConfig.HashAlgorithm→System.IComparableFSharp.Compiler.CompilerConfig.HashAlgorithm→System.IComparable`1FSharp.Compiler.CompilerConfig.LStatus→System.IComparableFSharp.Compiler.CompilerConfig.LStatus→System.IComparable`1FSharp.Compiler.CompilerConfig.MetadataAssemblyGeneration→System.IComparableFSharp.Compiler.CompilerConfig.MetadataAssemblyGeneration→System.IComparable`1FSharp.Compiler.CompilerConfig.ParallelReferenceResolution→System.IComparableFSharp.Compiler.CompilerConfig.ParallelReferenceResolution→System.IComparable`1FSharp.Compiler.CompilerConfig.TokenizeOption→System.IComparableFSharp.Compiler.CompilerConfig.TokenizeOption→System.IComparable`1FSharp.Compiler.CompilerConfig.TypeCheckingConfig→System.IComparableFSharp.Compiler.CompilerConfig.TypeCheckingConfig→System.IComparable`1FSharp.Compiler.CompilerConfig.TypeCheckingMode→System.IComparableFSharp.Compiler.CompilerConfig.TypeCheckingMode→System.IComparable`1FSharp.Compiler.CompilerConfig.VersionFlag→System.IComparableFSharp.Compiler.CompilerConfig.VersionFlag→System.IComparable`1FSharp.Compiler.CompilerConfig.WarningNumberSource→System.IComparableFSharp.Compiler.CompilerConfig.WarningNumberSource→System.IComparable`1
- Direction
- FSharp.Compiler.CompilerConfig uses System, so a change to System can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break System.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→7 FSharp.Compiler.CompilerConfig uses FSharp.Compiler.Text✕
- Connections
- 7 pairs of types, where a type in FSharp.Compiler.CompilerConfig uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.CompilerConfig.AssemblyReference→FSharp.Compiler.Text.RangeFSharp.Compiler.CompilerConfig.CompilerConfig→FSharp.Compiler.Text.RangeFSharp.Compiler.CompilerConfig.FileNameNotResolved→FSharp.Compiler.Text.RangeFSharp.Compiler.CompilerConfig.IRawFSharpAssemblyData→FSharp.Compiler.Text.RangeFSharp.Compiler.CompilerConfig.LoadedSourceNotFoundIgnoring→FSharp.Compiler.Text.RangeFSharp.Compiler.CompilerConfig.PackageManagerLine→FSharp.Compiler.Text.RangeFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.CompilerConfig uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→13 FSharp.Compiler.CompilerConfig uses FSharp.Compiler.AbstractIL.IL✕
- Connections
- 9 pairs of types, where a type in FSharp.Compiler.CompilerConfig uses a type in FSharp.Compiler.AbstractIL.IL.
- The types involved
FSharp.Compiler.CompilerConfig.IRawFSharpAssemblyData→FSharp.Compiler.AbstractIL.IL.ILAssemblyRefFSharp.Compiler.CompilerConfig.IRawFSharpAssemblyData→FSharp.Compiler.AbstractIL.IL.ILExportedTypesAndForwardersFSharp.Compiler.CompilerConfig.IRawFSharpAssemblyData→FSharp.Compiler.AbstractIL.IL.ILModuleDefFSharp.Compiler.CompilerConfig.IRawFSharpAssemblyData→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.AbstractIL.IL.ILPlatformFSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.AbstractIL.IL.PrimaryAssemblyFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.AbstractIL.IL.ILPlatformFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.AbstractIL.IL.PrimaryAssemblyFSharp.Compiler.CompilerConfig.VersionFlag→FSharp.Compiler.AbstractIL.IL.ILVersionInfo
- Direction
- FSharp.Compiler.CompilerConfig uses FSharp.Compiler.AbstractIL.IL, so a change to FSharp.Compiler.AbstractIL.IL can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break FSharp.Compiler.AbstractIL.IL.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→14 FSharp.Compiler.CompilerConfig uses FSharp.Compiler.Syntax✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CompilerConfig uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.CompilerConfig.WarningDescription→FSharp.Compiler.Syntax.Ident
- Direction
- FSharp.Compiler.CompilerConfig uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→19 FSharp.Compiler.CompilerConfig uses FSharp.Compiler.TcGlobals✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CompilerConfig uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.TcGlobals.CompilationModeFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.TcGlobals.CompilationMode
- Direction
- FSharp.Compiler.CompilerConfig uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→24 FSharp.Compiler.CompilerConfig uses FSharp.Compiler.Diagnostics✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CompilerConfig uses a type in FSharp.Compiler.Diagnostics.
- The types involved
FSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.Diagnostics.FSharpDiagnosticOptionsFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.Diagnostics.FSharpDiagnosticOptions
- Direction
- FSharp.Compiler.CompilerConfig uses FSharp.Compiler.Diagnostics, so a change to FSharp.Compiler.Diagnostics can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break FSharp.Compiler.Diagnostics.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→25 FSharp.Compiler.CompilerConfig uses FSharp.Compiler.DiagnosticsLogger✕
- Connections
- 4 pairs of types, where a type in FSharp.Compiler.CompilerConfig uses a type in FSharp.Compiler.DiagnosticsLogger.
- The types involved
FSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.DiagnosticsLogger.DiagnosticStyleFSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.DiagnosticsLogger.ExiterFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.DiagnosticsLogger.DiagnosticStyleFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.DiagnosticsLogger.Exiter
- Direction
- FSharp.Compiler.CompilerConfig uses FSharp.Compiler.DiagnosticsLogger, so a change to FSharp.Compiler.DiagnosticsLogger can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break FSharp.Compiler.DiagnosticsLogger.
- Position
- Below the diagonal: FSharp.Compiler.CompilerConfig uses a module listed above it, which is the healthy direction.
26→33 FSharp.Compiler.CompilerConfig uses FSharp.Compiler.CodeAnalysis part of a loop✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.CompilerConfig uses a type in FSharp.Compiler.CodeAnalysis.
- The types involved
FSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.CodeAnalysis.FxResolverFSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.CodeAnalysis.LegacyReferenceResolverFSharp.Compiler.CompilerConfig.TcConfig→FSharp.Compiler.CodeAnalysis.LegacyResolutionEnvironmentFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.CodeAnalysis.FxResolverFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.CodeAnalysis.LegacyReferenceResolverFSharp.Compiler.CompilerConfig.TcConfigBuilder→FSharp.Compiler.CodeAnalysis.LegacyResolutionEnvironment
- Direction
- FSharp.Compiler.CompilerConfig uses FSharp.Compiler.CodeAnalysis, so a change to FSharp.Compiler.CodeAnalysis can break FSharp.Compiler.CompilerConfig, while a change to FSharp.Compiler.CompilerConfig can't break FSharp.Compiler.CodeAnalysis.
- Position
- Above the diagonal, so it is part of a loop. Neither module can be changed, tested or released on its own until one of these dependencies is removed.
27→2 FSharp.Compiler.TypedTreeOps uses System.Collections✕
- Connections
- 15 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in System.Collections.
- The types involved
FSharp.Compiler.TypedTreeOps.AllowTypeDirectedDetupling→System.Collections.IStructuralComparableFSharp.Compiler.TypedTreeOps.AllowTypeDirectedDetupling→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTreeOps.DefensiveCopyWarning→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTreeOps.Erasure→System.Collections.IStructuralComparableFSharp.Compiler.TypedTreeOps.Erasure→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTreeOps.GenericParameterStyle→System.Collections.IStructuralComparableFSharp.Compiler.TypedTreeOps.GenericParameterStyle→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTreeOps.Mutates→System.Collections.IStructuralComparableFSharp.Compiler.TypedTreeOps.Mutates→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTreeOps.OptimizeForExpressionOptions→System.Collections.IStructuralComparableFSharp.Compiler.TypedTreeOps.OptimizeForExpressionOptions→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTreeOps.SignatureHidingInfo→System.Collections.IStructuralComparableFSharp.Compiler.TypedTreeOps.SignatureHidingInfo→System.Collections.IStructuralEquatableFSharp.Compiler.TypedTreeOps.ValCopyFlag→System.Collections.IStructuralComparableFSharp.Compiler.TypedTreeOps.ValCopyFlag→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.TypedTreeOps uses System.Collections, so a change to System.Collections can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→3 FSharp.Compiler.TypedTreeOps uses System.Collections.Generic✕
- Connections
- 4 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in System.Collections.Generic.
- The types involved
FSharp.Compiler.TypedTreeOps.SignatureHidingInfo→System.Collections.Generic.IComparer`1FSharp.Compiler.TypedTreeOps.TypedTreeOps→System.Collections.Generic.IComparer`1FSharp.Compiler.TypedTreeOps.TypedTreeOps→System.Collections.Generic.IEnumerable`1FSharp.Compiler.TypedTreeOps.ValHash`1→System.Collections.Generic.IEnumerable`1
- Direction
- FSharp.Compiler.TypedTreeOps uses System.Collections.Generic, so a change to System.Collections.Generic can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break System.Collections.Generic.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→6 FSharp.Compiler.TypedTreeOps uses System✕
- Connections
- 15 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in System.
- The types involved
FSharp.Compiler.TypedTreeOps.AllowTypeDirectedDetupling→System.IComparableFSharp.Compiler.TypedTreeOps.AllowTypeDirectedDetupling→System.IComparable`1FSharp.Compiler.TypedTreeOps.Erasure→System.IComparableFSharp.Compiler.TypedTreeOps.Erasure→System.IComparable`1FSharp.Compiler.TypedTreeOps.GenericParameterStyle→System.IComparableFSharp.Compiler.TypedTreeOps.GenericParameterStyle→System.IComparable`1FSharp.Compiler.TypedTreeOps.Mutates→System.IComparableFSharp.Compiler.TypedTreeOps.Mutates→System.IComparable`1FSharp.Compiler.TypedTreeOps.OptimizeForExpressionOptions→System.IComparableFSharp.Compiler.TypedTreeOps.OptimizeForExpressionOptions→System.IComparable`1FSharp.Compiler.TypedTreeOps.SignatureHidingInfo→System.IComparableFSharp.Compiler.TypedTreeOps.SignatureHidingInfo→System.IComparable`1FSharp.Compiler.TypedTreeOps.StaticOptimizationAnswer→System.EnumFSharp.Compiler.TypedTreeOps.ValCopyFlag→System.IComparableFSharp.Compiler.TypedTreeOps.ValCopyFlag→System.IComparable`1
- Direction
- FSharp.Compiler.TypedTreeOps uses System, so a change to System can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break System.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→7 FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.Text✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.TypedTreeOps.DefensiveCopyWarning→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTreeOps.MatchBuilder→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Text.LayoutFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Text.RangeFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Text.TaggedText
- Direction
- FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→10 FSharp.Compiler.TypedTreeOps uses Internal.Utilities.Collections.Tagged✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in Internal.Utilities.Collections.Tagged.
- The types involved
FSharp.Compiler.TypedTreeOps.SignatureHidingInfo→Internal.Utilities.Collections.Tagged.Set`2FSharp.Compiler.TypedTreeOps.TypedTreeOps→Internal.Utilities.Collections.Tagged.Set`2
- Direction
- FSharp.Compiler.TypedTreeOps uses Internal.Utilities.Collections.Tagged, so a change to Internal.Utilities.Collections.Tagged can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break Internal.Utilities.Collections.Tagged.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→11 FSharp.Compiler.TypedTreeOps uses Internal.Utilities.Library✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in Internal.Utilities.Library.
- The types involved
FSharp.Compiler.TypedTreeOps.DisplayEnv→Internal.Utilities.Library.InterruptibleLazy`1
- Direction
- FSharp.Compiler.TypedTreeOps uses Internal.Utilities.Library, so a change to Internal.Utilities.Library can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break Internal.Utilities.Library.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→13 FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.AbstractIL.IL✕
- Connections
- 12 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in FSharp.Compiler.AbstractIL.IL.
- The types involved
FSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILArrayShapeFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILAttribElemFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILAttributeFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILAttributesFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILFieldInitFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILFieldSpecFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILInstrFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILMethodSpecFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILReadonlyFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILTypeFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.AbstractIL.IL.ILVersionInfo
- Direction
- FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.AbstractIL.IL, so a change to FSharp.Compiler.AbstractIL.IL can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break FSharp.Compiler.AbstractIL.IL.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→14 FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.Syntax✕
- Connections
- 11 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.TypedTreeOps.MatchBuilder→FSharp.Compiler.Syntax.DebugPointAtBindingFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.DebugPointAtBindingFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.DebugPointAtFinallyFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.DebugPointAtForFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.DebugPointAtInOrToFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.DebugPointAtTryFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.DebugPointAtWhileFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.DebugPointAtWithFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.IdentFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.SynMemberFlagsFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.Syntax.TyparStaticReq
- Direction
- FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→18 FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.TypedTree✕
- Connections
- 72 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in FSharp.Compiler.TypedTree. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.TypedTreeOps.DisplayEnv→FSharp.Compiler.TypedTree.AccessibilityFSharp.Compiler.TypedTreeOps.DisplayEnv→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.TypedTreeOps.FreeVarOptions→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.TypedTreeOps.GeneralizedType→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.TypedTreeOps.GeneralizedType→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.TypedTreeOps.MatchBuilder→FSharp.Compiler.TypedTree.DecisionTreeFSharp.Compiler.TypedTreeOps.MatchBuilder→FSharp.Compiler.TypedTree.DecisionTreeTargetFSharp.Compiler.TypedTreeOps.MatchBuilder→FSharp.Compiler.TypedTree.ExprFSharp.Compiler.TypedTreeOps.MatchBuilder→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.TypedTreeOps.Remap→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.TypedTreeOps.Remap→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.TypedTreeOps.SignatureHidingInfo→FSharp.Compiler.TypedTree.EntityFSharp.Compiler.TypedTreeOps.SignatureHidingInfo→FSharp.Compiler.TypedTree.RecdFieldRefFSharp.Compiler.TypedTreeOps.SignatureHidingInfo→FSharp.Compiler.TypedTree.UnionCaseRefFSharp.Compiler.TypedTreeOps.SignatureHidingInfo→FSharp.Compiler.TypedTree.ValFSharp.Compiler.TypedTreeOps.TyconRefMap`1→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.TypedTreeOps.TyconRefMultiMap`1→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.TypedTreeOps.TyparMap`1→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.TypedTreeOps.TypeDefMetadata→FSharp.Compiler.TypedTree.TILObjectReprDataFSharp.Compiler.TypedTreeOps.TypeEquivEnv→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.TypedTreeOps.TypeEquivEnv→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.TypedTreeOps.TypeEquivEnv→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.TypedTree.ActivePatternReturnKindFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.TypedTree.AnonRecdTypeInfoFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.TypedTree.ArgReprInfo
- Direction
- FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→19 FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.TcGlobals✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.TypedTreeOps.DisplayEnv→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.TypedTreeOps.TypeEquivEnv→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.TcGlobals.BuiltinAttribInfoFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.TcGlobals.IntrinsicValRefFSharp.Compiler.TypedTreeOps.TypedTreeOps→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
27→25 FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.DiagnosticsLogger✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.TypedTreeOps uses a type in FSharp.Compiler.DiagnosticsLogger.
- The types involved
FSharp.Compiler.TypedTreeOps.ExprRewritingEnv→FSharp.Compiler.DiagnosticsLogger.StackGuard
- Direction
- FSharp.Compiler.TypedTreeOps uses FSharp.Compiler.DiagnosticsLogger, so a change to FSharp.Compiler.DiagnosticsLogger can break FSharp.Compiler.TypedTreeOps, while a change to FSharp.Compiler.TypedTreeOps can't break FSharp.Compiler.DiagnosticsLogger.
- Position
- Below the diagonal: FSharp.Compiler.TypedTreeOps uses a module listed above it, which is the healthy direction.
28→2 FSharp.Compiler.Infos uses System.Collections✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.Infos uses a type in System.Collections.
- The types involved
FSharp.Compiler.Infos.BadEventTransformation→System.Collections.IStructuralEquatableFSharp.Compiler.Infos.CallerInfo→System.Collections.IStructuralComparableFSharp.Compiler.Infos.CallerInfo→System.Collections.IStructuralEquatableFSharp.Compiler.Infos.ReflectedArgInfo→System.Collections.IStructuralComparableFSharp.Compiler.Infos.ReflectedArgInfo→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.Infos uses System.Collections, so a change to System.Collections can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
28→6 FSharp.Compiler.Infos uses System✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.Infos uses a type in System.
- The types involved
FSharp.Compiler.Infos.CallerInfo→System.IComparableFSharp.Compiler.Infos.CallerInfo→System.IComparable`1FSharp.Compiler.Infos.Infos→System.ExceptionFSharp.Compiler.Infos.ReflectedArgInfo→System.IComparableFSharp.Compiler.Infos.ReflectedArgInfo→System.IComparable`1
- Direction
- FSharp.Compiler.Infos uses System, so a change to System can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break System.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
28→7 FSharp.Compiler.Infos uses FSharp.Compiler.Text✕
- Connections
- 10 pairs of types, where a type in FSharp.Compiler.Infos uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.Infos.BadEventTransformation→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.EventInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.ILPropInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.Infos→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.MethInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.OptionalArgInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.PropInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.Infos.UnionCaseInfo→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.Infos uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
28→13 FSharp.Compiler.Infos uses FSharp.Compiler.AbstractIL.IL✕
- Connections
- 23 pairs of types, where a type in FSharp.Compiler.Infos uses a type in FSharp.Compiler.AbstractIL.IL.
- The types involved
FSharp.Compiler.Infos.EventInfo→FSharp.Compiler.AbstractIL.IL.ILAttributesFSharp.Compiler.Infos.ILEventInfo→FSharp.Compiler.AbstractIL.IL.ILEventDefFSharp.Compiler.Infos.ILEventInfo→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.AbstractIL.IL.ILFieldDefFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.AbstractIL.IL.ILFieldInitFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.AbstractIL.IL.ILFieldRefFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.AbstractIL.IL.ILTypeFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.AbstractIL.IL.ILMethodDefFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.AbstractIL.IL.ILMethodRefFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.AbstractIL.IL.ILParameterFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.Infos.ILPropInfo→FSharp.Compiler.AbstractIL.IL.ILPropertyDefFSharp.Compiler.Infos.ILTypeInfo→FSharp.Compiler.AbstractIL.IL.ILScopeRefFSharp.Compiler.Infos.ILTypeInfo→FSharp.Compiler.AbstractIL.IL.ILTypeDefFSharp.Compiler.Infos.ILTypeInfo→FSharp.Compiler.AbstractIL.IL.ILTypeRefFSharp.Compiler.Infos.MethInfo→FSharp.Compiler.AbstractIL.IL.ILAttributesFSharp.Compiler.Infos.MethInfo→FSharp.Compiler.AbstractIL.IL.ILMethodDefFSharp.Compiler.Infos.OptionalArgCallerSideValue→FSharp.Compiler.AbstractIL.IL.ILFieldInitFSharp.Compiler.Infos.OptionalArgInfo→FSharp.Compiler.AbstractIL.IL.ILFieldInitFSharp.Compiler.Infos.OptionalArgInfo→FSharp.Compiler.AbstractIL.IL.ILParameterFSharp.Compiler.Infos.OptionalArgInfo→FSharp.Compiler.AbstractIL.IL.ILScopeRef
- Direction
- FSharp.Compiler.Infos uses FSharp.Compiler.AbstractIL.IL, so a change to FSharp.Compiler.AbstractIL.IL can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break FSharp.Compiler.AbstractIL.IL.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
28→14 FSharp.Compiler.Infos uses FSharp.Compiler.Syntax✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.Infos uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.Infos.ParamData→FSharp.Compiler.Syntax.IdentFSharp.Compiler.Infos.ParamNameAndType→FSharp.Compiler.Syntax.Ident
- Direction
- FSharp.Compiler.Infos uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
28→18 FSharp.Compiler.Infos uses FSharp.Compiler.TypedTree✕
- Connections
- 52 pairs of types, where a type in FSharp.Compiler.Infos uses a type in FSharp.Compiler.TypedTree. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.Infos.CompiledSig→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.CompiledSig→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.Infos.EventInfo→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Infos.EventInfo→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.EventInfo→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.Infos.ILEventInfo→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Infos.ILEventInfo→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.Infos.ILMethParentTypeInfo→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Infos.ILMethParentTypeInfo→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.ILPropInfo→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.ILTypeInfo→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Infos.ILTypeInfo→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.Infos→FSharp.Compiler.TypedTree.ArgReprInfoFSharp.Compiler.Infos.Infos→FSharp.Compiler.TypedTree.SlotParamFSharp.Compiler.Infos.Infos→FSharp.Compiler.TypedTree.SlotSigFSharp.Compiler.Infos.Infos→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.Infos.Infos→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.Infos.Infos→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.Infos.MethInfo→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.Infos.MethInfo→FSharp.Compiler.TypedTree.SlotSig
- Direction
- FSharp.Compiler.Infos uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
28→19 FSharp.Compiler.Infos uses FSharp.Compiler.TcGlobals✕
- Connections
- 11 pairs of types, where a type in FSharp.Compiler.Infos uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.Infos.EventInfo→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.ILEventInfo→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.ILPropInfo→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.ILTypeInfo→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.Infos→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.MethInfo→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.OptionalArgInfo→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.ParamNameAndType→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.Infos.PropInfo→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.Infos uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
28→20 FSharp.Compiler.Infos uses FSharp.Compiler.Import✕
- Connections
- 8 pairs of types, where a type in FSharp.Compiler.Infos uses a type in FSharp.Compiler.Import.
- The types involved
FSharp.Compiler.Infos.EventInfo→FSharp.Compiler.Import.ImportMapFSharp.Compiler.Infos.ILFieldInfo→FSharp.Compiler.Import.ImportMapFSharp.Compiler.Infos.ILMethInfo→FSharp.Compiler.Import.ImportMapFSharp.Compiler.Infos.ILPropInfo→FSharp.Compiler.Import.ImportMapFSharp.Compiler.Infos.Infos→FSharp.Compiler.Import.ImportMapFSharp.Compiler.Infos.MethInfo→FSharp.Compiler.Import.ImportMapFSharp.Compiler.Infos.OptionalArgInfo→FSharp.Compiler.Import.ImportMapFSharp.Compiler.Infos.PropInfo→FSharp.Compiler.Import.ImportMap
- Direction
- FSharp.Compiler.Infos uses FSharp.Compiler.Import, so a change to FSharp.Compiler.Import can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break FSharp.Compiler.Import.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
28→27 FSharp.Compiler.Infos uses FSharp.Compiler.TypedTreeOps✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.Infos uses a type in FSharp.Compiler.TypedTreeOps.
- The types involved
FSharp.Compiler.Infos.Infos→FSharp.Compiler.TypedTreeOps.Erasure
- Direction
- FSharp.Compiler.Infos uses FSharp.Compiler.TypedTreeOps, so a change to FSharp.Compiler.TypedTreeOps can break FSharp.Compiler.Infos, while a change to FSharp.Compiler.Infos can't break FSharp.Compiler.TypedTreeOps.
- Position
- Below the diagonal: FSharp.Compiler.Infos uses a module listed above it, which is the healthy direction.
29→7 FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.Text✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.AccessibilityLogic uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.AccessibilityLogic, while a change to FSharp.Compiler.AccessibilityLogic can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.AccessibilityLogic uses a module listed above it, which is the healthy direction.
29→13 FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.AbstractIL.IL✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.AccessibilityLogic uses a type in FSharp.Compiler.AbstractIL.IL.
- The types involved
FSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.AbstractIL.IL.ILMemberAccess
- Direction
- FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.AbstractIL.IL, so a change to FSharp.Compiler.AbstractIL.IL can break FSharp.Compiler.AccessibilityLogic, while a change to FSharp.Compiler.AccessibilityLogic can't break FSharp.Compiler.AbstractIL.IL.
- Position
- Below the diagonal: FSharp.Compiler.AccessibilityLogic uses a module listed above it, which is the healthy direction.
29→18 FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.TypedTree✕
- Connections
- 8 pairs of types, where a type in FSharp.Compiler.AccessibilityLogic uses a type in FSharp.Compiler.TypedTree.
- The types involved
FSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.TypedTree.AccessibilityFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.TypedTree.RecdFieldRefFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.TypedTree.UnionCaseRefFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.AccessibilityLogic.AccessorDomain→FSharp.Compiler.TypedTree.CompilationPathFSharp.Compiler.AccessibilityLogic.AccessorDomain→FSharp.Compiler.TypedTree.EntityRef
- Direction
- FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.AccessibilityLogic, while a change to FSharp.Compiler.AccessibilityLogic can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.AccessibilityLogic uses a module listed above it, which is the healthy direction.
29→19 FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.TcGlobals✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.AccessibilityLogic uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.AccessibilityLogic.AccessorDomain→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.AccessibilityLogic, while a change to FSharp.Compiler.AccessibilityLogic can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.AccessibilityLogic uses a module listed above it, which is the healthy direction.
29→20 FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.Import✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.AccessibilityLogic uses a type in FSharp.Compiler.Import.
- The types involved
FSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.Import.ImportMap
- Direction
- FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.Import, so a change to FSharp.Compiler.Import can break FSharp.Compiler.AccessibilityLogic, while a change to FSharp.Compiler.AccessibilityLogic can't break FSharp.Compiler.Import.
- Position
- Below the diagonal: FSharp.Compiler.AccessibilityLogic uses a module listed above it, which is the healthy direction.
29→28 FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.Infos✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.AccessibilityLogic uses a type in FSharp.Compiler.Infos.
- The types involved
FSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.Infos.ILEventInfoFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.Infos.ILFieldInfoFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.Infos.ILPropInfoFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.Infos.MethInfoFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.Infos.PropInfoFSharp.Compiler.AccessibilityLogic.AccessibilityLogic→FSharp.Compiler.Infos.RecdFieldInfo
- Direction
- FSharp.Compiler.AccessibilityLogic uses FSharp.Compiler.Infos, so a change to FSharp.Compiler.Infos can break FSharp.Compiler.AccessibilityLogic, while a change to FSharp.Compiler.AccessibilityLogic can't break FSharp.Compiler.Infos.
- Position
- Below the diagonal: FSharp.Compiler.AccessibilityLogic uses a module listed above it, which is the healthy direction.
30→2 FSharp.Compiler.ConstraintSolver uses System.Collections✕
- Connections
- 3 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in System.Collections.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolverError→System.Collections.IStructuralEquatableFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarning→System.Collections.IStructuralEquatableFSharp.Compiler.ConstraintSolver.OverloadInformation→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.ConstraintSolver uses System.Collections, so a change to System.Collections can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→3 FSharp.Compiler.ConstraintSolver uses System.Collections.Generic✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in System.Collections.Generic.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→System.Collections.Generic.IComparer`1FSharp.Compiler.ConstraintSolver.ConstraintSolverState→System.Collections.Generic.IEnumerable`1
- Direction
- FSharp.Compiler.ConstraintSolver uses System.Collections.Generic, so a change to System.Collections.Generic can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break System.Collections.Generic.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→6 FSharp.Compiler.ConstraintSolver uses System✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in System.
- The types involved
FSharp.Compiler.ConstraintSolver.ErrorFromAddingConstraint→System.ExceptionFSharp.Compiler.ConstraintSolver.ErrorFromAddingTypeEquation→System.ExceptionFSharp.Compiler.ConstraintSolver.ErrorFromApplyingDefault→System.ExceptionFSharp.Compiler.ConstraintSolver.ErrorsFromAddingSubsumptionConstraint→System.ExceptionFSharp.Compiler.ConstraintSolver.OverloadInformation→System.Exception
- Direction
- FSharp.Compiler.ConstraintSolver uses System, so a change to System can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break System.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→7 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.Text✕
- Connections
- 19 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverError→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverInfiniteTypes→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverMissingConstraint→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarning→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningEquivWithTypes→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningWithType→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningWithTypes→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverTupleDiffLengths→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverTypesNotInEqualityRelation→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ConstraintSolverTypesNotInSubsumptionRelation→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ContextInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ErrorFromAddingConstraint→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ErrorFromAddingTypeEquation→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ErrorFromApplyingDefault→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.ErrorsFromAddingSubsumptionConstraint→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.NonRigidTypar→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.UnresolvedConversionOperator→FSharp.Compiler.Text.RangeFSharp.Compiler.ConstraintSolver.UnresolvedOverloading→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→10 FSharp.Compiler.ConstraintSolver uses Internal.Utilities.Collections.Tagged✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in Internal.Utilities.Collections.Tagged.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→Internal.Utilities.Collections.Tagged.Set`2
- Direction
- FSharp.Compiler.ConstraintSolver uses Internal.Utilities.Collections.Tagged, so a change to Internal.Utilities.Collections.Tagged can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break Internal.Utilities.Collections.Tagged.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→14 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.Syntax✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.Syntax.SynExpr
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→18 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.TypedTree✕
- Connections
- 30 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.TypedTree. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.ConstraintSolver.ArgDoesNotMatchError→FSharp.Compiler.TypedTree.ExprFSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.TypedTree.ExprFSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.TypedTree.NullnessFSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.TypedTree.TraitConstraintInfoFSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.TypedTree.TyparConstraintFSharp.Compiler.ConstraintSolver.ConstraintSolverInfiniteTypes→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ConstraintSolverMissingConstraint→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.ConstraintSolver.ConstraintSolverMissingConstraint→FSharp.Compiler.TypedTree.TyparConstraintFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningEquivWithTypes→FSharp.Compiler.TypedTree.NullnessInfoFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningEquivWithTypes→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningWithType→FSharp.Compiler.TypedTree.NullnessInfoFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningWithType→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningWithTypes→FSharp.Compiler.TypedTree.NullnessInfoFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningWithTypes→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ConstraintSolverTupleDiffLengths→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ConstraintSolverTypesNotInEqualityRelation→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ConstraintSolverTypesNotInSubsumptionRelation→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ContextInfo→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ErrorFromAddingTypeEquation→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ErrorFromApplyingDefault→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.ErrorFromApplyingDefault→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.ConstraintSolver.ErrorsFromAddingSubsumptionConstraint→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.ConstraintSolver.NonRigidTypar→FSharp.Compiler.TypedTree.TType
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→19 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.TcGlobals✕
- Connections
- 5 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.ConstraintSolver.ConstraintSolverState→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.ConstraintSolver.ErrorFromAddingTypeEquation→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.ConstraintSolver.ErrorFromApplyingDefault→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.ConstraintSolver.ErrorsFromAddingSubsumptionConstraint→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→20 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.Import✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.Import.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.Import.ImportMapFSharp.Compiler.ConstraintSolver.ConstraintSolverState→FSharp.Compiler.Import.ImportMap
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.Import, so a change to FSharp.Compiler.Import can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.Import.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→21 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.InfoReader✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.InfoReader.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolverState→FSharp.Compiler.InfoReader.InfoReaderFSharp.Compiler.ConstraintSolver.OverloadInformation→FSharp.Compiler.InfoReader.InfoReader
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.InfoReader, so a change to FSharp.Compiler.InfoReader can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.InfoReader.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→25 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.DiagnosticsLogger✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.DiagnosticsLogger.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.DiagnosticsLogger.OperationResult`1
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.DiagnosticsLogger, so a change to FSharp.Compiler.DiagnosticsLogger can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.DiagnosticsLogger.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→27 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.TypedTreeOps✕
- Connections
- 16 pairs of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.TypedTreeOps.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ConstraintSolverInfiniteTypes→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ConstraintSolverMissingConstraint→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningEquivWithTypes→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningWithType→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ConstraintSolverNullnessWarningWithTypes→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ConstraintSolverTupleDiffLengths→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ConstraintSolverTypesNotInEqualityRelation→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ConstraintSolverTypesNotInSubsumptionRelation→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ErrorFromAddingConstraint→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ErrorFromAddingTypeEquation→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ErrorFromApplyingDefault→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.ErrorsFromAddingSubsumptionConstraint→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.NonRigidTypar→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.UnresolvedConversionOperator→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.ConstraintSolver.UnresolvedOverloading→FSharp.Compiler.TypedTreeOps.DisplayEnv
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.TypedTreeOps, so a change to FSharp.Compiler.TypedTreeOps can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.TypedTreeOps.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→28 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.Infos✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.Infos.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.Infos.MethInfo
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.Infos, so a change to FSharp.Compiler.Infos can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.Infos.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
30→29 FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.AccessibilityLogic✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.ConstraintSolver uses a type in FSharp.Compiler.AccessibilityLogic.
- The types involved
FSharp.Compiler.ConstraintSolver.ConstraintSolver→FSharp.Compiler.AccessibilityLogic.AccessorDomain
- Direction
- FSharp.Compiler.ConstraintSolver uses FSharp.Compiler.AccessibilityLogic, so a change to FSharp.Compiler.AccessibilityLogic can break FSharp.Compiler.ConstraintSolver, while a change to FSharp.Compiler.ConstraintSolver can't break FSharp.Compiler.AccessibilityLogic.
- Position
- Below the diagonal: FSharp.Compiler.ConstraintSolver uses a module listed above it, which is the healthy direction.
31→1 FSharp.Compiler.EditorServices uses (global)✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.EditorServices uses a type in (global).
- The types involved
FSharp.Compiler.EditorServices.SemanticClassificationKeyStore→IDisposable
- Direction
- FSharp.Compiler.EditorServices uses (global), so a change to (global) can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break (global).
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→2 FSharp.Compiler.EditorServices uses System.Collections✕
- Connections
- 51 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.EditorServices.AssemblyContentType→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.AssemblyContentType→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.CompletionContext→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.CompletionItemKind→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.CompletionItemKind→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.EntityKind→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.EntityKind→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.FSharpGlyph→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.FSharpGlyph→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.FindDeclExternalSymbol→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.FindDeclExternalType→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.FindDeclExternalType→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.FindDeclFailureReason→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.FindDeclFailureReason→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.FindDeclResult→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.InheritanceContext→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.InheritanceContext→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.InsertionContext→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.InsertionContextEntity→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.InsertionContextEntity→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.LookupType→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.LookupType→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.MaybeUnresolvedIdent→System.Collections.IStructuralComparableFSharp.Compiler.EditorServices.MaybeUnresolvedIdent→System.Collections.IStructuralEquatableFSharp.Compiler.EditorServices.MethodOverrideCompletionContext→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.EditorServices uses System.Collections, so a change to System.Collections can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→6 FSharp.Compiler.EditorServices uses System✕
- Connections
- 40 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in System. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.EditorServices.AssemblyContentType→System.IComparableFSharp.Compiler.EditorServices.AssemblyContentType→System.IComparable`1FSharp.Compiler.EditorServices.CompletionItemKind→System.IComparableFSharp.Compiler.EditorServices.CompletionItemKind→System.IComparable`1FSharp.Compiler.EditorServices.EntityKind→System.IComparableFSharp.Compiler.EditorServices.EntityKind→System.IComparable`1FSharp.Compiler.EditorServices.FSharpGlyph→System.IComparableFSharp.Compiler.EditorServices.FSharpGlyph→System.IComparable`1FSharp.Compiler.EditorServices.FSharpGlyph→System.IEquatable`1FSharp.Compiler.EditorServices.FindDeclExternalType→System.IComparableFSharp.Compiler.EditorServices.FindDeclExternalType→System.IComparable`1FSharp.Compiler.EditorServices.FindDeclFailureReason→System.IComparableFSharp.Compiler.EditorServices.FindDeclFailureReason→System.IComparable`1FSharp.Compiler.EditorServices.InheritanceContext→System.IComparableFSharp.Compiler.EditorServices.InheritanceContext→System.IComparable`1FSharp.Compiler.EditorServices.InsertionContextEntity→System.IComparableFSharp.Compiler.EditorServices.InsertionContextEntity→System.IComparable`1FSharp.Compiler.EditorServices.LookupType→System.IComparableFSharp.Compiler.EditorServices.LookupType→System.IComparable`1FSharp.Compiler.EditorServices.MaybeUnresolvedIdent→System.IComparableFSharp.Compiler.EditorServices.MaybeUnresolvedIdent→System.IComparable`1FSharp.Compiler.EditorServices.ModuleKind→System.IComparableFSharp.Compiler.EditorServices.ModuleKind→System.IComparable`1FSharp.Compiler.EditorServices.NavigableContainerType→System.IComparableFSharp.Compiler.EditorServices.NavigableContainerType→System.IComparable`1
- Direction
- FSharp.Compiler.EditorServices uses System, so a change to System can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break System.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→7 FSharp.Compiler.EditorServices uses FSharp.Compiler.Text✕
- Connections
- 18 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.EditorServices.CompletionContext→FSharp.Compiler.Text.PositionFSharp.Compiler.EditorServices.CompletionContext→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.DeclarationListInfo→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.FindDeclResult→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.InsertionContext→FSharp.Compiler.Text.PositionFSharp.Compiler.EditorServices.MethodGroup→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.MethodGroupItem→FSharp.Compiler.Text.TaggedTextFSharp.Compiler.EditorServices.MethodGroupItemParameter→FSharp.Compiler.Text.TaggedTextFSharp.Compiler.EditorServices.MethodOverrideCompletionContext→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.NavigableItem→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.NavigationItem→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.ParameterLocations→FSharp.Compiler.Text.PositionFSharp.Compiler.EditorServices.PatternContext→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.RecordContext→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.SemanticClassificationItem→FSharp.Compiler.Text.RangeFSharp.Compiler.EditorServices.ToolTipElement→FSharp.Compiler.Text.TaggedTextFSharp.Compiler.EditorServices.ToolTipElementData→FSharp.Compiler.Text.TaggedTextFSharp.Compiler.EditorServices.TupledArgumentLocation→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.EditorServices uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→14 FSharp.Compiler.EditorServices uses FSharp.Compiler.Syntax✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.EditorServices.NavigationItem→FSharp.Compiler.Syntax.SynAccessFSharp.Compiler.EditorServices.ParameterLocations→FSharp.Compiler.Syntax.ParsedInput
- Direction
- FSharp.Compiler.EditorServices uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→18 FSharp.Compiler.EditorServices uses FSharp.Compiler.TypedTree✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.EditorServices uses a type in FSharp.Compiler.TypedTree.
- The types involved
FSharp.Compiler.EditorServices.CompletionItem→FSharp.Compiler.TypedTree.EntityRef
- Direction
- FSharp.Compiler.EditorServices uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→21 FSharp.Compiler.EditorServices uses FSharp.Compiler.InfoReader✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in FSharp.Compiler.InfoReader.
- The types involved
FSharp.Compiler.EditorServices.DeclarationListInfo→FSharp.Compiler.InfoReader.InfoReaderFSharp.Compiler.EditorServices.MethodGroup→FSharp.Compiler.InfoReader.InfoReader
- Direction
- FSharp.Compiler.EditorServices uses FSharp.Compiler.InfoReader, so a change to FSharp.Compiler.InfoReader can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break FSharp.Compiler.InfoReader.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→22 FSharp.Compiler.EditorServices uses FSharp.Compiler.NameResolution✕
- Connections
- 3 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in FSharp.Compiler.NameResolution.
- The types involved
FSharp.Compiler.EditorServices.CompletionItem→FSharp.Compiler.NameResolution.ItemFSharp.Compiler.EditorServices.CompletionItem→FSharp.Compiler.NameResolution.ItemWithInstFSharp.Compiler.EditorServices.MethodGroup→FSharp.Compiler.NameResolution.ItemWithInst
- Direction
- FSharp.Compiler.EditorServices uses FSharp.Compiler.NameResolution, so a change to FSharp.Compiler.NameResolution can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break FSharp.Compiler.NameResolution.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→23 FSharp.Compiler.EditorServices uses FSharp.Compiler.Symbols✕
- Connections
- 7 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in FSharp.Compiler.Symbols.
- The types involved
FSharp.Compiler.EditorServices.AssemblySymbol→FSharp.Compiler.Symbols.FSharpSymbolFSharp.Compiler.EditorServices.DeclarationListItem→FSharp.Compiler.Symbols.FSharpAccessibilityFSharp.Compiler.EditorServices.MethodGroupItem→FSharp.Compiler.Symbols.FSharpXmlDocFSharp.Compiler.EditorServices.ToolTipElement→FSharp.Compiler.Symbols.FSharpSymbolFSharp.Compiler.EditorServices.ToolTipElement→FSharp.Compiler.Symbols.FSharpXmlDocFSharp.Compiler.EditorServices.ToolTipElementData→FSharp.Compiler.Symbols.FSharpSymbolFSharp.Compiler.EditorServices.ToolTipElementData→FSharp.Compiler.Symbols.FSharpXmlDoc
- Direction
- FSharp.Compiler.EditorServices uses FSharp.Compiler.Symbols, so a change to FSharp.Compiler.Symbols can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break FSharp.Compiler.Symbols.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→27 FSharp.Compiler.EditorServices uses FSharp.Compiler.TypedTreeOps✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in FSharp.Compiler.TypedTreeOps.
- The types involved
FSharp.Compiler.EditorServices.DeclarationListInfo→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.EditorServices.MethodGroup→FSharp.Compiler.TypedTreeOps.DisplayEnv
- Direction
- FSharp.Compiler.EditorServices uses FSharp.Compiler.TypedTreeOps, so a change to FSharp.Compiler.TypedTreeOps can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break FSharp.Compiler.TypedTreeOps.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
31→29 FSharp.Compiler.EditorServices uses FSharp.Compiler.AccessibilityLogic✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.EditorServices uses a type in FSharp.Compiler.AccessibilityLogic.
- The types involved
FSharp.Compiler.EditorServices.DeclarationListInfo→FSharp.Compiler.AccessibilityLogic.AccessorDomainFSharp.Compiler.EditorServices.MethodGroup→FSharp.Compiler.AccessibilityLogic.AccessorDomain
- Direction
- FSharp.Compiler.EditorServices uses FSharp.Compiler.AccessibilityLogic, so a change to FSharp.Compiler.AccessibilityLogic can break FSharp.Compiler.EditorServices, while a change to FSharp.Compiler.EditorServices can't break FSharp.Compiler.AccessibilityLogic.
- Position
- Below the diagonal: FSharp.Compiler.EditorServices uses a module listed above it, which is the healthy direction.
32→2 FSharp.Compiler.CheckBasics uses System.Collections✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CheckBasics uses a type in System.Collections.
- The types involved
FSharp.Compiler.CheckBasics.CheckConstraints→System.Collections.IStructuralComparableFSharp.Compiler.CheckBasics.CheckConstraints→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.CheckBasics uses System.Collections, so a change to System.Collections can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→3 FSharp.Compiler.CheckBasics uses System.Collections.Generic✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckBasics uses a type in System.Collections.Generic.
- The types involved
FSharp.Compiler.CheckBasics.UngeneralizableItem→System.Collections.Generic.IComparer`1
- Direction
- FSharp.Compiler.CheckBasics uses System.Collections.Generic, so a change to System.Collections.Generic can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break System.Collections.Generic.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→6 FSharp.Compiler.CheckBasics uses System✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CheckBasics uses a type in System.
- The types involved
FSharp.Compiler.CheckBasics.CheckConstraints→System.IComparableFSharp.Compiler.CheckBasics.CheckConstraints→System.IComparable`1
- Direction
- FSharp.Compiler.CheckBasics uses System, so a change to System can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break System.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→7 FSharp.Compiler.CheckBasics uses FSharp.Compiler.Text✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→10 FSharp.Compiler.CheckBasics uses Internal.Utilities.Collections.Tagged✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckBasics uses a type in Internal.Utilities.Collections.Tagged.
- The types involved
FSharp.Compiler.CheckBasics.UngeneralizableItem→Internal.Utilities.Collections.Tagged.Set`2
- Direction
- FSharp.Compiler.CheckBasics uses Internal.Utilities.Collections.Tagged, so a change to Internal.Utilities.Collections.Tagged can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break Internal.Utilities.Collections.Tagged.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→14 FSharp.Compiler.CheckBasics uses FSharp.Compiler.Syntax✕
- Connections
- 4 pairs of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.CheckBasics.PrelimVal1→FSharp.Compiler.Syntax.IdentFSharp.Compiler.CheckBasics.PrelimVal1→FSharp.Compiler.Syntax.SynAccessFSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.Syntax.IdentFSharp.Compiler.CheckBasics.TcPatValFlags→FSharp.Compiler.Syntax.SynAccess
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→18 FSharp.Compiler.CheckBasics uses FSharp.Compiler.TypedTree✕
- Connections
- 22 pairs of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.TypedTree.
- The types involved
FSharp.Compiler.CheckBasics.ArgAndRetAttribs→FSharp.Compiler.TypedTree.AttribFSharp.Compiler.CheckBasics.CtorInfo→FSharp.Compiler.TypedTree.ValFSharp.Compiler.CheckBasics.ExplicitTyparInfo→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.CheckBasics.PrelimMemberInfo→FSharp.Compiler.TypedTree.ValMemberInfoFSharp.Compiler.CheckBasics.PrelimVal1→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.CheckBasics.PrelimVal1→FSharp.Compiler.TypedTree.ValBaseOrThisInfoFSharp.Compiler.CheckBasics.PrelimVal1→FSharp.Compiler.TypedTree.ValInlineFSharp.Compiler.CheckBasics.PrelimValReprInfo→FSharp.Compiler.TypedTree.ArgReprInfoFSharp.Compiler.CheckBasics.SafeInitData→FSharp.Compiler.TypedTree.RecdFieldFSharp.Compiler.CheckBasics.SafeInitData→FSharp.Compiler.TypedTree.RecdFieldRefFSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.TypedTree.ArgReprInfoFSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.TypedTree.CompilationPathFSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.TypedTree.ModuleOrNamespaceTypeFSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.TypedTree.ArgReprInfoFSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.TypedTree.NamedDebugPointKeyFSharp.Compiler.CheckBasics.TcPatValFlags→FSharp.Compiler.TypedTree.ValInlineFSharp.Compiler.CheckBasics.UngeneralizableItem→FSharp.Compiler.TypedTree.EntityFSharp.Compiler.CheckBasics.UngeneralizableItem→FSharp.Compiler.TypedTree.FreeTyvarsFSharp.Compiler.CheckBasics.UngeneralizableItem→FSharp.Compiler.TypedTree.ValFSharp.Compiler.CheckBasics.UnscopedTyparEnv→FSharp.Compiler.TypedTree.Typar
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→19 FSharp.Compiler.CheckBasics uses FSharp.Compiler.TcGlobals✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→20 FSharp.Compiler.CheckBasics uses FSharp.Compiler.Import✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.Import.
- The types involved
FSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.Import.ImportMap
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.Import, so a change to FSharp.Compiler.Import can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.Import.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→21 FSharp.Compiler.CheckBasics uses FSharp.Compiler.InfoReader✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.InfoReader.
- The types involved
FSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.InfoReader.InfoReader
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.InfoReader, so a change to FSharp.Compiler.InfoReader can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.InfoReader.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→22 FSharp.Compiler.CheckBasics uses FSharp.Compiler.NameResolution✕
- Connections
- 3 pairs of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.NameResolution.
- The types involved
FSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.NameResolution.NameResolutionEnvFSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.NameResolution.NameResolverFSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.NameResolution.TcResultsSink
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.NameResolution, so a change to FSharp.Compiler.NameResolution can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.NameResolution.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→24 FSharp.Compiler.CheckBasics uses FSharp.Compiler.Diagnostics✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.Diagnostics.
- The types involved
FSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.Diagnostics.FSharpDiagnosticOptions
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.Diagnostics, so a change to FSharp.Compiler.Diagnostics can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.Diagnostics.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→25 FSharp.Compiler.CheckBasics uses FSharp.Compiler.DiagnosticsLogger✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.DiagnosticsLogger.
- The types involved
FSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.DiagnosticsLogger.StackGuard
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.DiagnosticsLogger, so a change to FSharp.Compiler.DiagnosticsLogger can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.DiagnosticsLogger.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→27 FSharp.Compiler.CheckBasics uses FSharp.Compiler.TypedTreeOps✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.TypedTreeOps.
- The types involved
FSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.TypedTreeOps.ValMultiMap`1
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.TypedTreeOps, so a change to FSharp.Compiler.TypedTreeOps can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.TypedTreeOps.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→29 FSharp.Compiler.CheckBasics uses FSharp.Compiler.AccessibilityLogic✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.AccessibilityLogic.
- The types involved
FSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.AccessibilityLogic.AccessorDomain
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.AccessibilityLogic, so a change to FSharp.Compiler.AccessibilityLogic can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.AccessibilityLogic.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
32→30 FSharp.Compiler.CheckBasics uses FSharp.Compiler.ConstraintSolver✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CheckBasics uses a type in FSharp.Compiler.ConstraintSolver.
- The types involved
FSharp.Compiler.CheckBasics.TcEnv→FSharp.Compiler.ConstraintSolver.ContextInfoFSharp.Compiler.CheckBasics.TcFileState→FSharp.Compiler.ConstraintSolver.ConstraintSolverState
- Direction
- FSharp.Compiler.CheckBasics uses FSharp.Compiler.ConstraintSolver, so a change to FSharp.Compiler.ConstraintSolver can break FSharp.Compiler.CheckBasics, while a change to FSharp.Compiler.CheckBasics can't break FSharp.Compiler.ConstraintSolver.
- Position
- Below the diagonal: FSharp.Compiler.CheckBasics uses a module listed above it, which is the healthy direction.
33→1 FSharp.Compiler.CodeAnalysis uses (global)✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in (global).
- The types involved
FSharp.Compiler.CodeAnalysis.ItemKeyStore→IDisposable
- Direction
- FSharp.Compiler.CodeAnalysis uses (global), so a change to (global) can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break (global).
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→2 FSharp.Compiler.CodeAnalysis uses System.Collections✕
- Connections
- 10 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in System.Collections.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileAnswer→System.Collections.IStructuralEquatableFSharp.Compiler.CodeAnalysis.FSharpCodeCompletionOptions→System.Collections.IStructuralComparableFSharp.Compiler.CodeAnalysis.FSharpCodeCompletionOptions→System.Collections.IStructuralEquatableFSharp.Compiler.CodeAnalysis.FSharpParsingOptions→System.Collections.IStructuralEquatableFSharp.Compiler.CodeAnalysis.FSharpProjectOptions→System.Collections.IStructuralEquatableFSharp.Compiler.CodeAnalysis.FSharpUnresolvedReferencesSet→System.Collections.IStructuralEquatableFSharp.Compiler.CodeAnalysis.LegacyResolutionEnvironment→System.Collections.IStructuralComparableFSharp.Compiler.CodeAnalysis.LegacyResolutionEnvironment→System.Collections.IStructuralEquatableFSharp.Compiler.CodeAnalysis.LegacyResolutionFailure→System.Collections.IStructuralEquatableFSharp.Compiler.CodeAnalysis.TextContainer→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.CodeAnalysis uses System.Collections, so a change to System.Collections can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→3 FSharp.Compiler.CodeAnalysis uses System.Collections.Generic✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in System.Collections.Generic.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→System.Collections.Generic.IEnumerable`1
- Direction
- FSharp.Compiler.CodeAnalysis uses System.Collections.Generic, so a change to System.Collections.Generic can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break System.Collections.Generic.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→6 FSharp.Compiler.CodeAnalysis uses System✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in System.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCodeCompletionOptions→System.IComparableFSharp.Compiler.CodeAnalysis.FSharpCodeCompletionOptions→System.IComparable`1FSharp.Compiler.CodeAnalysis.IncrementalBuilder→System.IDisposableFSharp.Compiler.CodeAnalysis.LegacyResolutionEnvironment→System.IComparableFSharp.Compiler.CodeAnalysis.LegacyResolutionEnvironment→System.IComparable`1FSharp.Compiler.CodeAnalysis.TextContainer→System.IDisposable
- Direction
- FSharp.Compiler.CodeAnalysis uses System, so a change to System can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break System.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→7 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.Text✕
- Connections
- 7 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.Text.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Text.ISourceTextFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Text.PositionFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Text.RangeFSharp.Compiler.CodeAnalysis.FSharpParseFileResults→FSharp.Compiler.Text.PositionFSharp.Compiler.CodeAnalysis.FSharpParseFileResults→FSharp.Compiler.Text.RangeFSharp.Compiler.CodeAnalysis.FSharpSymbolUse→FSharp.Compiler.Text.RangeFSharp.Compiler.CodeAnalysis.TextContainer→FSharp.Compiler.Text.ISourceText
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→11 FSharp.Compiler.CodeAnalysis uses Internal.Utilities.Library✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in Internal.Utilities.Library.
- The types involved
FSharp.Compiler.CodeAnalysis.DelayedILModuleReader→Internal.Utilities.Library.Cancellable`1
- Direction
- FSharp.Compiler.CodeAnalysis uses Internal.Utilities.Library, so a change to Internal.Utilities.Library can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break Internal.Utilities.Library.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→14 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.Syntax✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.Syntax.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpParseFileResults→FSharp.Compiler.Syntax.ParsedInput
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→18 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.TypedTree✕
- Connections
- 9 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.TypedTree.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.TypedTree.CheckedImplFileFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.TypedTree.ModuleOrNamespaceTypeFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.TypedTree.OpenDeclarationFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.TypedTree.CheckedImplFileFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.TypedTree.ModuleOrNamespaceTypeFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.TypedTree.OpenDeclaration
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→19 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.TcGlobals✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→22 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.NameResolution✕
- Connections
- 8 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.NameResolution.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.NameResolution.ItemFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.NameResolution.NameResolutionEnvFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.NameResolution.TcResolutionsFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.NameResolution.TcSymbolUsesFSharp.Compiler.CodeAnalysis.FSharpSymbolUse→FSharp.Compiler.NameResolution.ItemOccurrenceFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.NameResolution.NameResolutionEnvFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.NameResolution.TcResolutionsFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.NameResolution.TcSymbolUses
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.NameResolution, so a change to FSharp.Compiler.NameResolution can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.NameResolution.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→23 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.Symbols✕
- Connections
- 13 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.Symbols.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Symbols.FSharpAssemblySignatureFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Symbols.FSharpDisplayContextFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Symbols.FSharpImplementationFileContentsFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Symbols.FSharpOpenDeclarationFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Symbols.FSharpSymbolFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Symbols.FSharpTypeFSharp.Compiler.CodeAnalysis.FSharpCheckProjectResults→FSharp.Compiler.Symbols.FSharpAssemblyContentsFSharp.Compiler.CodeAnalysis.FSharpCheckProjectResults→FSharp.Compiler.Symbols.FSharpAssemblySignatureFSharp.Compiler.CodeAnalysis.FSharpCheckProjectResults→FSharp.Compiler.Symbols.FSharpSymbolFSharp.Compiler.CodeAnalysis.FSharpProjectContext→FSharp.Compiler.Symbols.FSharpAccessibilityRightsFSharp.Compiler.CodeAnalysis.FSharpProjectContext→FSharp.Compiler.Symbols.FSharpAssemblyFSharp.Compiler.CodeAnalysis.FSharpSymbolUse→FSharp.Compiler.Symbols.FSharpDisplayContextFSharp.Compiler.CodeAnalysis.FSharpSymbolUse→FSharp.Compiler.Symbols.FSharpSymbol
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.Symbols, so a change to FSharp.Compiler.Symbols can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.Symbols.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→24 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.Diagnostics✕
- Connections
- 4 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.Diagnostics.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.Diagnostics.FSharpDiagnosticFSharp.Compiler.CodeAnalysis.FSharpCheckProjectResults→FSharp.Compiler.Diagnostics.FSharpDiagnosticFSharp.Compiler.CodeAnalysis.FSharpParseFileResults→FSharp.Compiler.Diagnostics.FSharpDiagnosticFSharp.Compiler.CodeAnalysis.FSharpParsingOptions→FSharp.Compiler.Diagnostics.FSharpDiagnosticOptions
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.Diagnostics, so a change to FSharp.Compiler.Diagnostics can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.Diagnostics.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→26 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.CompilerConfig✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.CompilerConfig.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.CompilerConfig.TcConfigFSharp.Compiler.CodeAnalysis.FSharpCheckProjectResults→FSharp.Compiler.CompilerConfig.TcConfigFSharp.Compiler.CodeAnalysis.FSharpParsingOptions→FSharp.Compiler.CompilerConfig.TcConfigFSharp.Compiler.CodeAnalysis.FSharpParsingOptions→FSharp.Compiler.CompilerConfig.TcConfigBuilderFSharp.Compiler.CodeAnalysis.FSharpUnresolvedReferencesSet→FSharp.Compiler.CompilerConfig.UnresolvedAssemblyReferenceFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.CompilerConfig.TcConfig
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.CompilerConfig, so a change to FSharp.Compiler.CompilerConfig can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.CompilerConfig.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→27 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.TypedTreeOps✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.TypedTreeOps.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpSymbolUse→FSharp.Compiler.TypedTreeOps.DisplayEnv
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.TypedTreeOps, so a change to FSharp.Compiler.TypedTreeOps can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.TypedTreeOps.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→29 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.AccessibilityLogic✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.AccessibilityLogic.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.AccessibilityLogic.AccessorDomainFSharp.Compiler.CodeAnalysis.TypeCheckInfo→FSharp.Compiler.AccessibilityLogic.AccessorDomain
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.AccessibilityLogic, so a change to FSharp.Compiler.AccessibilityLogic can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.AccessibilityLogic.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
33→31 FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.EditorServices✕
- Connections
- 8 pairs of types, where a type in FSharp.Compiler.CodeAnalysis uses a type in FSharp.Compiler.EditorServices.
- The types involved
FSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.EditorServices.DeclarationListInfoFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.EditorServices.FindDeclResultFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.EditorServices.MethodGroupFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.EditorServices.PartialLongNameFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.EditorServices.SemanticClassificationItemFSharp.Compiler.CodeAnalysis.FSharpCheckFileResults→FSharp.Compiler.EditorServices.ToolTipTextFSharp.Compiler.CodeAnalysis.FSharpParseFileResults→FSharp.Compiler.EditorServices.NavigationItemsFSharp.Compiler.CodeAnalysis.FSharpParseFileResults→FSharp.Compiler.EditorServices.ParameterLocations
- Direction
- FSharp.Compiler.CodeAnalysis uses FSharp.Compiler.EditorServices, so a change to FSharp.Compiler.EditorServices can break FSharp.Compiler.CodeAnalysis, while a change to FSharp.Compiler.CodeAnalysis can't break FSharp.Compiler.EditorServices.
- Position
- Below the diagonal: FSharp.Compiler.CodeAnalysis uses a module listed above it, which is the healthy direction.
34→2 FSharp.Compiler.CheckExpressions uses System.Collections✕
- Connections
- 34 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in System.Collections. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.CheckExpressions.BakedInMemberConstraintName→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.DeclKind→System.Collections.IStructuralComparableFSharp.Compiler.CheckExpressions.DeclKind→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.DeprecatedThreadStaticBindingWarning→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.ImplicitlyBoundTyparsAllowed→System.Collections.IStructuralComparableFSharp.Compiler.CheckExpressions.ImplicitlyBoundTyparsAllowed→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.IntfImplInExtrinsicAugmentation→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.IntfImplInIntrinsicAugmentation→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.InvalidAttributeTargetForLanguageElement→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.InvalidInternalsVisibleToAssemblyName→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.IsObjExprBinding→System.Collections.IStructuralComparableFSharp.Compiler.CheckExpressions.IsObjExprBinding→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.LetRecCheckedAtRuntime→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.MissingFields→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.NewSlotsOK→System.Collections.IStructuralComparableFSharp.Compiler.CheckExpressions.NewSlotsOK→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.NonVirtualAugmentationOnNullValuedType→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.OverrideInExtrinsicAugmentation→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.OverrideInIntrinsicAugmentation→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.OverridesOK→System.Collections.IStructuralComparableFSharp.Compiler.CheckExpressions.OverridesOK→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.SelfRefObjCtor→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.StandardOperatorRedefinitionWarning→System.Collections.IStructuralEquatableFSharp.Compiler.CheckExpressions.TcCanFail→System.Collections.IStructuralComparableFSharp.Compiler.CheckExpressions.TcCanFail→System.Collections.IStructuralEquatable
- Direction
- FSharp.Compiler.CheckExpressions uses System.Collections, so a change to System.Collections can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break System.Collections.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→6 FSharp.Compiler.CheckExpressions uses System✕
- Connections
- 16 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in System.
- The types involved
FSharp.Compiler.CheckExpressions.DeclKind→System.IComparableFSharp.Compiler.CheckExpressions.DeclKind→System.IComparable`1FSharp.Compiler.CheckExpressions.ImplicitlyBoundTyparsAllowed→System.IComparableFSharp.Compiler.CheckExpressions.ImplicitlyBoundTyparsAllowed→System.IComparable`1FSharp.Compiler.CheckExpressions.IsObjExprBinding→System.IComparableFSharp.Compiler.CheckExpressions.IsObjExprBinding→System.IComparable`1FSharp.Compiler.CheckExpressions.NewSlotsOK→System.IComparableFSharp.Compiler.CheckExpressions.NewSlotsOK→System.IComparable`1FSharp.Compiler.CheckExpressions.OverridesOK→System.IComparableFSharp.Compiler.CheckExpressions.OverridesOK→System.IComparable`1FSharp.Compiler.CheckExpressions.TcCanFail→System.IComparableFSharp.Compiler.CheckExpressions.TcCanFail→System.IComparable`1FSharp.Compiler.CheckExpressions.TcTrueMatchClause→System.IComparableFSharp.Compiler.CheckExpressions.TcTrueMatchClause→System.IComparable`1FSharp.Compiler.CheckExpressions.WarnOnIWSAM→System.IComparableFSharp.Compiler.CheckExpressions.WarnOnIWSAM→System.IComparable`1
- Direction
- FSharp.Compiler.CheckExpressions uses System, so a change to System can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break System.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→7 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.Text✕
- Connections
- 46 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.Text. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.CheckExpressions.BakedInMemberConstraintName→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.CoercionTargetSealed→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.DeprecatedThreadStaticBindingWarning→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.FieldGivenTwice→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.FieldsFromDifferentTypes→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.FunctionExpected→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.FunctionValueUnexpected→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.IndeterminateRuntimeCoercion→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.IndeterminateStaticCoercion→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.IntfImplInExtrinsicAugmentation→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.IntfImplInIntrinsicAugmentation→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.InvalidAttributeTargetForLanguageElement→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.InvalidRuntimeCoercion→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.LetRecCheckedAtRuntime→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.LetRecEvaluatedOutOfOrder→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.LetRecUnsound→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.MissingFields→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.NonUniqueInferredAbstractSlot→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.NonVirtualAugmentationOnNullValuedType→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.NormalizedBinding→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.NotAFunction→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.NotAFunctionButIndexer→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.OverrideInExtrinsicAugmentation→FSharp.Compiler.Text.RangeFSharp.Compiler.CheckExpressions.OverrideInIntrinsicAugmentation→FSharp.Compiler.Text.Range
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→13 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.AbstractIL.IL✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.AbstractIL.IL.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.AbstractIL.IL.ILFieldInit
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.AbstractIL.IL, so a change to FSharp.Compiler.AbstractIL.IL can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.AbstractIL.IL.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→14 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.Syntax✕
- Connections
- 32 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.Syntax. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.IdentFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynAccessFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynAttributeFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynBindingFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynConstFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynExprFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynMemberFlagsFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynPatFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynTyparDeclFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynTypeFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynTypeConstraintFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynValInfoFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.Syntax.SynValSigFSharp.Compiler.CheckExpressions.NormalizedBinding→FSharp.Compiler.Syntax.DebugPointAtBindingFSharp.Compiler.CheckExpressions.NormalizedBinding→FSharp.Compiler.Syntax.SynAccessFSharp.Compiler.CheckExpressions.NormalizedBinding→FSharp.Compiler.Syntax.SynAttributeFSharp.Compiler.CheckExpressions.NormalizedBinding→FSharp.Compiler.Syntax.SynBindingKindFSharp.Compiler.CheckExpressions.NormalizedBinding→FSharp.Compiler.Syntax.SynPatFSharp.Compiler.CheckExpressions.NormalizedBinding→FSharp.Compiler.Syntax.SynValDataFSharp.Compiler.CheckExpressions.NormalizedBinding→FSharp.Compiler.Syntax.SynValTyparDeclsFSharp.Compiler.CheckExpressions.NormalizedBindingRhs→FSharp.Compiler.Syntax.SynBindingReturnInfoFSharp.Compiler.CheckExpressions.NormalizedBindingRhs→FSharp.Compiler.Syntax.SynExprFSharp.Compiler.CheckExpressions.NormalizedBindingRhs→FSharp.Compiler.Syntax.SynSimplePatsFSharp.Compiler.CheckExpressions.PrelimVal2→FSharp.Compiler.Syntax.IdentFSharp.Compiler.CheckExpressions.PrelimVal2→FSharp.Compiler.Syntax.SynAccess
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.Syntax, so a change to FSharp.Compiler.Syntax can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.Syntax.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→18 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.TypedTree✕
- Connections
- 66 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.TypedTree. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.AccessibilityFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ActivePatternElemRefFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.AttribFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.BindingFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.CcuThunkFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.CompilationPathFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ConstFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.EntityFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.EntityRefFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ExprFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ModuleOrNamespaceKindFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ModuleOrNamespaceTypeFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ParentRefFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.TyparFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.TyparKindFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.TyparRigidityFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ValFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ValRecursiveScopeInfoFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ValRefFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTree.ValReprInfoFSharp.Compiler.CheckExpressions.CoercionTargetSealed→FSharp.Compiler.TypedTree.TTypeFSharp.Compiler.CheckExpressions.ContainerInfo→FSharp.Compiler.TypedTree.ParentRefFSharp.Compiler.CheckExpressions.FieldGivenTwice→FSharp.Compiler.TypedTree.RecdFieldRefFSharp.Compiler.CheckExpressions.FieldsFromDifferentTypes→FSharp.Compiler.TypedTree.RecdFieldRef
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.TypedTree, so a change to FSharp.Compiler.TypedTree can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.TypedTree.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→19 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.TcGlobals✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.TcGlobals.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TcGlobals.TcGlobalsFSharp.Compiler.CheckExpressions.NonUniqueInferredAbstractSlot→FSharp.Compiler.TcGlobals.TcGlobals
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.TcGlobals, so a change to FSharp.Compiler.TcGlobals can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.TcGlobals.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→21 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.InfoReader✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.InfoReader.
- The types involved
FSharp.Compiler.CheckExpressions.ValueRestriction→FSharp.Compiler.InfoReader.InfoReader
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.InfoReader, so a change to FSharp.Compiler.InfoReader can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.InfoReader.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→22 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.NameResolution✕
- Connections
- 6 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.NameResolution.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.NameResolution.AfterResolutionFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.NameResolution.CheckForDuplicateTyparFlagFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.NameResolution.ItemFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.NameResolution.ItemOccurrenceFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.NameResolution.TcResultsSinkFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.NameResolution.WarnOnUpperFlag
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.NameResolution, so a change to FSharp.Compiler.NameResolution can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.NameResolution.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→27 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.TypedTreeOps✕
- Connections
- 31 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.TypedTreeOps. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.TypedTreeOps.GeneralizedTypeFSharp.Compiler.CheckExpressions.CoercionTargetSealed→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.FieldGivenTwice→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.FieldsFromDifferentTypes→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.FunctionExpected→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.FunctionValueUnexpected→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.IndeterminateRuntimeCoercion→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.IndeterminateStaticCoercion→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.InvalidRuntimeCoercion→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.LetRecEvaluatedOutOfOrder→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.LetRecUnsound→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.NonUniqueInferredAbstractSlot→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.NotAFunction→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.NotAFunctionButIndexer→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.PrelimVal2→FSharp.Compiler.TypedTreeOps.GeneralizedTypeFSharp.Compiler.CheckExpressions.Recursion→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.RecursiveUseCheckedAtRuntime→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.RuntimeCoercionSourceSealed→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.StaticCoercionShouldUseBox→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.TyconBadArgs→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.UnionCaseWrongArguments→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.UnionCaseWrongNumberOfArgs→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.UnitTypeExpected→FSharp.Compiler.TypedTreeOps.DisplayEnvFSharp.Compiler.CheckExpressions.UnitTypeExpectedWithEquality→FSharp.Compiler.TypedTreeOps.DisplayEnv
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.TypedTreeOps, so a change to FSharp.Compiler.TypedTreeOps can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.TypedTreeOps.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→28 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.Infos✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.Infos.
- The types involved
FSharp.Compiler.CheckExpressions.NonUniqueInferredAbstractSlot→FSharp.Compiler.Infos.MethInfo
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.Infos, so a change to FSharp.Compiler.Infos can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.Infos.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→29 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.AccessibilityLogic✕
- Connections
- 1 pair of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.AccessibilityLogic.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.AccessibilityLogic.AccessorDomain
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.AccessibilityLogic, so a change to FSharp.Compiler.AccessibilityLogic can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.AccessibilityLogic.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→30 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.ConstraintSolver✕
- Connections
- 2 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.ConstraintSolver.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.ConstraintSolver.ContextInfoFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.ConstraintSolver.OverallTy
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.ConstraintSolver, so a change to FSharp.Compiler.ConstraintSolver can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.ConstraintSolver.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
34→32 FSharp.Compiler.CheckExpressions uses FSharp.Compiler.CheckBasics✕
- Connections
- 24 pairs of types, where a type in FSharp.Compiler.CheckExpressions uses a type in FSharp.Compiler.CheckBasics.
- The types involved
FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.ArgAndRetAttribsFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.CheckConstraintsFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.ExplicitTyparInfoFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.PrelimMemberInfoFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.PrelimVal1FSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.PrelimValReprInfoFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.SafeInitDataFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.TcEnvFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.TcFileStateFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.TcPatLinearEnvFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.TcPatValFlagsFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.UngeneralizableItemFSharp.Compiler.CheckExpressions.CheckExpressions→FSharp.Compiler.CheckBasics.UnscopedTyparEnvFSharp.Compiler.CheckExpressions.MemberOrValContainerInfo→FSharp.Compiler.CheckBasics.SafeInitDataFSharp.Compiler.CheckExpressions.PrelimVal2→FSharp.Compiler.CheckBasics.ArgAndRetAttribsFSharp.Compiler.CheckExpressions.PrelimVal2→FSharp.Compiler.CheckBasics.PrelimMemberInfoFSharp.Compiler.CheckExpressions.PrelimVal2→FSharp.Compiler.CheckBasics.PrelimValReprInfoFSharp.Compiler.CheckExpressions.RecursiveBindingInfo→FSharp.Compiler.CheckBasics.ExplicitTyparInfoFSharp.Compiler.CheckExpressions.RecursiveBindingInfo→FSharp.Compiler.CheckBasics.PrelimMemberInfoFSharp.Compiler.CheckExpressions.RecursiveBindingInfo→FSharp.Compiler.CheckBasics.PrelimValReprInfoFSharp.Compiler.CheckExpressions.RecursiveBindingInfo→FSharp.Compiler.CheckBasics.SafeInitDataFSharp.Compiler.CheckExpressions.ValScheme→FSharp.Compiler.CheckBasics.PrelimMemberInfoFSharp.Compiler.CheckExpressions.ValSpecResult→FSharp.Compiler.CheckBasics.PrelimMemberInfoFSharp.Compiler.CheckExpressions.ValSpecResult→FSharp.Compiler.CheckBasics.PrelimValReprInfo
- Direction
- FSharp.Compiler.CheckExpressions uses FSharp.Compiler.CheckBasics, so a change to FSharp.Compiler.CheckBasics can break FSharp.Compiler.CheckExpressions, while a change to FSharp.Compiler.CheckExpressions can't break FSharp.Compiler.CheckBasics.
- Position
- Below the diagonal: FSharp.Compiler.CheckExpressions uses a module listed above it, which is the healthy direction.
35→2 Fable uses System.Collections✕
- Connections
- 13 pairs of types, where a type in Fable uses a type in System.Collections.
- The types involved
Fable.CompilerOptions→System.Collections.IStructuralComparableFable.CompilerOptions→System.Collections.IStructuralEquatableFable.CompilerPlugins→System.Collections.IStructuralEquatableFable.InlineExpr→System.Collections.IStructuralComparableFable.InlineExpr→System.Collections.IStructuralEquatableFable.Language→System.Collections.IStructuralComparableFable.Language→System.Collections.IStructuralEquatableFable.OutputType→System.Collections.IStructuralComparableFable.OutputType→System.Collections.IStructuralEquatableFable.Severity→System.Collections.IStructuralComparableFable.Severity→System.Collections.IStructuralEquatableFable.Verbosity→System.Collections.IStructuralComparableFable.Verbosity→System.Collections.IStructuralEquatable
- Direction
- Fable uses System.Collections, so a change to System.Collections can break Fable, while a change to Fable can't break System.Collections.
- Position
- Below the diagonal: Fable uses a module listed above it, which is the healthy direction.
35→3 Fable uses System.Collections.Generic✕
- Connections
- 1 pair of types, where a type in Fable uses a type in System.Collections.Generic.
- The types involved
Fable.PluginHelper→System.Collections.Generic.IEnumerable`1
- Direction
- Fable uses System.Collections.Generic, so a change to System.Collections.Generic can break Fable, while a change to Fable can't break System.Collections.Generic.
- Position
- Below the diagonal: Fable uses a module listed above it, which is the healthy direction.
35→6 Fable uses System✕
- Connections
- 21 pairs of types, where a type in Fable uses a type in System.
- The types involved
Fable.CompilerOptions→System.IComparableFable.CompilerOptions→System.IComparable`1Fable.CompilerOptions→System.IEquatable`1Fable.CompilerPlugins→System.IEquatable`1Fable.InlineExpr→System.IComparableFable.InlineExpr→System.IComparable`1Fable.InlineExpr→System.IEquatable`1Fable.Language→System.IComparableFable.Language→System.IComparable`1Fable.Language→System.IEquatable`1Fable.OutputType→System.IComparableFable.OutputType→System.IComparable`1Fable.OutputType→System.IEquatable`1Fable.PluginAttribute→System.AttributeFable.ScanForPluginsAttribute→System.AttributeFable.Severity→System.IComparableFable.Severity→System.IComparable`1Fable.Severity→System.IEquatable`1Fable.Verbosity→System.IComparableFable.Verbosity→System.IComparable`1Fable.Verbosity→System.IEquatable`1
- Direction
- Fable uses System, so a change to System can break Fable, while a change to Fable can't break System.
- Position
- Below the diagonal: Fable uses a module listed above it, which is the healthy direction.
35→8 Fable uses Fable.AST✕
- Connections
- 2 pairs of types, where a type in Fable uses a type in Fable.AST.
- The types involved
Fable.Compiler→Fable.AST.SourceLocationFable.PluginHelper→Fable.AST.SourceLocation
- Direction
- Fable uses Fable.AST, so a change to Fable.AST can break Fable, while a change to Fable can't break Fable.AST.
- Position
- Below the diagonal: Fable uses a module listed above it, which is the healthy direction.
35→15 Fable uses Fable.AST.Fable✕
- Connections
- 13 pairs of types, where a type in Fable uses a type in Fable.AST.Fable.
- The types involved
Fable.Compiler→Fable.AST.Fable.EntityFable.Compiler→Fable.AST.Fable.EntityRefFable.CompilerPlugins→Fable.AST.Fable.EntityRefFable.InlineExpr→Fable.AST.Fable.ExprFable.InlineExpr→Fable.AST.Fable.IdentFable.MemberDeclarationPluginAttribute→Fable.AST.Fable.ExprFable.MemberDeclarationPluginAttribute→Fable.AST.Fable.FileFable.MemberDeclarationPluginAttribute→Fable.AST.Fable.MemberDeclFable.MemberDeclarationPluginAttribute→Fable.AST.Fable.MemberFunctionOrValueFable.PluginHelper→Fable.AST.Fable.EntityFable.PluginHelper→Fable.AST.Fable.EntityRefFable.PluginHelper→Fable.AST.Fable.MemberFunctionOrValueFable.PluginHelper→Fable.AST.Fable.MemberRef
- Direction
- Fable uses Fable.AST.Fable, so a change to Fable.AST.Fable can break Fable, while a change to Fable can't break Fable.AST.Fable.
- Position
- Below the diagonal: Fable uses a module listed above it, which is the healthy direction.
35→23 Fable uses FSharp.Compiler.Symbols✕
- Connections
- 1 pair of types, where a type in Fable uses a type in FSharp.Compiler.Symbols.
- The types involved
Fable.Compiler→FSharp.Compiler.Symbols.FSharpImplementationFileDeclaration
- Direction
- Fable uses FSharp.Compiler.Symbols, so a change to FSharp.Compiler.Symbols can break Fable, while a change to Fable can't break FSharp.Compiler.Symbols.
- Position
- Below the diagonal: Fable uses a module listed above it, which is the healthy direction.
35→33 Fable uses FSharp.Compiler.CodeAnalysis✕
- Connections
- 1 pair of types, where a type in Fable uses a type in FSharp.Compiler.CodeAnalysis.
- The types involved
Fable.Compiler→FSharp.Compiler.CodeAnalysis.FSharpProjectOptions
- Direction
- Fable uses FSharp.Compiler.CodeAnalysis, so a change to FSharp.Compiler.CodeAnalysis can break Fable, while a change to Fable can't break FSharp.Compiler.CodeAnalysis.
- Position
- Below the diagonal: Fable uses a module listed above it, which is the healthy direction.
36→2 Fable.Transforms.FSharp2Fable uses System.Collections✕
- Connections
- 2 pairs of types, where a type in Fable.Transforms.FSharp2Fable uses a type in System.Collections.
- The types involved
Fable.Transforms.FSharp2Fable.CompiledValue→System.Collections.IStructuralComparableFable.Transforms.FSharp2Fable.CompiledValue→System.Collections.IStructuralEquatable
- Direction
- Fable.Transforms.FSharp2Fable uses System.Collections, so a change to System.Collections can break Fable.Transforms.FSharp2Fable, while a change to Fable.Transforms.FSharp2Fable can't break System.Collections.
- Position
- Below the diagonal: Fable.Transforms.FSharp2Fable uses a module listed above it, which is the healthy direction.
36→3 Fable.Transforms.FSharp2Fable uses System.Collections.Generic✕
- Connections
- 3 pairs of types, where a type in Fable.Transforms.FSharp2Fable uses a type in System.Collections.Generic.
- The types involved
Fable.Transforms.FSharp2Fable.FsEnt→System.Collections.Generic.IEnumerable`1Fable.Transforms.FSharp2Fable.FsMemberFunctionOrValue→System.Collections.Generic.IEnumerable`1Fable.Transforms.FSharp2Fable.FsParam→System.Collections.Generic.IEnumerable`1
- Direction
- Fable.Transforms.FSharp2Fable uses System.Collections.Generic, so a change to System.Collections.Generic can break Fable.Transforms.FSharp2Fable, while a change to Fable.Transforms.FSharp2Fable can't break System.Collections.Generic.
- Position
- Below the diagonal: Fable.Transforms.FSharp2Fable uses a module listed above it, which is the healthy direction.
36→6 Fable.Transforms.FSharp2Fable uses System✕
- Connections
- 3 pairs of types, where a type in Fable.Transforms.FSharp2Fable uses a type in System.
- The types involved
Fable.Transforms.FSharp2Fable.CompiledValue→System.IComparableFable.Transforms.FSharp2Fable.CompiledValue→System.IComparable`1Fable.Transforms.FSharp2Fable.CompiledValue→System.IEquatable`1
- Direction
- Fable.Transforms.FSharp2Fable uses System, so a change to System can break Fable.Transforms.FSharp2Fable, while a change to Fable.Transforms.FSharp2Fable can't break System.
- Position
- Below the diagonal: Fable.Transforms.FSharp2Fable uses a module listed above it, which is the healthy direction.
36→8 Fable.Transforms.FSharp2Fable uses Fable.AST✕
- Connections
- 1 pair of types, where a type in Fable.Transforms.FSharp2Fable uses a type in Fable.AST.
- The types involved
Fable.Transforms.FSharp2Fable.IFableCompiler→Fable.AST.SourceLocation
- Direction
- Fable.Transforms.FSharp2Fable uses Fable.AST, so a change to Fable.AST can break Fable.Transforms.FSharp2Fable, while a change to Fable.Transforms.FSharp2Fable can't break Fable.AST.
- Position
- Below the diagonal: Fable.Transforms.FSharp2Fable uses a module listed above it, which is the healthy direction.
36→15 Fable.Transforms.FSharp2Fable uses Fable.AST.Fable✕
- Connections
- 39 pairs of types, where a type in Fable.Transforms.FSharp2Fable uses a type in Fable.AST.Fable. Showing 25 of them; the rest are in namespace-graph.json in this report's bundle.
- The types involved
Fable.Transforms.FSharp2Fable.Context→Fable.AST.Fable.IdentFable.Transforms.FSharp2Fable.Context→Fable.AST.Fable.TypeFable.Transforms.FSharp2Fable.Context→Fable.AST.Fable.WitnessFable.Transforms.FSharp2Fable.FsAbstractSignature→Fable.AST.Fable.AbstractSignatureFable.Transforms.FSharp2Fable.FsAbstractSignature→Fable.AST.Fable.TypeFable.Transforms.FSharp2Fable.FsAtt→Fable.AST.Fable.AttributeFable.Transforms.FSharp2Fable.FsAtt→Fable.AST.Fable.EntityRefFable.Transforms.FSharp2Fable.FsDeclaredType→Fable.AST.Fable.DeclaredTypeFable.Transforms.FSharp2Fable.FsDeclaredType→Fable.AST.Fable.EntityRefFable.Transforms.FSharp2Fable.FsDeclaredType→Fable.AST.Fable.TypeFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.AttributeFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.DeclaredTypeFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.EntityFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.EntityRefFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.FieldFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.GenericParamFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.MemberFunctionOrValueFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.MemberRefInfoFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.TypeFable.Transforms.FSharp2Fable.FsEnt→Fable.AST.Fable.UnionCaseFable.Transforms.FSharp2Fable.FsField→Fable.AST.Fable.FieldFable.Transforms.FSharp2Fable.FsField→Fable.AST.Fable.TypeFable.Transforms.FSharp2Fable.FsGenParam→Fable.AST.Fable.ConstraintFable.Transforms.FSharp2Fable.FsGenParam→Fable.AST.Fable.GenericParamFable.Transforms.FSharp2Fable.FsMemberFunctionOrValue→Fable.AST.Fable.AbstractSignature
- Direction
- Fable.Transforms.FSharp2Fable uses Fable.AST.Fable, so a change to Fable.AST.Fable can break Fable.Transforms.FSharp2Fable, while a change to Fable.Transforms.FSharp2Fable can't break Fable.AST.Fable.
- Position
- Below the diagonal: Fable.Transforms.FSharp2Fable uses a module listed above it, which is the healthy direction.
36→23 Fable.Transforms.FSharp2Fable uses FSharp.Compiler.Symbols✕
- Connections
- 14 pairs of types, where a type in Fable.Transforms.FSharp2Fable uses a type in FSharp.Compiler.Symbols.
- The types involved
Fable.Transforms.FSharp2Fable.Context→FSharp.Compiler.Symbols.FSharpMemberOrFunctionOrValueFable.Transforms.FSharp2Fable.FsAbstractSignature→FSharp.Compiler.Symbols.FSharpAbstractSignatureFable.Transforms.FSharp2Fable.FsAtt→FSharp.Compiler.Symbols.FSharpAttributeFable.Transforms.FSharp2Fable.FsDeclaredType→FSharp.Compiler.Symbols.FSharpEntityFable.Transforms.FSharp2Fable.FsDeclaredType→FSharp.Compiler.Symbols.FSharpTypeFable.Transforms.FSharp2Fable.FsEnt→FSharp.Compiler.Symbols.FSharpEntityFable.Transforms.FSharp2Fable.FsEnt→FSharp.Compiler.Symbols.FSharpMemberOrFunctionOrValueFable.Transforms.FSharp2Fable.FsField→FSharp.Compiler.Symbols.FSharpFieldFable.Transforms.FSharp2Fable.FsGenParam→FSharp.Compiler.Symbols.FSharpGenericParameterFable.Transforms.FSharp2Fable.FsGenParam→FSharp.Compiler.Symbols.FSharpGenericParameterConstraintFable.Transforms.FSharp2Fable.FsMemberFunctionOrValue→FSharp.Compiler.Symbols.FSharpMemberOrFunctionOrValueFable.Transforms.FSharp2Fable.FsParam→FSharp.Compiler.Symbols.FSharpParameterFable.Transforms.FSharp2Fable.FsUnionCase→FSharp.Compiler.Symbols.FSharpUnionCaseFable.Transforms.FSharp2Fable.IFableCompiler→FSharp.Compiler.Symbols.FSharpExpr
- Direction
- Fable.Transforms.FSharp2Fable uses FSharp.Compiler.Symbols, so a change to FSharp.Compiler.Symbols can break Fable.Transforms.FSharp2Fable, while a change to Fable.Transforms.FSharp2Fable can't break FSharp.Compiler.Symbols.
- Position
- Below the diagonal: Fable.Transforms.FSharp2Fable uses a module listed above it, which is the healthy direction.
36→35 Fable.Transforms.FSharp2Fable uses Fable✕
- Connections
- 2 pairs of types, where a type in Fable.Transforms.FSharp2Fable uses a type in Fable.
- The types involved
Fable.Transforms.FSharp2Fable.IFableCompiler→Fable.CompilerFable.Transforms.FSharp2Fable.IFableCompiler→Fable.InlineExpr
- Direction
- Fable.Transforms.FSharp2Fable uses Fable, so a change to Fable can break Fable.Transforms.FSharp2Fable, while a change to Fable.Transforms.FSharp2Fable can't break Fable.
- Position
- Below the diagonal: Fable.Transforms.FSharp2Fable uses a module listed above it, which is the healthy direction.
37→2 Fable.Transforms.Printer uses System.Collections✕
- Connections
- 2 pairs of types, where a type in Fable.Transforms.Printer uses a type in System.Collections.
- The types involved
Fable.Transforms.Printer.ParsedXmlDoc→System.Collections.IStructuralComparableFable.Transforms.Printer.ParsedXmlDoc→System.Collections.IStructuralEquatable
- Direction
- Fable.Transforms.Printer uses System.Collections, so a change to System.Collections can break Fable.Transforms.Printer, while a change to Fable.Transforms.Printer can't break System.Collections.
- Position
- Below the diagonal: Fable.Transforms.Printer uses a module listed above it, which is the healthy direction.
37→6 Fable.Transforms.Printer uses System✕
- Connections
- 5 pairs of types, where a type in Fable.Transforms.Printer uses a type in System.
- The types involved
Fable.Transforms.Printer.ParsedXmlDoc→System.IComparableFable.Transforms.Printer.ParsedXmlDoc→System.IComparable`1Fable.Transforms.Printer.ParsedXmlDoc→System.IEquatable`1Fable.Transforms.Printer.PrinterImpl→System.IDisposableFable.Transforms.Printer.Writer→System.IDisposable
- Direction
- Fable.Transforms.Printer uses System, so a change to System can break Fable.Transforms.Printer, while a change to Fable.Transforms.Printer can't break System.
- Position
- Below the diagonal: Fable.Transforms.Printer uses a module listed above it, which is the healthy direction.
37→8 Fable.Transforms.Printer uses Fable.AST✕
- Connections
- 2 pairs of types, where a type in Fable.Transforms.Printer uses a type in Fable.AST.
- The types involved
Fable.Transforms.Printer.PrinterImpl→Fable.AST.SourceLocationFable.Transforms.Printer.Writer→Fable.AST.SourceLocation
- Direction
- Fable.Transforms.Printer uses Fable.AST, so a change to Fable.AST can break Fable.Transforms.Printer, while a change to Fable.Transforms.Printer can't break Fable.AST.
- Position
- Below the diagonal: Fable.Transforms.Printer uses a module listed above it, which is the healthy direction.
37→35 Fable.Transforms.Printer uses Fable✕
- Connections
- 2 pairs of types, where a type in Fable.Transforms.Printer uses a type in Fable.
- The types involved
Fable.Transforms.Printer.PrinterImpl→Fable.SeverityFable.Transforms.Printer.Writer→Fable.Severity
- Direction
- Fable.Transforms.Printer uses Fable, so a change to Fable can break Fable.Transforms.Printer, while a change to Fable.Transforms.Printer can't break Fable.
- Position
- Below the diagonal: Fable.Transforms.Printer uses a module listed above it, which is the healthy direction.
38→2 Fable.Transforms.State uses System.Collections✕
- Connections
- 10 pairs of types, where a type in Fable.Transforms.State uses a type in System.Collections.
- The types involved
Fable.Transforms.State.EntitySignature→System.Collections.IStructuralEquatableFable.Transforms.State.FileSignature→System.Collections.IStructuralEquatableFable.Transforms.State.ImplFile→System.Collections.IStructuralEquatableFable.Transforms.State.LogEntry→System.Collections.IStructuralComparableFable.Transforms.State.LogEntry→System.Collections.IStructuralEquatableFable.Transforms.State.MemberSignature→System.Collections.IStructuralEquatableFable.Transforms.State.ParameterSignature→System.Collections.IStructuralComparableFable.Transforms.State.ParameterSignature→System.Collections.IStructuralEquatableFable.Transforms.State.PluginRef→System.Collections.IStructuralComparableFable.Transforms.State.PluginRef→System.Collections.IStructuralEquatable
- Direction
- Fable.Transforms.State uses System.Collections, so a change to System.Collections can break Fable.Transforms.State, while a change to Fable.Transforms.State can't break System.Collections.
- Position
- Below the diagonal: Fable.Transforms.State uses a module listed above it, which is the healthy direction.
38→3 Fable.Transforms.State uses System.Collections.Generic✕
- Connections
- 1 pair of types, where a type in Fable.Transforms.State uses a type in System.Collections.Generic.
- The types involved
Fable.Transforms.State.State→System.Collections.Generic.IEnumerable`1
- Direction
- Fable.Transforms.State uses System.Collections.Generic, so a change to System.Collections.Generic can break Fable.Transforms.State, while a change to Fable.Transforms.State can't break System.Collections.Generic.
- Position
- Below the diagonal: Fable.Transforms.State uses a module listed above it, which is the healthy direction.
38→6 Fable.Transforms.State uses System✕
- Connections
- 13 pairs of types, where a type in Fable.Transforms.State uses a type in System.
- The types involved
Fable.Transforms.State.EntitySignature→System.IEquatable`1Fable.Transforms.State.FileSignature→System.IEquatable`1Fable.Transforms.State.ImplFile→System.IEquatable`1Fable.Transforms.State.LogEntry→System.IComparableFable.Transforms.State.LogEntry→System.IComparable`1Fable.Transforms.State.LogEntry→System.IEquatable`1Fable.Transforms.State.MemberSignature→System.IEquatable`1Fable.Transforms.State.ParameterSignature→System.IComparableFable.Transforms.State.ParameterSignature→System.IComparable`1Fable.Transforms.State.ParameterSignature→System.IEquatable`1Fable.Transforms.State.PluginRef→System.IComparableFable.Transforms.State.PluginRef→System.IComparable`1Fable.Transforms.State.PluginRef→System.IEquatable`1
- Direction
- Fable.Transforms.State uses System, so a change to System can break Fable.Transforms.State, while a change to Fable.Transforms.State can't break System.
- Position
- Below the diagonal: Fable.Transforms.State uses a module listed above it, which is the healthy direction.
38→8 Fable.Transforms.State uses Fable.AST✕
- Connections
- 2 pairs of types, where a type in Fable.Transforms.State uses a type in Fable.AST.
- The types involved
Fable.Transforms.State.CompilerImpl→Fable.AST.SourceLocationFable.Transforms.State.LogEntry→Fable.AST.SourceLocation
- Direction
- Fable.Transforms.State uses Fable.AST, so a change to Fable.AST can break Fable.Transforms.State, while a change to Fable.Transforms.State can't break Fable.AST.
- Position
- Below the diagonal: Fable.Transforms.State uses a module listed above it, which is the healthy direction.
38→15 Fable.Transforms.State uses Fable.AST.Fable✕
- Connections
- 5 pairs of types, where a type in Fable.Transforms.State uses a type in Fable.AST.Fable.
- The types involved
Fable.Transforms.State.Assemblies→Fable.AST.Fable.EntityFable.Transforms.State.CompilerImpl→Fable.AST.Fable.EntityFable.Transforms.State.CompilerImpl→Fable.AST.Fable.EntityRefFable.Transforms.State.ImplFile→Fable.AST.Fable.EntityFable.Transforms.State.MemberSignature→Fable.AST.Fable.Type
- Direction
- Fable.Transforms.State uses Fable.AST.Fable, so a change to Fable.AST.Fable can break Fable.Transforms.State, while a change to Fable.Transforms.State can't break Fable.AST.Fable.
- Position
- Below the diagonal: Fable.Transforms.State uses a module listed above it, which is the healthy direction.
38→23 Fable.Transforms.State uses FSharp.Compiler.Symbols✕
- Connections
- 8 pairs of types, where a type in Fable.Transforms.State uses a type in FSharp.Compiler.Symbols.
- The types involved
Fable.Transforms.State.Assemblies→FSharp.Compiler.Symbols.FSharpAssemblyFable.Transforms.State.CompilerImpl→FSharp.Compiler.Symbols.FSharpImplementationFileDeclarationFable.Transforms.State.ImplFile→FSharp.Compiler.Symbols.FSharpImplementationFileContentsFable.Transforms.State.ImplFile→FSharp.Compiler.Symbols.FSharpImplementationFileDeclarationFable.Transforms.State.ImplFile→FSharp.Compiler.Symbols.FSharpXmlDocFable.Transforms.State.MemberSignature→FSharp.Compiler.Symbols.FSharpInlineAnnotationFable.Transforms.State.Project→FSharp.Compiler.Symbols.FSharpAssemblyFable.Transforms.State.Project→FSharp.Compiler.Symbols.FSharpImplementationFileContents
- Direction
- Fable.Transforms.State uses FSharp.Compiler.Symbols, so a change to FSharp.Compiler.Symbols can break Fable.Transforms.State, while a change to Fable.Transforms.State can't break FSharp.Compiler.Symbols.
- Position
- Below the diagonal: Fable.Transforms.State uses a module listed above it, which is the healthy direction.
38→33 Fable.Transforms.State uses FSharp.Compiler.CodeAnalysis✕
- Connections
- 2 pairs of types, where a type in Fable.Transforms.State uses a type in FSharp.Compiler.CodeAnalysis.
- The types involved
Fable.Transforms.State.CompilerImpl→FSharp.Compiler.CodeAnalysis.FSharpProjectOptionsFable.Transforms.State.Project→FSharp.Compiler.CodeAnalysis.FSharpProjectOptions
- Direction
- Fable.Transforms.State uses FSharp.Compiler.CodeAnalysis, so a change to FSharp.Compiler.CodeAnalysis can break Fable.Transforms.State, while a change to Fable.Transforms.State can't break FSharp.Compiler.CodeAnalysis.
- Position
- Below the diagonal: Fable.Transforms.State uses a module listed above it, which is the healthy direction.
38→35 Fable.Transforms.State uses Fable✕
- Connections
- 12 pairs of types, where a type in Fable.Transforms.State uses a type in Fable.
- The types involved
Fable.Transforms.State.Assemblies→Fable.CompilerPluginsFable.Transforms.State.CompilerImpl→Fable.CompilerFable.Transforms.State.CompilerImpl→Fable.CompilerOptionsFable.Transforms.State.CompilerImpl→Fable.CompilerPluginsFable.Transforms.State.CompilerImpl→Fable.InlineExprFable.Transforms.State.CompilerImpl→Fable.OutputTypeFable.Transforms.State.CompilerImpl→Fable.SeverityFable.Transforms.State.LogEntry→Fable.SeverityFable.Transforms.State.PrecompiledInfo→Fable.InlineExprFable.Transforms.State.Project→Fable.CompilerFable.Transforms.State.Project→Fable.InlineExprFable.Transforms.State.Project→Fable.InlineExprLazy
- Direction
- Fable.Transforms.State uses Fable, so a change to Fable can break Fable.Transforms.State, while a change to Fable.Transforms.State can't break Fable.
- Position
- Below the diagonal: Fable.Transforms.State uses a module listed above it, which is the healthy direction.
39→2 Fable.Compiler.Util uses System.Collections✕
- Connections
- 5 pairs of types, where a type in Fable.Compiler.Util uses a type in System.Collections.
- The types involved
Fable.Compiler.Util.CliArgs→System.Collections.IStructuralEquatableFable.Compiler.Util.PrecompiledFileJson→System.Collections.IStructuralComparableFable.Compiler.Util.PrecompiledFileJson→System.Collections.IStructuralEquatableFable.Compiler.Util.PrecompiledInfoJson→System.Collections.IStructuralComparableFable.Compiler.Util.PrecompiledInfoJson→System.Collections.IStructuralEquatable
- Direction
- Fable.Compiler.Util uses System.Collections, so a change to System.Collections can break Fable.Compiler.Util, while a change to Fable.Compiler.Util can't break System.Collections.
- Position
- Below the diagonal: Fable.Compiler.Util uses a module listed above it, which is the healthy direction.
39→6 Fable.Compiler.Util uses System✕
- Connections
- 4 pairs of types, where a type in Fable.Compiler.Util uses a type in System.
- The types involved
Fable.Compiler.Util.PrecompiledFileJson→System.IComparableFable.Compiler.Util.PrecompiledFileJson→System.IComparable`1Fable.Compiler.Util.PrecompiledInfoJson→System.IComparableFable.Compiler.Util.PrecompiledInfoJson→System.IComparable`1
- Direction
- Fable.Compiler.Util uses System, so a change to System can break Fable.Compiler.Util, while a change to Fable.Compiler.Util can't break System.
- Position
- Below the diagonal: Fable.Compiler.Util uses a module listed above it, which is the healthy direction.
39→35 Fable.Compiler.Util uses Fable✕
- Connections
- 4 pairs of types, where a type in Fable.Compiler.Util uses a type in Fable.
- The types involved
Fable.Compiler.Util.CliArgs→Fable.CompilerOptionsFable.Compiler.Util.CliArgs→Fable.VerbosityFable.Compiler.Util.PrecompiledInfoImpl→Fable.CompilerOptionsFable.Compiler.Util.PrecompiledInfoJson→Fable.CompilerOptions
- Direction
- Fable.Compiler.Util uses Fable, so a change to Fable can break Fable.Compiler.Util, while a change to Fable.Compiler.Util can't break Fable.
- Position
- Below the diagonal: Fable.Compiler.Util uses a module listed above it, which is the healthy direction.
39→38 Fable.Compiler.Util uses Fable.Transforms.State✕
- Connections
- 1 pair of types, where a type in Fable.Compiler.Util uses a type in Fable.Transforms.State.
- The types involved
Fable.Compiler.Util.PrecompiledInfoImpl→Fable.Transforms.State.PrecompiledInfo
- Direction
- Fable.Compiler.Util uses Fable.Transforms.State, so a change to Fable.Transforms.State can break Fable.Compiler.Util, while a change to Fable.Compiler.Util can't break Fable.Transforms.State.
- Position
- Below the diagonal: Fable.Compiler.Util uses a module listed above it, which is the healthy direction.
40→6 Fable.Standalone.Main uses System✕
- Connections
- 1 pair of types, where a type in Fable.Standalone.Main uses a type in System.
- The types involved
Fable.Standalone.Main.ParseAndCheckResults→System.Lazy`1
- Direction
- Fable.Standalone.Main uses System, so a change to System can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break System.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→7 Fable.Standalone.Main uses FSharp.Compiler.Text✕
- Connections
- 3 pairs of types, where a type in Fable.Standalone.Main uses a type in FSharp.Compiler.Text.
- The types involved
Fable.Standalone.Main.Main→FSharp.Compiler.Text.RangeFable.Standalone.Main.Main→FSharp.Compiler.Text.TaggedTextFable.Standalone.Main.Main→FSharp.Compiler.Text.TextTag
- Direction
- Fable.Standalone.Main uses FSharp.Compiler.Text, so a change to FSharp.Compiler.Text can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break FSharp.Compiler.Text.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→9 Fable.Standalone.Main uses Fable.Transforms.Rust.AST.Types✕
- Connections
- 1 pair of types, where a type in Fable.Standalone.Main uses a type in Fable.Transforms.Rust.AST.Types.
- The types involved
Fable.Standalone.Main.RustResult→Fable.Transforms.Rust.AST.Types.Crate
- Direction
- Fable.Standalone.Main uses Fable.Transforms.Rust.AST.Types, so a change to Fable.Transforms.Rust.AST.Types can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break Fable.Transforms.Rust.AST.Types.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→15 Fable.Standalone.Main uses Fable.AST.Fable✕
- Connections
- 1 pair of types, where a type in Fable.Standalone.Main uses a type in Fable.AST.Fable.
- The types involved
Fable.Standalone.Main.Main→Fable.AST.Fable.File
- Direction
- Fable.Standalone.Main uses Fable.AST.Fable, so a change to Fable.AST.Fable can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break Fable.AST.Fable.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→16 Fable.Standalone.Main uses Fable.Transforms.Python.AST✕
- Connections
- 1 pair of types, where a type in Fable.Standalone.Main uses a type in Fable.Transforms.Python.AST.
- The types involved
Fable.Standalone.Main.PythonResult→Fable.Transforms.Python.AST.Module
- Direction
- Fable.Standalone.Main uses Fable.Transforms.Python.AST, so a change to Fable.Transforms.Python.AST can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break Fable.Transforms.Python.AST.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→23 Fable.Standalone.Main uses FSharp.Compiler.Symbols✕
- Connections
- 2 pairs of types, where a type in Fable.Standalone.Main uses a type in FSharp.Compiler.Symbols.
- The types involved
Fable.Standalone.Main.Main→FSharp.Compiler.Symbols.FSharpXmlDocFable.Standalone.Main.SymbolImpl→FSharp.Compiler.Symbols.FSharpSymbol
- Direction
- Fable.Standalone.Main uses FSharp.Compiler.Symbols, so a change to FSharp.Compiler.Symbols can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break FSharp.Compiler.Symbols.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→24 Fable.Standalone.Main uses FSharp.Compiler.Diagnostics✕
- Connections
- 1 pair of types, where a type in Fable.Standalone.Main uses a type in FSharp.Compiler.Diagnostics.
- The types involved
Fable.Standalone.Main.Main→FSharp.Compiler.Diagnostics.FSharpDiagnostic
- Direction
- Fable.Standalone.Main uses FSharp.Compiler.Diagnostics, so a change to FSharp.Compiler.Diagnostics can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break FSharp.Compiler.Diagnostics.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→31 Fable.Standalone.Main uses FSharp.Compiler.EditorServices✕
- Connections
- 6 pairs of types, where a type in Fable.Standalone.Main uses a type in FSharp.Compiler.EditorServices.
- The types involved
Fable.Standalone.Main.Main→FSharp.Compiler.EditorServices.CompletionItemKindFable.Standalone.Main.Main→FSharp.Compiler.EditorServices.DeclarationListItemFable.Standalone.Main.Main→FSharp.Compiler.EditorServices.FSharpGlyphFable.Standalone.Main.Main→FSharp.Compiler.EditorServices.FindDeclFailureReasonFable.Standalone.Main.Main→FSharp.Compiler.EditorServices.SemanticClassificationTypeFable.Standalone.Main.Main→FSharp.Compiler.EditorServices.ToolTipElement
- Direction
- Fable.Standalone.Main uses FSharp.Compiler.EditorServices, so a change to FSharp.Compiler.EditorServices can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break FSharp.Compiler.EditorServices.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→33 Fable.Standalone.Main uses FSharp.Compiler.CodeAnalysis✕
- Connections
- 5 pairs of types, where a type in Fable.Standalone.Main uses a type in FSharp.Compiler.CodeAnalysis.
- The types involved
Fable.Standalone.Main.Main→FSharp.Compiler.CodeAnalysis.FSharpCheckProjectResultsFable.Standalone.Main.Main→FSharp.Compiler.CodeAnalysis.FSharpProjectOptionsFable.Standalone.Main.ParseAndCheckResults→FSharp.Compiler.CodeAnalysis.FSharpCheckFileResultsFable.Standalone.Main.ParseAndCheckResults→FSharp.Compiler.CodeAnalysis.FSharpCheckProjectResultsFable.Standalone.Main.ParseAndCheckResults→FSharp.Compiler.CodeAnalysis.FSharpParseFileResults
- Direction
- Fable.Standalone.Main uses FSharp.Compiler.CodeAnalysis, so a change to FSharp.Compiler.CodeAnalysis can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break FSharp.Compiler.CodeAnalysis.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→35 Fable.Standalone.Main uses Fable✕
- Connections
- 2 pairs of types, where a type in Fable.Standalone.Main uses a type in Fable.
- The types involved
Fable.Standalone.Main.Main→Fable.CompilerFable.Standalone.Main.Main→Fable.Language
- Direction
- Fable.Standalone.Main uses Fable, so a change to Fable can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break Fable.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→37 Fable.Standalone.Main uses Fable.Transforms.Printer✕
- Connections
- 1 pair of types, where a type in Fable.Standalone.Main uses a type in Fable.Transforms.Printer.
- The types involved
Fable.Standalone.Main.Main→Fable.Transforms.Printer.Writer
- Direction
- Fable.Standalone.Main uses Fable.Transforms.Printer, so a change to Fable.Transforms.Printer can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break Fable.Transforms.Printer.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
40→38 Fable.Standalone.Main uses Fable.Transforms.State✕
- Connections
- 6 pairs of types, where a type in Fable.Standalone.Main uses a type in Fable.Transforms.State.
- The types involved
Fable.Standalone.Main.Main→Fable.Transforms.State.CompilerImplFable.Standalone.Main.Main→Fable.Transforms.State.LogEntryFable.Standalone.Main.Main→Fable.Transforms.State.PrecompiledInfoFable.Standalone.Main.Main→Fable.Transforms.State.ProjectFable.Standalone.Main.ParseAndCheckResults→Fable.Transforms.State.LogEntryFable.Standalone.Main.ParseAndCheckResults→Fable.Transforms.State.Project
- Direction
- Fable.Standalone.Main uses Fable.Transforms.State, so a change to Fable.Transforms.State can break Fable.Standalone.Main, while a change to Fable.Standalone.Main can't break Fable.Transforms.State.
- Position
- Below the diagonal: Fable.Standalone.Main uses a module listed above it, which is the healthy direction.
At a glance — Code Health
At a glance — Architecture
At a glance — Maturity
At a glance — Readiness
At a glance — Security
At a glance — Event Sourcing
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A05:2025 — Injection | 92 | High / Critical |
| A02:2025 — Security Misconfiguration | 13 | Medium |
| A03:2025 — Software Supply Chain Failures | 8 | High / Critical |
Roadmap
Begin by cleaning up the package.json to address outdated dependencies and remove unused packages, while explicitly declaring unlisted imports. Next, fix the test configuration to ensure the test script correctly references existing files, and break down the largest source files to improve maintainability. Finally, implement a draft release or manual gate to prevent bad builds from being published to users.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Resolve the 1 Test suite declares a test script but contains no test files finding(s) in Test Reliability. | +3.1 pts | Low | Test Reliability |
| Resolve the 30 Outdated (npm) finding(s) in Dependency Hygiene — start with package.json. | +3.7 pts | Medium | Dependency Hygiene |
| Resolve the 1 No ADRs found finding(s) in ADR Quality. | +1.1 pts | Low | ADR Quality |
| Nothing pauses a release for a human: publish as a draft release (or gate the release job on a protected tag/manual dispatch) so a bad build can be stopped before users can download it. | +2.2 pts | Medium | Deployment & Rollback |
| Remove unused dependencies, declare unlisted imports explicitly, and demote type-/test-only packages to devDependencies. | +2.2 pts | Medium | Dependency Hygiene |
| Resolve the 50 TooManyFunctions finding(s) in God Classes — start with Set.fs (6), Map.fs (6), ilwrite.fs (2). | +1.1 pts | Medium | God Classes |
| Resolve the 150 FileTooLong finding(s) in God Classes — start with Replacements.fs (5), Seq.fs (5), Map.fs (4). | +1.7 pts | High | God Classes |
| Keep implementation types off the public surface (Dart: a `_` name, or keep it under `lib/src/` unexported; Rust: `pub(crate)`, or keep the module private) so internals can change without breaking consumers. | +1.5 pts | Medium | Library API & versioning |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 3.4 | Slop | Dependency Vulnerabilities: High CVE: REDACTED |
| REDACTED | 4.4 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 4.4 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 4.4 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 4.5 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 4.6 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 5.1 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 5.1 | Mixed | Static Analysis (SAST): High: REDACTED |
| src/Fable.Transforms/Rust/Replacements.fs | 5.5 | Mixed | Change Coupling: Boundary-crossing change coupling: Replacements.fs ↔ Mutable.rs |
| REDACTED | 5.7 | Mixed | Static Analysis (SAST): Medium: REDACTED |
| src/Fable.Transforms/Python/Replacements.fs | 6.5 | Mixed | Change Coupling: Boundary-crossing change coupling: Replacements.fs ↔ double.py |
| src/Fable.Transforms/Dart/DartPrinter.fs | 6.5 | Mixed | Change Coupling: Boundary-crossing change coupling: DartPrinter.fs ↔ Util.dart |
| src/fable-library-rust/src/Array.fs | 7.0 | Mixed | God Classes: FileTooLong: src/Array.fs |
| src/fable-library-ts/MutableMap.fs | 7.0 | Mixed | God Classes: TooManyMethods: Dictionary |
| src/fable-library-py/src/ints.rs | 7.0 | Mixed | God Classes: TooManyMethods: Int8 |
| src/Fable.Transforms/FSharp2Fable.Util.fs | 7.1 | Mixed | God Classes: FileTooLong: Fable.Transforms/FSharp2Fable.Util.fs |
| src/fable-library-py/src/array.rs | 7.2 | Mixed | God Classes: FileTooLong: src/array.rs |
| src/fable-library-py/fable_library/Set.fs | 7.2 | Mixed | God Classes: TooManyFunctions: SetTreeModule |
| src/fable-library-ts/Set.fs | 7.2 | Mixed | God Classes: TooManyFunctions: SetTreeModule |
| src/fable-library-py/fable_library/Map.fs | 7.2 | Mixed | God Classes: TooManyFunctions: MapTreeModule |
How the grades work
A definite problem that already costs you something and drags the score down: a missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here tends to cause failures elsewhere.
Likely wrong, but not failing yet. It degrades the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to carry for two years either.
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Something this survey could not settle from the outside, and which could be critical or serious. Either a control was required and no positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean result. These are excluded from the score rather than awarded a pass, so the number on the cover neither rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each one is named under Limitations.
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 56 of 60 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); 4 documentation/naming judgement(s) are LLM-assisted and labelled advisory. Overall confidence is 0.8 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
What we checked — 60 dimensions across the health lenses
- Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 568 of 798 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line.
- Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
- Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
Tools & methods
| Method | Backs | Version | Evaluator |
|---|---|---|---|
| Roslyn static analysis | Complexity, cohesion, coupling, dead code, API surface, layering | 5.3.0 | ✓ deterministic |
| Native secret scanner | Hardcoded secrets / credentials | 1.0.0 | ✓ deterministic |
| Watchdog duplication detector (in-process) | Code duplication | 1.0.0 | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.400 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.400 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy · checkov | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 · 3.2.533 | ✓ deterministic |
| LLM (sampled · advisory) | Documentation quality, ADR conformance, naming — sampled over a bounded sample; advisory, never a deterministic measurement | Local LLM | ◐ LLM · sampled · advisory |
Run transparency — what happened this run
- D1 Cyclomatic Complexity — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Cyclomatic Complexity couldn't be assessed within its 5-minute budget on a solution this large — not included in this run.
- D2 Cognitive Complexity — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Cognitive Complexity couldn't be assessed within its 5-minute budget on a solution this large — not included in this run.
- D4 Code Duplication — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Code Duplication couldn't be assessed within its 19-minute budget on a solution this large — not included in this run.
- D14 License Compliance — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. This repository declares a Python REDACTED/requirements.txt (pip/uv/Poetry), but the licence verdict published here was taken over its NuGet package dependencies. Nothing was read about its Python dependencies' licensing in either direction, and a clean score on this card must not be read as covering them.
- D14 License Compliance — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. This repository declares package.json, but the licence verdict published here was taken over its NuGet package dependencies. Nothing was read about its npm dependencies' licensing in either direction, and a clean score on this card must not be read as covering them.
- D15 Churn × Complexity Hotspots — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. A hotspot's complexity is meant to be the worst body its churn actually touched. For src/Fable.Transforms/Babel/Fable2Babel.fs, src/Fable.Transforms/FSharp2Fable.Util.fs, src/Fable.Transforms/Transforms.Util.fs, src/Fable.Cli/Main.fs, src/Fable.Transforms/Replacements.fs, … that could not be established — the complexity reader for the file reports no body extents, or the history carries no per-line attribution — so the row quotes the file's worst body, which the counted changes may never have touched. The churn count is unaffected.
- D32 Data Compliance (PII/GDPR) — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. `src/fable-library-py/fable_library/async_.py`, `src/fable-library-py/fable_library/async_builder.py`, `src/fable-library-py/fable_library/bases.py`, `src/fable-library-py/fable_library/choice.pyi`, `src/fable-library-py/fable_library/core/array.pyi`, … (+22 more) produced a parse error, so every rule in this engine's `gdpr.yml` was absent there. That absence is NOT a clean result: these rules detect personal data crossing a boundary into a log sink, a URL or browser storage, and a file that was never parsed cannot report any of the three. The rest of the tree analysed normally and its rows above stand; only these files are unaccounted for. You can widen what we reach: fix the syntax error (or exclude the file deliberately) and re-scan to cover it.
- D39 IL Efficiency — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. `dotnet build` exited 1 with a compiler/MSBuild diagnostic, so there were no assemblies to read IL from. The build itself is D18's row, with the ask; nothing further is charged here.
- AX1 Captive dependencies — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads Microsoft.Extensions.DependencyInjection registrations in C# and Spring beans in Java/Kotlin only, and this repository defines its own container in src/Fable.Transforms/Babel/Fable2Babel.fs, whose lifetimes are not modelled yet, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- AXR1 Runtime accessibility — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Render strategy: boot via REDACTED (REDACTED). docker build failed (exit 127) — DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with BuildKit: https://docs.docker.com/go/bui…; runtime evidence skipped.
- C1 Data Protection — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These personal data controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks personal data controls.
- C2 Access Controls — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These authorization controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks authorization controls.
- C3 Audit Trail — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These audit controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks audit controls.
- C4 Data Retention — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These retention controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks retention controls.
- C5 Data-Subject Rights — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These data-subject rights controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks data-subject rights controls.
- IC1 Incompleteness & stubs — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- P5 DR & Backup — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. No backup/snapshot/replication config, RTO/RPO or restore-procedure documentation was found — and no production persistence was detected either (no data-access packages, no data-store services, no database resources), so there is nothing in this repository whose loss a DR control would recover. If this system's data lives in a platform or ops repo we can't see, that's where the DR evidence belongs.
- R10 Code Duplication — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 2 further occurrence(s) are not listed individually; the score already reflects all 42.
- R7 Dead Code — measured, with a gap in what it reached — Watchdog measured this, but not all of it. What it did not reach is a gap on our side — a collector, parser or image we have not built yet — so the numbers on that dimension cover less than the repository, and the part left out is not evidence that it would have passed. 30 further occurrence(s) are not listed individually; the score already reflects all 70.
- S1 Web-Security Posture — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These web-security controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks web-security controls.
- X1 Async correctness — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X12 Unreachable branch — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X13 Undrained process stream — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X14 Bypassable address classification — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X15 Unvalidated length from an untrusted reader — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X16 Unfloored truncation loop — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X17 Uncapped recursion over a caller-supplied document — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X18 Disposal-pattern correctness — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X19 Unrestored process-global state — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X2 Cancellation propagation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X21 Side-effecting pattern guard — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X22 Contradicted release guard — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X24 Document value interpolated into markup unescaped — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X25 Inert configuration knob — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X26 Unsynchronised callback handoff — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X29 Per-element action decided by a fixed element — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X3 Exception handling — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X30 Support guard that admits what it rejects — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X32 Type resolved by simple name across every loaded assembly — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X4 Structured logging — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X5 Nullable reference types — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X7 Silent fallback defaults — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. X7 measured the part of this repository it reads (C#, Python, TypeScript/JavaScript, Rust, Go, Java, Kotlin, Scala, PHP, Ruby, Swift and Dart), and its Erlang source is outside the check's reach, so the card covers only part of the product. That is a gap in this analyzer's language reach — not a finding that the unread source is free of silent defaults.
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
- D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
- D5 Coupling: Coupling is measured between projects/assemblies — runtime coupling through DI, reflection, messaging or shared databases is invisible to a static reference graph.
- D6 Cohesion (LCOM4): LCOM4 cohesion is syntactic — it infers connectivity from which methods touch which fields/methods by name, not from real runtime behaviour or intent.
- D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
- D11 Test Reliability: Flakiness is inferred from history/markers — Watchdog runs the suite once (for coverage), not the repeated runs under varied conditions that reveal nondeterminism, so a flaky test never recorded as failing is invisible here.
- D12 Dependency Hygiene: Dependency health reads manifests and lockfiles — a vulnerability in a vendored/copied dependency, or risk from how a dependency is actually used, is outside this view.
- D13 Secret Scanning: Secret detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D16 Bus Factor: Bus-factor is a time-decayed model of commit attribution (who has recently, repeatedly worked a file), not comprehension — pairing, review and reading-without-committing spread knowledge it can't see; bot commits and shared accounts still distort it.
- D19 Documentation Quality: Documentation quality is judged by an LLM over a bounded sample of docs — it reads what is written, not whether the docs match the running system, and it is advisory, not a measurement. Its critique rows are drawn from a closed category vocabulary and each row means the same thing in every run, so two scans can be compared row by row; the SET that fires is still a sample, and does not repeat exactly. Measured on one frozen input, six scans at one engine SHA: 2-5 critique rows per scan, 8 distinct rows across the six, 3 of those 8 seen in only one scan. So a D19 row is evidence about the documentation, but a COUNT of D19 rows is not a quantity — never read a change in it as an improvement or a regression.
- D20 ADR Quality: ADR quality is an LLM read of the decision records present — it cannot know about decisions made and never recorded, and its verdict is sampled and advisory.
- D21 Naming Consistency: Naming quality is an LLM judgement over a bounded sample — it assesses clarity/consistency of the names it sees, not domain-correctness, and is advisory.
- D22 Internal API Consistency: API-surface coherence is an LLM judgement over a sample of the public surface — consistency of intent across the whole API is approximated, not exhaustively verified.
- D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
- D27 Navigability: Indirection/navigability is structural — it measures hops to follow a call, not whether that indirection buys real flexibility or just ceremony.
- D28 Secrets (history): Secret-history scanning sweeps the git log for known patterns — a secret that predates the available history, or never matched a signature, is not found (clean means "nothing matched in the history we can see").
- D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
- D30 Dependency Vulnerabilities: CVE matching depends on accurate package/version metadata and on the advisory databases — a vulnerability with no published advisory, or in code not declared as a dependency, is not seen. Coverage needs a RESOLVED graph: an unpinned requirements.txt, or a pom without a resolved build, yields partial coverage rather than a clean verdict. An ecosystem the analyzer cannot scan is reported as unmeasured, never as clean.
- D31 IaC & Container Security: IaC scanning checks Dockerfiles/Terraform/Kubernetes against best-practice rules — it cannot see the live cloud account, runtime configuration, or drift between the committed config and what is actually deployed.
- D34 Knowledge Freshness: Freshness is decayed commit RECENCY, not comprehension — code read often but rarely committed reads as orphaned, and stable code that genuinely needs no changes is penalised the same as forgotten code; bot/squash commits distort it like the bus factor.
- D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
- D43 Malicious Dependencies: Only packages some vulnerability database has already NAMED as malicious are seen — a compromise published in the last hours, or never reported at all, is invisible here, and this dimension reading 10 is not evidence that a dependency is trustworthy. There is no typosquat or dependency-confusion analysis: a package nobody has reported is simply absent from the feeds. Coverage is the dependency scan's: an ecosystem that could not be scanned is disclosed as unmeasured, never as clean.
- D44 Platform End-of-Life: The support table is FROZEN, so it goes out of date by losing RECALL: a release that ended support after the table was written is missed until the table is refreshed, and this dimension reading 10 is not evidence that a platform is current. Only platforms the repository DECLARES in a place this pass reads are seen — a runtime named only in a REDACTED (D31's subject), in a CI workflow (D29's), or in a file this pass does not parse (go.mod, a Gemfile ruby directive) is invisible here, which is why a repository declaring none of them abstains rather than scoring. Only frameworks with a PUBLISHED support policy are tracked: React, Flask and Express publish none, so their age cannot be judged and their absence from a report is not a statement that they are supported.
- AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
- AX9 CQS / query purity: Handlers are found by interface/name convention — a query handler using neither is not seen. Mutation is a resolved write/publish invocation (SaveChanges/repository/bus), so a write hidden behind a hand-rolled wrapper, reflection, or a string-keyed service locator resolves to a non-persistence type and isn't flagged; it detects that a query writes state, not whether the write is a legitimate read-side cache update. Clean means "no resolved write/publish in a query body", not a proof of CQS purity.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
- P4 Deployment & Rollback: Approval/branch-protection rules live in repository settings the scan cannot see — only their in-repo evidence (config files, workflows) is checked, so a control enforced purely in the host's settings reads as "not evidenced".
- P6 Release Hygiene: Rollback/observability controls are inferred from repo artefacts (pipelines, dashboards-as-code) — controls configured in external tooling, with no in-repo trace, cannot be credited.
The LLM boundary
Dimensions
D3 · God Classes
239 god class(es) detected.
What to do
- Resolve the 150 FileTooLong finding(s) in God Classes — start with Replacements.fs (5), Seq.fs (5), Map.fs (4). — One of this dimension's main actionable groups (150 warning-level).
- Resolve the 50 TooManyFunctions finding(s) in God Classes — start with Set.fs (6), Map.fs (6), ilwrite.fs (2). — One of this dimension's main actionable groups (50 warning-level).
- Resolve the 33 TooManyMethods finding(s) in God Classes — start with ints.rs (8), floats.rs (2), Set.fs (2). — One of this dimension's main actionable groups (33 warning-level).
- Enforce God Classes in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D5 · Coupling
80 projects, 0 dependency cycle(s), 0 unstable depended-on project(s).
D6 · Cohesion (LCOM4)
0 of 94 classes have LCOM4 above 3.
D9 · Test Distribution
322 test methods: 312 unit, 10 integration, 0 BDD, 0 e2e. The Rust suite contributes 11 `#[test]` function(s) across 2 file(s) declaring at least one; its unit/integration split is Cargo's own — 1 of those file(s) are integration-test targets under a crate's tests/ directory, and the rest are #[test] functions compiled into the crate they test. The Python suite contributes 311 test function(s) across 14 file(s) declaring at least one — every `def test…` in a file pytest or unittest would collect, which is those frameworks' own definition of a case; a parametrize table counts once, so this is a floor. Its tier split is read from file names and paths only.
D11 · Test Reliability
0 flaky across 4 measured tier(s). unit: measured (0 flaky); integration: measured (0 flaky); other: measured (0 flaky); JavaScript/TypeScript (jest via `npm ci --ignore-scripts` in tests/React/ (0 tests)): measured (0 flaky).
What to do
- Resolve the 1 Test suite declares a test script but contains no test files finding(s) in Test Reliability. — One of this dimension's main actionable groups (1 issue-level).
D12 · Dependency Hygiene
2 outdated, 0 vulnerable, 0 deprecated packages. Those are the NuGet packages; this repository's npm dependencies were read too — 203 outdated of 478 package(s) across 6 lockfile(s).
What to do
- Resolve the 30 Outdated (npm) finding(s) in Dependency Hygiene — start with package.json. — One of this dimension's main actionable groups (30 recommendation-level).
- Resolve the 1 Outdated finding(s) in Dependency Hygiene — start with Fable.Core.fsproj. — One of this dimension's main actionable groups (1 recommendation-level).
- Enforce Dependency Hygiene in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D13 · Secret Scanning
Secret scan ran and found no leaked secrets.
D14 · License Compliance
0 of 240 packages use a banned license. ★ DEPTH: this repository's MSBuild projects declare 44 direct `PackageReference`(s), and 155 further package(s) were reached beyond them by closing the graph over nuget.org's own nuspec dependency graph — so a banned licence pulled in only by a dependency's OWN dependencies is inside this verdict. A package whose licence nuget.org could not be asked for is not graded, and version ranges are taken at their lower bound, so this is the closure as that graph states it rather than a restored consumer's exact resolution. ★ COVERAGE OF THIS VERDICT: it grades this repository's NuGet package dependencies and nothing else. The repository also declares a Python REDACTED/requirements.txt (pip/uv/Poetry) and package.json, and the licences of those dependency graphs were NOT read by this pass — a gap in this engine's coverage, not a statement about them. So this result says the graded closure carries no banned licence; it does NOT say this repository's licensing is clear.
D15 · Churn × Complexity Hotspots
Top hotspots: src/Fable.Transforms/Beam/Replacements.fs (21×264=5544); src/Fable.Transforms/Rust/Replacements.fs (16×103=1648); src/Fable.Transforms/Rust/Fable2Rust.fs (21×57=1197) Repeated repair below the complexity floor: src/fable-library-rust/src/Native.rs (7 of 9 changes were fixes); src/fable-library-py/fable_library/async_.py (7 of 8 changes were fixes); src/fable-library-rust/src/Reflection.rs (5 of 7 changes were fixes)
What to do
- Resolve the 30 Hotspot finding(s) in Churn × Complexity Hotspots — start with Replacements.fs (5), Main.fs (3), Fable2Rust.fs. — One of this dimension's main actionable groups (30 warning-level).
- Resolve the 14 Repeated repair finding(s) in Churn × Complexity Hotspots — start with Native.rs, async_.py, Reflection.rs. — One of this dimension's main actionable groups (14 warning-level).
D16 · Bus Factor
67 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is src/Fable.Transforms/Beam/Fable2Beam.fs. Counted over 492 of the 625 production source files in this repository: 130 are under the ~2,400-byte size floor this dimension measures over, and the remaining 3 have no attributable history left to measure.
What to do
- Resolve the 5 Off-boarding risk finding(s) in Bus Factor. — One of this dimension's main actionable groups (5 recommendation-level).
- Resolve the 1 Further sole-owners (lower concentration) finding(s) in Bus Factor. — One of this dimension's main actionable groups (1 recommendation-level).
D19 · Documentation Quality
The repository's root README gives a strong overview (Fable is an F# to JS compiler powered by forked FCS) and links to the Nuget, GitHub workflow, Twitter, and a PR note. It also describes getting started at fable.io/docs/2-steps/setup.html and building with VSCode Dev Container plus system requirements, then dives into Requirements (docker, Dev Containers extension), Use VSCode Dev Container, and Use your machine steps. The README is well-structured and clearly documents the repository's purpose.
What to do
- Improve Documentation Quality — currently 8.0/10. — The repository's root README gives a strong overview (Fable is an F# to JS compiler powered by forked FCS) and links to the Nuget, GitHub workflow, Twitter, and a PR note. It also describes getting started at fable.io/docs/2-steps/setup.html and building with VSCode Dev Container plus system requirements, then dives into Requirements (docker, Dev Containers extension), Use VSCode Dev Container, and Use your machine steps. The README is well-structured and clearly documents the repository's purpose.
D20 · ADR Quality
No architecture decision records were found.
What to do
- Resolve the 1 No ADRs found finding(s) in ADR Quality. — One of this dimension's main actionable groups (1 recommendation-level).
D21 · Naming Consistency
0 naming inconsistencies across 0 sampled symbols.
D22 · Internal API Consistency
3 API inconsistencies across a 400-member sample of 302 exposed types.
What to do
- Resolve the 1 Redundant and confusing null-handling factory methods. 'Create' returns… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Inconsistent naming for untainting operations. 'PUntaint' is a method on… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Inconsistent use of 'Try' prefix and return types. Some methods return… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
D26 · Project Cohesion
7 of 35 build units (Cargo, MSBuild, npm, pub) flagged as possibly oversized/incoherent.
What to do
- Resolve the 1 Projects may be oversized for their cohesion finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).
D27 · Navigability
100 % of calls cross a namespace and 0 % go through an interface, but 0 % of collaborators are co-located — so following a call takes several hops. Baseline: small — navigation cost is tolerated.
What to do
- Resolve the 1 Scattered collaborators finding(s) in Navigability. — One of this dimension's main actionable groups (1 recommendation-level).
D28 · Secrets (history)
gitleaks scanned the full history AND the current working tree and found no secrets.
D29 · Static Analysis (SAST)
92 finding(s): 0 critical, 90 high, 2 medium, 0 low. 79 unpinned-GitHub-Actions row(s) are reported here but scored by D36 (supply-chain provenance), which measures that posture as `pinned_actions` — one pinning decision is charged once, not once per lens. semgrep hit a parse error in 29 file(s) — `.devcontainer/scripts/zsh_dotnet_completion.sh` (line 15), `src/fable-library-py/fable_library/async_.py` (line 54, lines 58–62, lines 68–71, …), `src/fable-library-py/fable_library/async_builder.py` (line 29, line 117, line 137, …), `src/fable-library-py/fable_library/bases.py` (line 164, lines 201–204, lines 222–225), `src/fable-library-py/fable_library/choice.pyi` (line 9, lines 11–13, lines 15–17, …), … (+24 more) — so no absence of findings in the named regions is evidence of anything; rows reported elsewhere in those files are real. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them. Separately, one or more rules could not re-parse an embedded snippet in 1 file(s) (e.g. a workflow `run:` block read as shell). Those files WERE scanned and their other rows are unaffected; only those rules' view of those snippets is missing.
What to do
- Resolve the 2 REDACTED finding(s) charged to Static Analysis (SAST) — the other 79 are reported here at file:line but scored by D36 (supply-chain provenance), which charges them once. — One of this dimension's main actionable groups (81 issue-level, 2 of them charged here).
- Resolve the 3 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED, REDACTED, REDACTED. — One of this dimension's main actionable groups (3 issue-level).
- Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED, REDACTED. — One of this dimension's main actionable groups (2 issue-level).
D30 · Dependency Vulnerabilities
4 finding(s): 0 critical, 1 high, 2 medium, 1 low.
What to do
- Resolve the 1 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED. — One of this dimension's main actionable groups (1 issue-level).
- Resolve the 2 Medium vulnerability finding(s) in Dependency Vulnerabilities — start with REDACTED (2). — One of this dimension's main actionable groups (2 warning-level).
- Resolve the 1 Low CVE finding(s) in Dependency Vulnerabilities — start with REDACTED. — One of this dimension's main actionable groups (1 recommendation-level).
D31 · IaC & Container Security
13 finding(s): 0 critical, 0 high, 0 medium, 13 low.
D34 · Knowledge Freshness
33 of 495 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is src/fcs-fable/src/Compiler/AbstractIL/ilwrite.fs. Counted over 495 of the 625 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
What to do
- Resolve the 8 Orphaned knowledge finding(s) in Knowledge Freshness — start with ilwrite.fs, infos.fs, Exprs.fs. — One of this dimension's main actionable groups (8 issue-level).
- Resolve the 25 Orphaned file finding(s) in Knowledge Freshness — start with service_slim.fs, PhpPrinter.fs, AccessibilityLogic.fs. — One of this dimension's main actionable groups (25 recommendation-level).
- Resolve the 1 Further orphaned files (smaller) finding(s) in Knowledge Freshness. — One of this dimension's main actionable groups (1 recommendation-level).
D35 · Change Coupling
Strongest change-coupling: HashMap.rs↔HashSet.rs 100%; MutableMap.fs↔MutableSet.fs 91%; Replacements.fs↔Mutable.rs 82%
What to do
- Resolve the 4 Boundary-crossing change coupling finding(s) in Change Coupling — start with Replacements.fs (3), DartPrinter.fs. — One of this dimension's main actionable groups (4 issue-level).
- Resolve the 6 Change coupling finding(s) in Change Coupling — start with HashMap.rs, MutableMap.fs, Array.fs. — One of this dimension's main actionable groups (6 warning-level).
- Resolve the 1 Change-coupling hub finding(s) in Change Coupling — start with Option.fs. — One of this dimension's main actionable groups (1 warning-level).
D36 · Supply-chain Provenance & Signing
2/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).
What to do
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
D43 · Malicious Dependencies
No dependency in any ecosystem this repository declares is published as malicious.
D44 · Platform End-of-Life
1 end-of-life runtime(s) and 0 end-of-life framework(s), read from 74 platform declaration(s) and 7 dependency declaration(s). This dimension reads what the repository says about ITSELF — a pinned target framework, a version file, a capped requires-python, a Rust toolchain pin, a framework major a constraint cannot move off. A FLOOR is deliberately never charged: `requires-python = ">=3.8"` states what the package SUPPORTS, not what it runs on, and a well-maintained library declares exactly that while running its own CI on a current release. The end-of-life facts are FROZEN and dated, so this dimension needs no network and answers identically inside a closed scan fence; as the table ages it loses recall and never precision, because a statement about support that ended in the past cannot become false. The OS layer of a container image is D31's question and the toolchain a CI workflow installs is D29's; this row is neither.
What to do
- Resolve the 1 End-of-life runtime finding(s) in Platform End-of-Life — start with quicktest.fsproj. — One of this dimension's main actionable groups (1 warning-level).
Frontend & cross-cutting dimensions
AX10 · Code composition
What to do
- The domain core is a small share of production code, but most of the rest matched no layer vocabulary at all — so this is not yet an anemic-domain finding. The namespace/path convention could not place that code, which makes the composition above a statement about the naming, not about the design. Name the layers (or check that the repository's conventions differ from the ones this check knows) before reading a thin domain into it.
AX3 · Project dependency cycles
AX4 · Dependency direction
AX6 · Interface segregation
- `MutableArray` declares 19 required operations under just 15 distinct name(s): `every`, `fill`, `filter`, `find`, `findIndex`, `forEach`, `indexOf`, `join`, `lastIndexOf`, `reduce`, `reduce`, `reduce`, `reduceRight`, `reduceRight`, `reduceRight`, `reverse`, `slice`, `some`, `sort`. Counted over its REQUIRED operations — a method signature or a function-typed property with no `?`, once per signature; optional members and data properties are not counted, because no implementer is forced to write them. That is an OVERLOAD SET, not 19 separate responsibilities: a caller binds to 15 operation(s) and uses the overload it selected, so the Interface-Segregation harm does NOT apply on the caller's side and splitting this into role-interfaces would scatter one operation without relieving anything. The burden that does remain is the IMPLEMENTER's — all 19 signatures must be written and kept in step. Reduce it by collapsing overloads (optional or default parameters, or an options object) rather than by segregating the interface. — src/fable-library-ts/Util.ts:3
What to do
- Collapse overload sets (optional/default parameters, or an options object) — these interfaces are wide in SIGNATURES, not in responsibilities, so segregating them would relieve no caller.
AX8 · Test isolation
AX9 · CQS / query purity
ES1 · Fold determinism
ES2 · Immutable events
GD1 · Unfinished & placeholder code
M1 · Documentation (README)
- 261 code files changed in the last 6 months but the README was not touched — it may no longer reflect the system.
What to do
- Explain in the README how to run the tests. Add a section called Testing to the README in the repository's top folder, saying how to run the test suite.
- Add an 'Architecture' / 'How it works' section to the root README — the high-level shape.
- Add a README to the 2 of 8 project(s) that lack one — worth up to 0.5 pts.
- Review the README against recent changes; refresh the parts that drifted.
M2 · Architecture documentation
- No Architecture Decision Records found — no conventional ADR directory, no numbered `NNNN-title` documents in any markup this check reads, and nothing ADR-shaped by content. Design rationale recorded elsewhere (a design-notes tree, a mailing list, pull-request discussion) is not visible to this check and is not re-findable per decision, so a future maintainer cannot ask why one choice was made and get an answer.
What to do
- Record your significant design decisions. Write one short document per decision, giving its date, the situation, the decision and its consequences, and keep them together with your other design documents. A docs/adr folder with each file named by number and title is the easiest place to find them.
M3 · Folder & project structure
M4 · Documentation accuracy
- README.md runs `./build.cmd`, but `build.cmd` does not exist. Checked without a model against the repository: its files and folders, the scripts and dependencies of every package.json, the projects, namespaces, package references and target frameworks of the .NET build, the SDK and Node pins, and the identifiers of every file that is not a document; the documents' own text never counts. A footprint generated at build time, read only by a platform, or living outside this repository is not seen, and this row is then wrong. — README.md:41
What to do
- Reconcile the README with reality: README.md runs `./build.cmd`, but `build.cmd` does not exist.
P1 · CI/CD gates
P10 · Library API & versioning
- 145/169 types (86%) declared in the published library are public. For a library, every public type is a stability contract — keep implementation types off the surface and expose only the intended API.
What to do
- Keep implementation types off the public surface (Dart: a `_` name, or keep it under `lib/src/` unexported; Rust: `pub(crate)`, or keep the module private) so internals can change without breaking consumers.
P2 · Observability
- Only 4/12 runnable modules use logging (modules with no entry point or server are excluded — they are libraries a runnable module hosts). Silent: `src/Fable.Build`, `src/fable-compiler-js`, `src/fable-compiler-js/src`, `src/fcs-fable/codegen`, `src/fcs-fable/src/Compiler` and 3 more.
What to do
- Extend structured logging to the remaining runnable modules so everything you run is diagnosable in production.
P3 · Security & performance tooling
What to do
- Dependabot is configured but does not watch `pip` — add that `package-ecosystem` entry to REDACTED so those dependencies get the same automatic update and advisory pressure as the ones it already covers.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
P4 · Deployment & Rollback
What to do
- Nothing pauses a release for a human: publish as a draft release (or gate the release job on a protected tag/manual dispatch) so a bad build can be stopped before users can download it.
P6 · Release Hygiene
PF1 · Benchmark discipline
PF2 · Allocation hygiene
What to do
- Raise allocation-aware density on the hot paths — currently 1759 use(s) across 399,142 production line(s) (~4.4/1k). More of the idioms below on the allocation-heavy paths climbs this toward 10.
- Dart: on hot paths, hold numbers in dart:typed_data lists (Int32List, Float64List …) instead of boxed List<int>/List<double>, read through views (sublistView, buffer.asInt32List, asByteData) instead of copying, make lists that never grow growable: false, compute in the SIMD types (Float32x4List …), and build bytes with BytesBuilder(copy: false).
- F#: on hot paths, work through Span/Memory (AsSpan/AsMemory) instead of copies, rent buffers from ArrayPool, make small records, unions and tuples [<Struct>]/struct (…) and options voption, mark lambda parameters of inline functions [<InlineIfLambda>], use valueTask for completions that are usually synchronous, and presize ResizeArray/StringBuilder.
PF3 · Async & latency hygiene
- `Parallel` holds an async function that calls .Wait() — a blocking call inside async code stalls the thread-pool thread the workflow runs on, and every continuation queued behind it for as long as it runs. — src/fcs-fable/src/Compiler/Facilities/DiagnosticsLogger.fs:1069
- `GetOrComputeValue` holds an async function that calls .Wait() — a blocking call inside async code stalls the thread-pool thread the workflow runs on, and every continuation queued behind it for as long as it runs. — src/fcs-fable/src/Compiler/Facilities/BuildGraph.fs:64
What to do
- F#: inside async { } or task { }, bind with let! / do! (Async.AwaitTask for a Task) instead of Async.RunSynchronously, .Wait() or .GetAwaiter().GetResult(), and use do! Async.Sleep or Task.Delay instead of Thread.Sleep; Async.RunSynchronously belongs at the program's entry point, outside every workflow.
R1 · Type Safety
What to do
- Migrate the remaining .js/.jsx files to TypeScript.
R10 · Code Duplication
- src/fable-library-ts/Date.ts:691 · src/fable-library-ts/DateOffset.ts:110 — the two spans are one implementation copied and then locally edited — 972 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — src/fable-library-ts/Date.ts:691
- src/fable-library-ts/Date.ts:605 · src/fable-library-ts/DateTimeFormat.ts:513 — the 2 copies sit in sibling files in one directory, so check first whether one of them (or an existing module there) already owns this behaviour and the others should call it; otherwise extract it into one module in that directory and have each site call it. — src/fable-library-ts/Date.ts:605
- src/fable-library-ts/Date.ts:303 · src/fable-library-ts/DateTimeFormat.ts:292 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Date.ts:303
- src/fable-library-ts/TimeSpan.ts:143 · src/fable-library-ts/TimeSpanTemporal.ts:225 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/TimeSpan.ts:143
- src/fable-library-ts/DateOnly.ts:76 · src/fable-library-ts/DateOnlyTemporal.ts:99 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/DateOnly.ts:76
- src/fable-library-ts/Date.ts:58 · src/fable-library-ts/DateTimeFormat.ts:73 — the 2 copies sit in sibling files in one directory, so check first whether one of them (or an existing module there) already owns this behaviour and the others should call it; otherwise extract it into one module in that directory and have each site call it. — src/fable-library-ts/Date.ts:58
- src/fable-library-ts/Date.ts:177 · src/fable-library-ts/Date.ts:210 · src/fable-library-ts/Date.ts:242 — all 3 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Date.ts:177
- src/fable-library-ts/DateTimeFormat.ts:178 · src/fable-library-ts/DateTimeFormat.ts:211 · src/fable-library-ts/DateTimeFormat.ts:243 — all 3 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/DateTimeFormat.ts:178
- src/fable-library-ts/Util.ts:410 · src/fable-library-ts/Util.ts:449 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Util.ts:410
- src/fable-library-ts/Date.ts:156 · src/fable-library-ts/DateTimeFormat.ts:157 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Date.ts:156
- src/fable-library-ts/Observable.ts:76 · src/fable-library-ts/Observable.ts:93 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Observable.ts:76
- src/fable-library-ts/Uri.ts:101 · src/fable-library-ts/Uri.ts:127 — the two spans are one implementation copied and then locally edited — 57 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — src/fable-library-ts/Uri.ts:101
- src/fable-library-ts/TimeSpan.ts:184 · src/fable-library-ts/TimeSpanTemporal.ts:267 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/TimeSpan.ts:184
- src/fable-library-ts/BitConverter.ts:21 · src/fable-library-ts/BitConverter.ts:35 · src/fable-library-ts/BitConverter.ts:49 · src/fable-library-ts/BitConverter.ts:63 — all 4 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/BitConverter.ts:21
- src/fable-library-ts/Date.ts:103 · src/fable-library-ts/Date.ts:226 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Date.ts:103
- src/fable-library-ts/DateTimeFormat.ts:121 · src/fable-library-ts/DateTimeFormat.ts:227 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/DateTimeFormat.ts:121
- src/fable-library-ts/Encoding.ts:108 · src/fable-library-ts/Encoding.ts:143 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Encoding.ts:108
- src/fable-library-ts/TimeOnly.ts:99 · src/fable-library-ts/TimeSpan.ts:167 · src/fable-library-ts/TimeSpanTemporal.ts:249 — the 3 copies are spread across 3 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/TimeOnly.ts:99
- src/fable-library-ts/TimeOnly.ts:7 · src/fable-library-ts/TimeOnlyTemporal.ts:38 — the two spans are one implementation copied and then locally edited — 65 tokens are still identical, in the same order in both files, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — src/fable-library-ts/TimeOnly.ts:7
- src/fable-library-ts/TimeSpan.ts:18 · src/fable-library-ts/TimeSpanTemporal.ts:60 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/TimeSpan.ts:18
- src/fable-library-ts/Char.ts:81 · src/fable-library-ts/Char.ts:93 — all 2 copies are in the same file, and the CITED SPAN is a run of MODULE-LEVEL DECLARATIONS — bindings the module declares and exports — rather than statements with a call site. Do not read this as an extract-a-helper row: a call expression cannot stand where a declaration was, and putting one there would delete the names themselves, which are what the rest of the codebase imports. What actually repeats here is the INITIALISER — the same expression shape written once per binding. So give that expression one name (a small helper the initialisers call, or a shared base value they are each derived from) and keep every binding under the name it already has. Where the run is an enumeration — one binding per distinct thing, differing precisely in the thing each one names — the repetition IS the enumeration and collapsing it would delete entries; consider instead whether the set belongs in one exported table the individual names are read out of. Reported because the copies drift apart the first time only one of them is edited. — src/fable-library-ts/Char.ts:81
- src/fable-library-ts/Date.ts:409 · src/fable-library-ts/Date.ts:513 · src/fable-library-ts/DateTimeFormat.ts:436 — the 3 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Date.ts:409
- src/fable-library-ts/DateTimeOffsetTemporal.ts:302 · src/fable-library-ts/DateTimeTemporal.ts:76 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/DateTimeOffsetTemporal.ts:302
- src/fable-library-ts/AsyncBuilder.ts:209 · src/fable-library-ts/AsyncBuilder.ts:218 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited. — src/fable-library-ts/AsyncBuilder.ts:209
- src/fable-library-ts/Date.ts:472 · src/fable-library-ts/Date.ts:491 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Date.ts:472
- src/fable-library-ts/Numeric.ts:57 · src/fable-library-ts/Numeric.ts:67 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited. — src/fable-library-ts/Numeric.ts:57
- REDACTED:83 · REDACTED:93 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited. — REDACTED:83
- src/fable-library-ts/Types.ts:130 · src/fable-library-ts/Types.ts:146 — the two spans are one implementation copied and then locally edited — 94 tokens are still identical, in the same order in both spans, with only local edits between them. The copies have already begun to drift, which is this row's finding: an edit made to one and not the other changes behaviour silently. Diff the two spans first to learn what genuinely differs, then extract the shared core into one module both sites use, passing the differences in as parameters — or, if one copy exists only because the other could not be imported from its context, make one of them the single source the other is generated or re-exported from. If one copy is no longer reachable, delete it rather than letting it shadow the live one. — src/fable-library-ts/Types.ts:130
- src/fable-library-ts/Char.ts:136 · src/fable-library-ts/Char.ts:146 · src/fable-library-ts/Char.ts:156 · src/fable-library-ts/Char.ts:166 · +1 more site(s) not listed — all 5 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/Char.ts:136
- src/fable-library-ts/CollectionUtil.ts:52 · src/fable-library-ts/CollectionUtil.ts:103 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/CollectionUtil.ts:52
- src/fable-library-ts/DateTimeFormat.ts:381 · src/fable-library-ts/DateTimeFormat.ts:391 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/DateTimeFormat.ts:381
- src/fable-library-ts/Reflection.ts:345 · src/fable-library-ts/Reflection.ts:353 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited. — src/fable-library-ts/Reflection.ts:345
- src/fable-library-ts/lib/big.js:593 · src/fable-library-ts/lib/big.js:732 — both copies are in the same file, so extract the block into one function there and call it from each site — the copies drift apart the first time only one of them is edited. — src/fable-library-ts/lib/big.js:593
- src/fable-library-ts/CollectionUtil.ts:77 · src/fable-library-ts/CollectionUtil.ts:107 — all 2 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/CollectionUtil.ts:77
- src/fable-library-ts/CollectionUtil.ts:146 · src/fable-library-ts/Util.ts:713 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/CollectionUtil.ts:146
- src/fable-library-ts/AsyncBuilder.ts:184 · src/fable-library-ts/TaskBuilder.ts:17 — the 2 copies are spread across 2 files, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/AsyncBuilder.ts:184
- src/fable-library-ts/BitConverter.ts:92 · src/fable-library-ts/BitConverter.ts:98 · src/fable-library-ts/BitConverter.ts:105 · src/fable-library-ts/BitConverter.ts:111 · +6 more site(s) not listed — all 10 copies are in the same file, and the CITED SPAN is not a self-contained block — it runs from inside one construct into the next (the tail of a branch plus the head of the following one, a run of switch arms, the end of a declaration plus the list that follows it) rather than covering a whole unit. So do not lift these lines literally: no call can be substituted for a half-open construct. Extract the enclosing repeated UNIT instead — the whole function, component or branch these lines sit in — and where the repetition IS the construct (a run of switch arms, a stack of near-identical declarations) replace it with one table or registry looked up by key rather than a helper each arm calls. The copies still drift apart the first time only one of them is edited, which is why this is reported. — src/fable-library-ts/BitConverter.ts:92
- src/fable-library-ts/BitConverter.ts:108 · src/fable-library-ts/BitConverter.ts:114 · src/fable-library-ts/BitConverter.ts:120 · src/fable-library-ts/BitConverter.ts:126 · +4 more site(s) not listed — all 8 copies are in the same file, so extract the block into one function there and call it from every one of those sites — resolving only two of them leaves the rest to drift apart the first time one is edited. — src/fable-library-ts/BitConverter.ts:108
- src/fable-library-ts/Date.ts:741 · src/fable-library-ts/DateTimeTemporal.ts:222 — the 2 copies sit in sibling files in one directory, so check first whether one of them (or an existing module there) already owns this behaviour and the others should call it; otherwise extract it into one module in that directory and have each site call it. — src/fable-library-ts/Date.ts:741
- src/fable-library-ts/DateTimeTemporal.ts:31 · src/fable-library-ts/TimeSpanTemporal.ts:5 — the 2 copies are spread across 2 files, and the SHAPE of this repetition could not be determined. It is not a run of declarations, a listing, a declaration header, a type body or a slice through a construct — and it was not measured as a run of executable statements either, so this row cannot tell you whether a function can stand where these lines are. Read the two spans before acting, because the move is opposite in the two cases. Where they are statements, the ordinary answer holds: give the shared part one home and call it from each site. Where they turn out to be declarations, a literal's entries, or the cases of an enumeration, there is no call site to call anything from, and collapsing them would delete what each copy pins — a shared base type, a generated set, or one exported constant each site refers to is the move instead, and sometimes the honest answer is that there is nothing to extract at all. Reported because the copies drift apart the first time only one of them is edited, which is true whichever of those they are. — src/fable-library-ts/DateTimeTemporal.ts:31
What to do
- Act on each finding's own remediation rather than one rule: the move depends on what recurs. Where the copies are executable blocks, give the shared part one home and call it from each site; where they are declarations, a listing, a specialisation already delegating to its base, or one shape repeated per entity, there is no call site and the move is a shared type, a generated set or a factory — sometimes there is nothing to extract.
R2 · Cyclomatic Complexity
- dateToStringWithCustomFormat has cyclomatic complexity 65 and cognitive complexity 87; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/Date.ts:93
- (anonymous) has cyclomatic complexity 61 and cognitive complexity 104; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — REDACTED:379
- dateToStringWithCustomFormat has cyclomatic complexity 58 and cognitive complexity 76; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/DateTimeFormat.ts:111
- divide has cyclomatic complexity 34 and cognitive complexity 78; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/lib/big.js:419
- round has cyclomatic complexity 32 and cognitive complexity 33; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/lib/big.js:195
- formatReplacement has cyclomatic complexity 29 and cognitive complexity 41; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — REDACTED:229
- parseRaw has cyclomatic complexity 26 and cognitive complexity 49; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. (×2) — src/fable-library-ts/Date.ts:605, src/fable-library-ts/DateTimeFormat.ts:513
- walk has cyclomatic complexity 24 and cognitive complexity 28; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/quotation.ts:550
- evaluate has cyclomatic complexity 22 and cognitive complexity 26; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/quotation.ts:411
- sub has cyclomatic complexity 21 and cognitive complexity 34; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/lib/big.js:579
- parse has cyclomatic complexity 21 and cognitive complexity 30; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/TimeSpanTemporal.ts:225
- split has cyclomatic complexity 20 and cognitive complexity 37; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — REDACTED:678
- parse has cyclomatic complexity 20 and cognitive complexity 27; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/TimeSpan.ts:143
- exprToString has cyclomatic complexity 20 and cognitive complexity 26; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/quotation.ts:518
- sub has cyclomatic complexity 20 and cognitive complexity 21; this row is raised above a cyclomatic bar of 10. The two numbers answer different questions and the gap between them is what decides whether to act: cyclomatic counts the independent arms through the body, cognitive counts what it costs to hold them in your head, so nesting and mixed boolean chains raise it while a flat run of independent arms does not. Cognitive is at or above cyclomatic here, so the branching is nested or entangled rather than laid out side by side — extracting each decision into its own named function is the change that pays. Measured by this repository's own parse of the file, so a body assembled at runtime, or generated, is counted as written rather than as it executes. — src/fable-library-ts/quotation.ts:604
What to do
- Break down the listed branch-heavy functions; aim P95 cyclomatic ≤ 5.
R3 · Large Files
- src/fable-library-ts/lib/big.js has 879 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — src/fable-library-ts/lib/big.js:1
- src/fable-library-ts/Util.ts has 863 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — src/fable-library-ts/Util.ts:1
- src/fable-library-ts/Date.ts has 815 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — src/fable-library-ts/Date.ts:1
- REDACTED has 702 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — REDACTED:1
- src/fable-library-ts/quotation.ts has 617 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — src/fable-library-ts/quotation.ts:1
- src/fable-library-ts/DateTimeFormat.ts has 545 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — src/fable-library-ts/DateTimeFormat.ts:1
- src/fable-library-ts/Reflection.ts has 538 significant lines (blank lines excluded), over the 400-line bar, and contains logic — a file this long is usually several responsibilities in one module. — src/fable-library-ts/Reflection.ts:1
What to do
- Split each oversized file along the responsibilities already in it, into smaller focused modules in the same package.
R5 · Dependency Freshness
What to do
- Bump outdated dependencies to current versions to limit upgrade debt.
R6 · Tooling
R7 · Dead Code
- 9 file(s) (~233 LoC) were excluded from dead-code analysis — declare main/module/exports or a conventional entry (src/index.*, an index.html script) so reachability can see this package.
- 49 file(s) (~12565 LoC) were excluded from dead-code analysis — declare main/module/exports or a conventional entry (src/index.*, an index.html script) so reachability can see this package. — src/fable-library-ts
- 1 file(s) (~6 LoC) were excluded from dead-code analysis — declare main/module/exports or a conventional entry (src/index.*, an index.html script) so reachability can see this package. — tests/React
- Unreachable from the 3 application, 4 tooling and 14 test entry point(s) detected in this repo. Gate removals on `npm run tsc` — an undetected custom entry would make these reachable.
- no import path from any entry point (3 application, 4 tooling, 14 test roots considered), and no other file in the scanned tree imports it — nothing in-repo names this module at all, which is the strongest form of this claim the import graph can make (×2) — REDACTED, src/fable-standalone/src/Worker/util.js
- Nothing imports this binding — it is safe to review for removal. (×34) — src/fable-library-ts/Util.ts:69, src/fable-library-ts/Util.ts:116, src/fable-library-ts/Util.ts:120, …
What to do
- Delete the dead files and unused exports — every line is maintenance cost and rebuild-estimate inflation with zero runtime value.
R8 · Dependency Hygiene
- Declared in the root package.json but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it.
- Declared in src/fable-compiler-js/package.json but never imported anywhere in that package or its workspace members — no static import reaches it. Usually that is dead weight and attack surface, but two shapes are indistinguishable from source and are NOT dead: an optional or native peer that another dependency loads dynamically at runtime, and a package a build, docs or test step installs and invokes separately. Confirm which of the three this is before removing it. (×2)
What to do
- Remove unused dependencies, declare unlisted imports explicitly, and demote type-/test-only packages to devDependencies.
R9 · Circular Imports
- src/fable-library-ts/BigInt.ts → src/fable-library-ts/Decimal.ts → src/fable-library-ts/BigInt.ts — src/fable-library-ts/BigInt.ts:3
What to do
- Break each cycle by extracting the shared piece into a module both sides can import.
X20 · Mistyped argument guard
X23 · Unguarded diagnostic materialisation
X27 · Collection changed while being enumerated
X28 · Index access outside its own emptiness guard
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 69% | Adequate | Acceptable, with room to improve. |
| Architecture | 91% | Exemplary | Solid. |
| Maturity | 73% | Strong | Solid. |
| Readiness | 64% | Adequate | Largest drag on the score — prioritise here. |
| Security | 73% | Adequate — gated by D29 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Event Sourcing | 100% | Exemplary | Strongest area. |
| Performance | 78% | Strong | Solid. |
Unscored — 2 check(s) recorded observations but carry no score
- SC1 Supply-chain hygiene — 1 observation(s) recorded · Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X10 Duplicated predicate — 25 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
Not evidenced — 4 control(s) we could not find positive evidence for
- C3 Audit Trail — Not assessed: these audit controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks audit controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C4 Data Retention — Not assessed: these retention controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks retention controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C5 Data-Subject Rights — Not assessed: these data-subject rights controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks data-subject rights controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- P5 DR & Backup — not evidenced — repo shows no backup/RTO/RPO controls; absence of evidence is not evidence of a working control
Not included — 69 check(s) not relevant to this codebase
- AC1 Text alternatives — No web markup found — accessibility is not applicable to this repository.
- AC2 Forms & labels — No web markup found — accessibility is not applicable to this repository.
- AC3 Page structure — No web markup found — accessibility is not applicable to this repository.
- AC4 Keyboard semantics — No web markup found — accessibility is not applicable to this repository.
- AC5 ARIA correctness — No web markup found — accessibility is not applicable to this repository.
- AC6 Visual & motion safety — No web markup found — accessibility is not applicable to this repository.
- AC7 A11y enforcement — No web markup found — accessibility is not applicable to this repository.
- AX1 Captive dependencies — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX2 Stateful singletons — No container singleton was found, so there is no shared instance for concurrent requests to race on. No F# function in this code takes an ASP.NET Core or Suave HttpContext (a Giraffe, Saturn, Falco, Oxpecker or Suave handler) and no F# class is an ASP.NET Core controller, so no request handler shares module state between request threads. No function in this Python code is served by a threaded web framework (a Flask, Bottle or FastAPI route, a Django or Pyramid view), so no module is shared between request threads. Dart isolates share no mutable memory, so no two requests write one object at the same instant. Erlang processes share no mutable memory — state lives in a process's own mailbox — so there is no shared object to race on. Its F# is compiled by Fable to JavaScript, which runs on one event loop, so no two requests write a shared object at the same instant. PHP builds its object graph per request and shares none of it between requests. Rust's compiler refuses unsynchronised shared mutation — a value shared across threads must be Sync — so the race this check looks for cannot be written. TypeScript/JavaScript runs each process's requests on one event loop, so no two requests write a shared object at the same instant (interleaving across an await is a different defect).
- AX5 Architecture & structure — not assessed — architecture style/structure is computed from a project graph (projects, types, module namespaces) that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AXB2 Runtime readiness — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- AXR1 Runtime accessibility — docker build failed (exit 127) — DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with BuildKit: https://docs.docker.com/go/bui…; runtime evidence skipped This is a statement about this run, not a statement about your application: nothing here says the surface is inaccessible, only that it was never rendered.
- C1 Data Protection — Not assessed: these personal data controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks personal data controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C2 Access Controls — Not assessed: these authorization controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks authorization controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- D1 Cyclomatic Complexity — Cyclomatic Complexity not included (time budget)
- D10 Test Quality — ~128127 lines of test source are present (.fs, .py, .js, .mjs) but no test cases reached the test census for this repository — no test root we could resolve declared them, or the files we read declare no cases in a test framework we recognise — so skipped/assertion-free tests couldn't be counted. Not scored — this is a gap in the analyzer, not a finding about this repository.
- D17 Explicit Debt — the C# workspace loaded 0 projects, so explicit-debt density could not be measured
- D18 Solution Shape — D18 scores the shape of a C#/VB .NET solution; this repository's .NET projects are all F# (.fsproj), which the C#/VB workspace does not load, so the dimension does not apply.
- D2 Cognitive Complexity — Cognitive Complexity not included (time budget)
- D23 Boundary Type-Coupling — No bounded-context organisation was detected either — neither a context-shaped layout, nor 2+ sibling source directories each declaring an aggregate root, nor 2+ projects each declaring an entity of their own. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
- D24 Comment Value — No inline comments to assess — comment value is not applicable here.
- D25 ADR Conformance — no ADRs to check
- D32 Data Compliance (PII/GDPR) — 27 file(s) were not parsed by semgrep — the PII/GDPR ruleset never ran over them
- D37 Vulnerability-disclosure Policy — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed.
- D39 IL Efficiency — IL not measured — the target did not build
- D4 Code Duplication — Code Duplication not included (time budget)
- D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
- D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
- D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
- D7 Architectural Integrity — no checkable ADRs and no dependency cycles — architectural integrity not assessed
- D8 Code Coverage — Coverage NOT MEASURED: the .NET half could not be measured — the repository wires up no coverage collector for `--collect:"XPlat Code Coverage"` to use; the JavaScript/TypeScript half could not be measured — the jest suite in tests/React/ ran and not one test passed (No tests found, exiting with code 1), so the coverage would describe the failed run, not the code. This repository's production source spans both ecosystems, and no partial figure is published as if it were the whole: coverage is excluded from the score rather than counted as a near-zero. The named suite step is one the repository's maintainers can perform; once it passes, the real number is measured on the next scan. Alternatively, commit the lcov/Cobertura report your CI produces and it is read without a re-run.
- DM1 Domain Modelling — applicable but not scored (3 signals for this style, 3 needed — the count is met but a required primary signal is absent): 19 strongly-typed id(s); 1488 value object(s); 50 domain event(s); its domain events are published by services or handlers — no domain entity raises one; no aggregate is declared and no domain structure surrounds the state-guarding types: not claimed as DDD
- ED2 Event/command shape — not scored — deciding whether a command has more than one competing handler requires resolving the call graph, which this analysis does not build from source alone for this language. Reported as guidance rather than measured
- ED2 Event/command shape — not scored — deciding whether a command has more than one competing handler requires resolving the call graph, and a call made through an inferred or generic receiver has no resolvable owner in the source. Reported as guidance rather than measured
- ED5 Idempotency — no mutating command handlers or message consumers detected — idempotency check not applicable
- IC1 Incompleteness & stubs — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- P12 CI test-gate honesty — Reported, not scored — and nothing was matched here. The coverage check applies to any stack, and the automatic-re-run check to any GitHub-Actions workflow, but the checks for excluded tests, skipped tests and sleep-based synchronisation currently recognise only some ecosystems' test-runner idioms, so on a repository built with another stack the zeros below mean 'not checked', not 'clean'.
- P7 Outbound HTTP resilience — not measured — the application kind could not be determined for this repo
- P8 Schema migrations — no ORM, schema-migration tool or schema auto-create was found in this repository's dependency manifests or source, so there is no database schema for this check to judge
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (Cobertura — `dotnet test --collect:"XPlat Code Coverage"` with a `coverlet.collector` PackageReference) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures, or wire coverage collection into CI, to enable this cross-layer check
- R11 Import Boundaries — No recognizable feature-sliced/layered src layout — boundary rules not applicable.
- R4 Test Coverage — 14 test file(s) reach none of 52 production file(s) via imports — exercised outside the JS import graph (integration/bundled), not import-reachable
- S1 Web-Security Posture — Not assessed: these web-security controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks web-security controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- X1 Async correctness — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X12 Unreachable branch — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X13 Undrained process stream — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X14 Bypassable address classification — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X15 Unvalidated length from an untrusted reader — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X16 Unfloored truncation loop — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X17 Uncapped recursion over a caller-supplied document — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X18 Disposal-pattern correctness — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X19 Unrestored process-global state — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X2 Cancellation propagation — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X21 Side-effecting pattern guard — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X22 Contradicted release guard — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X24 Document value interpolated into markup unescaped — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X25 Inert configuration knob — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X26 Unsynchronised callback handoff — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X29 Per-element action decided by a fixed element — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X3 Exception handling — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X30 Support guard that admits what it rejects — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X31 Test-only surface in a production module — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X32 Type resolved by simple name across every loaded assembly — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X4 Structured logging — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X5 Nullable reference types — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X6 Hand-rolled structured-format parsing — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X7 Silent fallback defaults — Advisory — this card reports evidence and never carries a score.
- X9 Subsumed condition operand — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
Critical — 105 finding(s)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Orphaned knowledge src/fcs-fable/src/Compiler/AbstractIL/ilwrite.fs:1
- Orphaned knowledge src/fcs-fable/src/Compiler/Checking/infos.fs:1
- Orphaned knowledge src/fcs-fable/src/Compiler/Symbols/Exprs.fs:1
- Orphaned knowledge src/fcs-fable/src/Compiler/Optimize/InnerLambdasToTopLevelFuncs.fs:1
- Orphaned knowledge src/fcs-fable/src/Compiler/Checking/SignatureConformance.fs:1
- Orphaned knowledge src/fable-library-dart/List.fs:1
- Orphaned knowledge src/Fable.PublishUtils/PublishUtils.fs:1
- Orphaned knowledge src/fable-library-php/Set.php:1
- Boundary-crossing change coupling: Replacements.fs ↔ Mutable.rs src/Fable.Transforms/Rust/Replacements.fs:1
- Boundary-crossing change coupling: Replacements.fs ↔ Option.fs src/Fable.Transforms/Rust/Replacements.fs:1
- Boundary-crossing change coupling: Replacements.fs ↔ double.py src/Fable.Transforms/Python/Replacements.fs:1
- Boundary-crossing change coupling: DartPrinter.fs ↔ Util.dart src/Fable.Transforms/Dart/DartPrinter.fs:1
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Test suite declares a test script but contains no test files: tests/React/
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Import cycle (2 files) src/fable-library-ts/BigInt.ts:3
Serious — 373 finding(s)
- FileTooLong: Expressions/CheckExpressions.fs src/fcs-fable/src/Compiler/Checking/Expressions/CheckExpressions.fs
- FileTooLong: TypedTree/TypedTreeOps.fs src/fcs-fable/src/Compiler/TypedTree/TypedTreeOps.fs
- FileTooLong: Beam/Replacements.fs src/Fable.Transforms/Beam/Replacements.fs
- FileTooLong: Rust/Fable2Rust.fs src/Fable.Transforms/Rust/Fable2Rust.fs
- FileTooLong: Fable.Transforms/Replacements.fs src/Fable.Transforms/Replacements.fs
- FileTooLong: AbstractIL/il.fs src/fcs-fable/src/Compiler/AbstractIL/il.fs
- FileTooLong: Checking/CheckDeclarations.fs src/fcs-fable/src/Compiler/Checking/CheckDeclarations.fs
- FileTooLong: AbstractIL/ilread.fs src/fcs-fable/src/Compiler/AbstractIL/ilread.fs
- FileTooLong: Babel/Fable2Babel.fs src/Fable.Transforms/Babel/Fable2Babel.fs
- FileTooLong: Checking/NameResolution.fs src/fcs-fable/src/Compiler/Checking/NameResolution.fs
- FileTooLong: src/array.rs src/fable-library-py/src/array.rs
- FileTooLong: Python/Fable2Python.Transforms.fs src/Fable.Transforms/Python/Fable2Python.Transforms.fs
- FileTooLong: Python/Replacements.fs src/Fable.Transforms/Python/Replacements.fs
- FileTooLong: Interactive/fsi.fs src/fcs-fable/src/Compiler/Interactive/fsi.fs
- FileTooLong: Dart/Replacements.fs src/Fable.Transforms/Dart/Replacements.fs
- FileTooLong: AbstractIL/ilwrite.fs src/fcs-fable/src/Compiler/AbstractIL/ilwrite.fs
- FileTooLong: TypedTree/TypedTree.fs src/fcs-fable/src/Compiler/TypedTree/TypedTree.fs
- FileTooLong: Optimize/Optimizer.fs src/fcs-fable/src/Compiler/Optimize/Optimizer.fs
- FileTooLong: TypedTree/TypedTreePickle.fs src/fcs-fable/src/Compiler/TypedTree/TypedTreePickle.fs
- FileTooLong: Service/FSharpCheckerResults.fs src/fcs-fable/src/Compiler/Service/FSharpCheckerResults.fs
- FileTooLong: Rust/Replacements.fs src/Fable.Transforms/Rust/Replacements.fs
- FileTooLong: Checking/ConstraintSolver.fs src/fcs-fable/src/Compiler/Checking/ConstraintSolver.fs
- FileTooLong: Fable.Transforms/FSharp2Fable.Util.fs src/Fable.Transforms/FSharp2Fable.Util.fs
- FileTooLong: Beam/Fable2Beam.fs src/Fable.Transforms/Beam/Fable2Beam.fs
- FileTooLong: Symbols/Symbols.fs src/fcs-fable/src/Compiler/Symbols/Symbols.fs
- TooManyFunctions: ILBinaryWriter src/fcs-fable/src/Compiler/AbstractIL/ilwrite.fs:3
- TooManyFunctions: Util src/Fable.Transforms/Rust/Fable2Rust.fs:1330
- TooManyFunctions: Util src/Fable.Transforms/Babel/Fable2Babel.fs:1041
- TooManyFunctions: TypeInfo src/Fable.Transforms/Rust/Fable2Rust.fs:371
- TooManyFunctions: Util src/Fable.Transforms/FSharp2Fable.Util.fs:2001
- TooManyFunctions: TypedTreeBasics src/fcs-fable/src/Compiler/TypedTree/TypedTreeBasics.fs:7
- TooManyFunctions: fable_library_rust::BigInt::BigInt_ src/fable-library-rust/src/BigInt.rs:102
- TooManyFunctions: fable_library_rust::Decimal::Decimal_ src/fable-library-rust/src/Decimal.rs:31
- TooManyFunctions: Exprs src/Fable.Transforms/Rust/AST/Rust.AST.Helpers.fs:702
- TooManyFunctions: fable_library_rust::Convert::Convert_ src/fable-library-rust/src/Convert.rs:40
- TooManyFunctions: QuotationPickler src/fcs-fable/src/Compiler/TypedTree/QuotationPickler.fs:3
- TooManyFunctions: fable_library_rust::Char::Char_ src/fable-library-rust/src/Char.rs:160
- TooManyFunctions: fable_date_offset src/fable-library-beam/fable_date_offset.erl:1
- TooManyFunctions: fable_library_rust::Native::Native_ src/fable-library-rust/src/Native.rs:59
- TooManyFunctions: quotation_ src/fable-library-rust/src/Quotation.fs:6
- TooManyFunctions: SetTreeModule src/fable-library-dart/Set.fs:26
- TooManyFunctions: SetTreeModule src/fable-library-py/fable_library/Set.fs:26
- TooManyFunctions: SetTreeModule src/fable-library-ts/Set.fs:26
- TooManyFunctions: MapTreeModule src/fable-library-dart/Map.fs:24
- TooManyFunctions: MapTreeModule src/fable-library-py/fable_library/Map.fs:25
- TooManyFunctions: MapTreeModule src/fable-library-ts/Map.fs:24
- TooManyFunctions: ResizeArrayModule src/fcs-fable/src/Compiler/Utilities/ResizeArray.fs:8
- TooManyFunctions: fable_quotation src/fable-library-beam/fable_quotation.erl:1
- TooManyFunctions: fable_utils src/fable-library-beam/fable_utils.erl:1
- TooManyFunctions: fable_library_rust::NativeArray::NativeArray_ src/fable-library-rust/src/NativeArray.rs:93
- TooManyMethods: FSharpArray src/fable-library-py/src/array.rs:21
- TooManyMethods: PhpCompiler src/Fable.Transforms/Php/Fable2Php.fs:1947
- TooManyMethods: DateTime src/fable-library-rust/src/DateTime.rs:29
- TooManyMethods: TransparentCompiler src/fcs-fable/src/Compiler/Service/TransparentCompiler.fs:410
- TooManyMethods: Float32 src/fable-library-py/src/floats.rs:619
- TooManyMethods: Float64 src/fable-library-py/src/floats.rs:620
- TooManyMethods: DateTimeOffset src/fable-library-rust/src/DateTimeOffset.rs:25
- TooManyMethods: TimeSpan src/fable-library-rust/src/TimeSpan.rs:11
- TooManyMethods: FSharpSet src/fable-library-ts/Set.fs:705
- TooManyMethods: Int8 src/fable-library-py/src/ints.rs:1029
- TooManyMethods: UInt8 src/fable-library-py/src/ints.rs:1031
- TooManyMethods: Int16 src/fable-library-py/src/ints.rs:1033
- TooManyMethods: UInt16 src/fable-library-py/src/ints.rs:1035
- TooManyMethods: Int32 src/fable-library-py/src/ints.rs:1037
- TooManyMethods: UInt32 src/fable-library-py/src/ints.rs:1039
- TooManyMethods: Int64 src/fable-library-py/src/ints.rs:1041
- TooManyMethods: UInt64 src/fable-library-py/src/ints.rs:1043
- TooManyMethods: FSharpMap src/fable-library-ts/Map.fs:678
- TooManyMethods: BackgroundCompiler src/fcs-fable/src/Compiler/Service/BackgroundCompiler.fs:236
- TooManyMethods: ProvidedType src/fcs-fable/src/Compiler/TypedTree/TypeProviders.fs:337
- TooManyMethods: Regex src/fable-library-rust/src/RegExp.rs:14
- TooManyMethods: StringBuilder src/fable-library-py/fable_library/System.Text.fs:6
- TooManyMethods: FSharpSet src/fable-library-py/fable_library/Set.fs:705
- TooManyMethods: StringBuilder src/fable-library-ts/System.Text.fs:3
- TooManyMethods: ConcurrentDictionary`2 src/fcs-fable/System.Collections.Concurrent.fs:27
- Hotspot: src/Fable.Transforms/Beam/Replacements.fs src/Fable.Transforms/Beam/Replacements.fs:5781
- Hotspot: src/Fable.Transforms/Rust/Replacements.fs src/Fable.Transforms/Rust/Replacements.fs:1374
- Hotspot: src/Fable.Transforms/Rust/Fable2Rust.fs src/Fable.Transforms/Rust/Fable2Rust.fs:1150
- Hotspot: src/Fable.Transforms/Python/Replacements.fs src/Fable.Transforms/Python/Replacements.fs:1148
- Hotspot: src/Fable.Transforms/Beam/Fable2Beam.fs src/Fable.Transforms/Beam/Fable2Beam.fs:316
- Hotspot: src/Fable.Transforms/Replacements.fs src/Fable.Transforms/Replacements.fs:1499
- Hotspot: src/Fable.Transforms/Python/Fable2Python.Transforms.fs src/Fable.Transforms/Python/Fable2Python.Transforms.fs:930
- Hotspot: src/Fable.Transforms/Babel/Fable2Babel.fs src/Fable.Transforms/Babel/Fable2Babel.fs:1710
- Hotspot: src/Fable.Transforms/Python/Fable2Python.Util.fs src/Fable.Transforms/Python/Fable2Python.Util.fs:1020
- Hotspot: src/Fable.Transforms/Dart/Replacements.fs src/Fable.Transforms/Dart/Replacements.fs:975
- Hotspot: src/fable-standalone/src/Worker/Worker.fs src/fable-standalone/src/Worker/Worker.fs:339
- Hotspot: src/fable-standalone/src/Main.fs src/fable-standalone/src/Main.fs:467
- Hotspot: src/Fable.Transforms/Transforms.Util.fs src/Fable.Transforms/Transforms.Util.fs:1762
- Hotspot: src/Fable.Transforms/FSharp2Fable.Util.fs src/Fable.Transforms/FSharp2Fable.Util.fs:1648
- Hotspot: src/Fable.Cli/Main.fs src/Fable.Cli/Main.fs:1491
- Hotspot: src/Fable.Transforms/Dart/Fable2Dart.fs src/Fable.Transforms/Dart/Fable2Dart.fs:826
- Hotspot: src/Fable.Transforms/Python/Fable2Python.Reflection.fs src/Fable.Transforms/Python/Fable2Python.Reflection.fs:117
- Hotspot: src/Fable.Transforms/Beam/Fable2Beam.Util.fs src/Fable.Transforms/Beam/Fable2Beam.Util.fs:199
- Hotspot: REDACTED REDACTED:369
- Hotspot: src/Fable.Transforms/Php/Fable2Php.fs src/Fable.Transforms/Php/Fable2Php.fs:936
- Hotspot: src/fable-library-rust/src/Quotation.fs src/fable-library-rust/src/Quotation.fs:437
- Hotspot: src/Fable.Compiler/ProjectCracker.fs src/Fable.Compiler/ProjectCracker.fs:894
- Hotspot: src/Fable.Transforms/Replacements.Util.fs src/Fable.Transforms/Replacements.Util.fs:1308
- Hotspot: src/Fable.Transforms/Beam/ErlangPrinter.fs src/Fable.Transforms/Beam/ErlangPrinter.fs:100
- Hotspot: src/Fable.Compiler/MSBuildCrackerResolver.fs src/Fable.Compiler/MSBuildCrackerResolver.fs:202
- Repeated repair: src/fable-library-rust/src/Native.rs src/fable-library-rust/src/Native.rs:399
- Repeated repair: src/fable-library-py/fable_library/async_.py src/fable-library-py/fable_library/async_.py:85
- Repeated repair: src/fable-library-rust/src/Reflection.rs src/fable-library-rust/src/Reflection.rs:78
- Repeated repair: src/fable-library-ts/Async.ts src/fable-library-ts/Async.ts:194
- Repeated repair: src/Fable.Transforms/State.fs src/Fable.Transforms/State.fs:216
- Repeated repair: src/fable-library-py/fable_library/async_builder.py src/fable-library-py/fable_library/async_builder.py:64
- Repeated repair: src/Fable.Transforms/Beam/Prelude.fs src/Fable.Transforms/Beam/Prelude.fs:691
- Repeated repair: src/fable-library-rust/src/Async.rs src/fable-library-rust/src/Async.rs:485
- Repeated repair: src/Fable.Transforms/Rust/AST/Rust.AST.Helpers.fs src/Fable.Transforms/Rust/AST/Rust.AST.Helpers.fs:340
- Repeated repair: src/fable-library-py/fable_library/decimal_.py src/fable-library-py/fable_library/decimal_.py:117
- Repeated repair: src/fable-library-py/fable_library/mailbox_processor.py src/fable-library-py/fable_library/mailbox_processor.py:155
- Repeated repair: src/fable-library-ts/AsyncBuilder.ts src/fable-library-ts/AsyncBuilder.ts:202
- Repeated repair: src/fable-library-rust/src/Event.rs src/fable-library-rust/src/Event.rs:351
- Repeated repair: src/fable-library-rust/src/Observable.rs src/fable-library-rust/src/Observable.rs:302
- Change coupling: HashMap.rs ↔ HashSet.rs src/fable-library-rust/src/HashMap.rs:1
- Change coupling: MutableMap.fs ↔ MutableSet.fs src/fable-library-ts/MutableMap.fs:1
- Change coupling: Array.fs ↔ List.fs src/fable-library-rust/src/Array.fs:1
- Change coupling: Interfaces.fs ↔ Native.rs src/fable-library-rust/src/Interfaces.fs:1
- Change coupling: numeric.py ↔ string_.py src/fable-library-py/fable_library/numeric.py:1
- Change coupling: HashSet.rs ↔ String.rs src/fable-library-rust/src/HashSet.rs:1
- FunctionTooLong: Date.dateToStringWithCustomFormat src/fable-library-ts/Date.ts:93
- FunctionTooLong: DateTimeFormat.dateToStringWithCustomFormat src/fable-library-ts/DateTimeFormat.ts:111
- FunctionTooLong: fable_library_core::array::register_array_module src/fable-library-py/src/array.rs:5613
- FunctionTooLong: String.format REDACTED:369
- Duplicated block (9 lines × 2 locations) src/fable-library-ts/AsyncBuilder.ts:209
- Duplicated block (9 lines × 2 locations) src/fable-library-ts/Date.ts:472
- Duplicated block (9 lines × 2 locations) src/fable-library-ts/Numeric.ts:57
- Duplicated block (9 lines × 2 locations) REDACTED:83
- Duplicated block (12 lines × 2 locations) src/fable-library-ts/Date.ts:103
- Duplicated block (12 lines × 2 locations) src/fable-library-ts/DateTimeFormat.ts:121
- Duplicated block (12 lines × 2 locations) src/fable-library-ts/Encoding.ts:108
- Duplicated block (7 lines × 2 locations) src/fable-library-ts/DateTimeFormat.ts:381
- Duplicated block (7 lines × 2 locations) src/fable-library-ts/Reflection.ts:345
- Duplicated block (7 lines × 2 locations) src/fable-library-ts/lib/big.js:593
- Duplicated block (5 lines × 2 locations) src/fable-library-ts/AsyncBuilder.ts:184
- Duplicated block (5 lines × 2 locations) src/fable-library-ts/Date.ts:741
- Duplicated block (5 lines × 2 locations) src/fable-library-ts/DateTimeTemporal.ts:31
- REDACTED
- REDACTED
- ClassTooLong: FSharpArray src/fable-library-py/src/array.rs:21
- ClassTooLong: NativeArray src/fable-library-py/src/native_array.rs:118
- REDACTED
- REDACTED
- Sync-over-async blocking src/fcs-fable/src/Compiler/Facilities/DiagnosticsLogger.fs:1069
- Sync-over-async blocking src/fcs-fable/src/Compiler/Facilities/BuildGraph.fs:64
- Duplicated block (21 lines × 3 locations) src/fable-library-ts/Date.ts:177
- Duplicated block (21 lines × 3 locations) src/fable-library-ts/DateTimeFormat.ts:178
- Duplicated block (15 lines × 2 locations) src/fable-library-ts/Date.ts:156
- Duplicated block (15 lines × 2 locations) src/fable-library-ts/Observable.ts:76
- Duplicated block (10 lines × 2 locations) src/fable-library-ts/Char.ts:81
- Duplicated block (10 lines × 2 locations) src/fable-library-ts/DateTimeOffsetTemporal.ts:302
- Duplicated block (6 lines × 2 locations) src/fable-library-ts/CollectionUtil.ts:77
- Duplicated block (6 lines × 2 locations) src/fable-library-ts/CollectionUtil.ts:146
- Complex function parseRaw (cyclomatic 26, cognitive 49) src/fable-library-ts/Date.ts:605
- Complex function parseRaw (cyclomatic 26, cognitive 49) src/fable-library-ts/DateTimeFormat.ts:513
- Redundant and confusing null-handling factory methods. 'Create' returns MaybeNull, 'CreateNonNull' presumably throws or asserts, and 'CreateWithNullCheck' is ambiguous about its return type and behavior compared to 'Create'. It is unclear if 'CreateWithNullCheck' is a safer wrapper around 'Create' or a distinct validation step.
- Inconsistent naming for untainting operations. 'PUntaint' is a method on the instance, while 'PUntaintNoFailure' takes a function argument. The 'NoFailure' suffix is non-standard and unclear. It is not obvious if 'PUntaint' can fail or if 'PUntaintNoFailure' is a variant that handles errors differently.
- Inconsistent use of 'Try' prefix and return types. Some methods return 'Tainted' directly (implying they might throw or wrap), while others return 'Tainted' but are named 'Try...'. 'unmarshal' is a distinct operation but lacks the 'Try' prefix despite likely being fallible. The distinction between 'TryTypeMember' and 'TryTypeMemberNonNull' is unclear without documentation.
- Change-coupling hub: Option.fs → Array.fs, List.fs, Native.rs src/fable-library-rust/src/Option.fs
- REDACTED
- REDACTED
- End-of-life runtime: .NET net9.0 src/quicktest-beam/quicktest.fsproj:4
- Coverage not measured — .NET and JavaScript/TypeScript suite
- README may be stale
- Duplicated block with local edits (139 matched lines × 2 locations) src/fable-library-ts/Date.ts:691
- Duplicated block (69 lines × 2 locations) src/fable-library-ts/Date.ts:605
- Duplicated block (57 lines × 2 locations) src/fable-library-ts/Date.ts:303
- Duplicated block (36 lines × 2 locations) src/fable-library-ts/TimeSpan.ts:143
- Duplicated block (35 lines × 2 locations) src/fable-library-ts/DateOnly.ts:76
- Duplicated block (34 lines × 2 locations) src/fable-library-ts/Date.ts:58
- Duplicated block (16 lines × 2 locations) src/fable-library-ts/Util.ts:410
- Duplicated block with local edits (14 matched lines × 2 locations) src/fable-library-ts/Uri.ts:101
- Duplicated block (13 lines × 2 locations) src/fable-library-ts/TimeSpan.ts:184
- Duplicated block (12 lines × 4 locations) src/fable-library-ts/BitConverter.ts:21
- Duplicated block (12 lines × 3 locations) src/fable-library-ts/TimeOnly.ts:99
- Duplicated block with local edits (12 matched lines × 2 locations) src/fable-library-ts/TimeOnly.ts:7
- Duplicated block (11 lines × 2 locations) src/fable-library-ts/TimeSpan.ts:18
- Duplicated block (10 lines × 3 locations) src/fable-library-ts/Date.ts:409
- Duplicated block with local edits (9 matched lines × 2 locations) src/fable-library-ts/Types.ts:130
- Duplicated block (8 lines × 5 locations) src/fable-library-ts/Char.ts:136
- Duplicated block (8 lines × 2 locations) src/fable-library-ts/CollectionUtil.ts:52
- Duplicated block (5 lines × 10 locations) src/fable-library-ts/BitConverter.ts:92
- Duplicated block (5 lines × 8 locations) src/fable-library-ts/BitConverter.ts:108
- Complex function dateToStringWithCustomFormat (cyclomatic 65, cognitive 87) src/fable-library-ts/Date.ts:93
- Complex function (anonymous) (cyclomatic 61, cognitive 104) REDACTED:379
- Complex function dateToStringWithCustomFormat (cyclomatic 58, cognitive 76) src/fable-library-ts/DateTimeFormat.ts:111
- Complex function divide (cyclomatic 34, cognitive 78) src/fable-library-ts/lib/big.js:419
- Complex function round (cyclomatic 32, cognitive 33) src/fable-library-ts/lib/big.js:195
- Complex function formatReplacement (cyclomatic 29, cognitive 41) REDACTED:229
- Complex function walk (cyclomatic 24, cognitive 28) src/fable-library-ts/quotation.ts:550
- Complex function evaluate (cyclomatic 22, cognitive 26) src/fable-library-ts/quotation.ts:411
- Complex function sub (cyclomatic 21, cognitive 34) src/fable-library-ts/lib/big.js:579
- Complex function parse (cyclomatic 21, cognitive 30) src/fable-library-ts/TimeSpanTemporal.ts:225
- Complex function split (cyclomatic 20, cognitive 37) REDACTED:678
- Complex function parse (cyclomatic 20, cognitive 27) src/fable-library-ts/TimeSpan.ts:143
- Complex function exprToString (cyclomatic 20, cognitive 26) src/fable-library-ts/quotation.ts:518
- Complex function sub (cyclomatic 20, cognitive 21) src/fable-library-ts/quotation.ts:604
- src/fable-library-ts/lib/big.js: 879 lines of code src/fable-library-ts/lib/big.js:1
- src/fable-library-ts/Util.ts: 863 lines of code src/fable-library-ts/Util.ts:1
- src/fable-library-ts/Date.ts: 815 lines of code src/fable-library-ts/Date.ts:1
- REDACTED: 702 lines of code REDACTED:1
- src/fable-library-ts/quotation.ts: 617 lines of code src/fable-library-ts/quotation.ts:1
- src/fable-library-ts/DateTimeFormat.ts: 545 lines of code src/fable-library-ts/DateTimeFormat.ts:1
- src/fable-library-ts/Reflection.ts: 538 lines of code src/fable-library-ts/Reflection.ts:1
- Dead file (~72 LoC) REDACTED
- Dead file (~31 LoC) src/fable-standalone/src/Worker/util.js
- Unused dependency 'ghreleases'
- Unused dependency '@fable-org/fable-metadata'
- Unused dependency '@fable-org/fable-standalone'
- NuGet dependencies are not locked
Minor — 146 finding(s)
- Outdated (npm): @asamuzakjp/css-color
- Outdated (npm): @types/jsdom
- Outdated (npm): ansi-escapes
- Outdated (npm): bl
- Outdated (npm): camelcase
- Outdated (npm): chokidar
- Outdated (npm): commander
- Outdated (npm): data-urls
- Outdated (npm): escape-string-regexp
- Outdated (npm): execa
- Outdated (npm): find-up
- Outdated (npm): get-stream
- Outdated (npm): html-encoding-sniffer
- Outdated (npm): human-signals
- Outdated (npm): js-tokens
- Outdated (npm): jsdom tests/React/package.json:7
- Outdated (npm): json-parse-even-better-errors
- Outdated (npm): locate-path
- Outdated (npm): mimic-fn
- Outdated (npm): onetime
- Outdated (npm): p-limit
- Outdated (npm): p-locate
- Outdated (npm): parse-json
- Outdated (npm): pkg-dir
- Outdated (npm): string-length
- Orphaned file src/fcs-fable/service_slim.fs:1
- Orphaned file src/Fable.Transforms/Php/PhpPrinter.fs:1
- Orphaned file src/fcs-fable/src/Compiler/Checking/AccessibilityLogic.fs:1
- Orphaned file src/fcs-fable/src/Compiler/TypedTree/QuotationPickler.fs:1
- Orphaned file src/fcs-fable/src/Compiler/Service/ServiceAssemblyContent.fs:1
- Orphaned file src/fcs-fable/src/Compiler/Utilities/lib.fs:1
- Orphaned file src/fable-library-dart/Date.dart:1
- Orphaned file src/fable-library-php/Map.php:1
- Orphaned file src/fable-library-php/List.php:1
- Orphaned file src/fcs-fable/src/Compiler/Optimize/LowerLocalMutables.fs:1
- Orphaned file src/fcs-fable/src/Compiler/Symbols/SymbolPatterns.fs:1
- Orphaned file src/fcs-fable/src/Compiler/TypedTree/tainted.fs:1
- Orphaned file src/fable-library-ts/Uri.ts:1
- Orphaned file src/fcs-fable/src/Compiler/Service/ExternalSymbol.fs:1
- Orphaned file src/fable-library-dart/RegExp.dart:1
- Orphaned file src/fcs-fable/src/Compiler/Utilities/EditDistance.fs:1
- Orphaned file src/fcs-fable/ast_print.fs:1
- Orphaned file src/fable-library-php/Serialization.php:1
- Orphaned file src/fable-library-php/Util.php:1
- Orphaned file src/Fable.Transforms/Printer.fs:1
- Orphaned file src/tools/ASTViewer/ASTViewer.fs:1
- Orphaned file src/fcs-fable/src/Compiler/Facilities/ReferenceResolver.fs:1
- Orphaned file src/Fable.AST/Common.fs:1
- Orphaned file src/fable-library-php/Seq.php:1
- Orphaned file src/fcs-fable/src/Compiler/Service/SemanticClassificationKey.fs:1
- Duplicated predicate src/fcs-fable/src/Compiler/Checking/PostInferenceChecks.fs:1521
- Duplicated predicate src/fable-library-beam/Range.fs:15
- Duplicated predicate src/fable-library-dart/Array.fs:687
- Duplicated predicate src/Fable.Transforms/Babel/Fable2Babel.fs:1114
- Duplicated predicate src/Fable.Transforms/Babel/Fable2Babel.fs:1103
- Duplicated predicate src/Fable.Transforms/Babel/Fable2Babel.fs:4910
- Duplicated predicate src/Fable.Transforms/Dart/Replacements.fs:4182
- Duplicated predicate src/fcs-fable/src/Compiler/Checking/CheckFormatStrings.fs:451
- Duplicated predicate src/fcs-fable/src/Compiler/Checking/PostInferenceChecks.fs:2602
- Duplicated predicate src/fable-library-dart/System.Text.fs:106
- Duplicated predicate src/fable-library-beam/Seq.fs:1251
- Duplicated predicate src/fable-library-beam/Seq.fs:542
- Duplicated predicate src/fcs-fable/src/Compiler/Checking/ConstraintSolver.fs:2217
- Duplicated predicate src/Fable.Compiler/ProjectCracker.fs:442
- Duplicated predicate src/fcs-fable/src/Compiler/Driver/ScriptClosure.fs:440
- Duplicated predicate src/fable-library-dart/Array.fs:182
- Duplicated predicate src/Fable.Cli/Printers.fs:36
- Duplicated predicate src/fcs-fable/src/Compiler/CodeGen/IlxGen.fs:5703
- Duplicated predicate src/fcs-fable/src/Compiler/Driver/fsc.fs:533
- Duplicated predicate src/fcs-fable/src/Compiler/Service/IncrementalBuild.fs:851
- Duplicated predicate src/fcs-fable/src/Compiler/Utilities/sformat.fs:464
- Duplicated predicate src/fcs-fable/src/Compiler/Checking/AugmentWithHashCompare.fs:1430
- Duplicated predicate src/fcs-fable/src/Compiler/TypedTree/TypedTreeBasics.fs:292
- Duplicated predicate src/Fable.Cli/Printers.fs:147
- Duplicated predicate src/Fable.Cli/Printers.fs:98
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Off-boarding risk: anonymized user #1
- Off-boarding risk: anonymized user #2
- Off-boarding risk: anonymized user #3
- Off-boarding risk: anonymized user #4
- Off-boarding risk: anonymized user #5
- Fat interface: MutableArray (19 required operations) src/fable-library-ts/Util.ts:3
- Outdated: FSharp.Core src/Fable.Core/Fable.Core.fsproj:28
- Further sole-owners (lower concentration)
- No ADRs found
- Projects may be oversized for their cohesion
- Scattered collaborators
- REDACTED
- Further orphaned files (smaller)
- REDACTED
- REDACTED
- No ADRs
- README/code drift README.md:41
- Large public API surface
- Logging is not universal
- Unused export 'ICollection' src/fable-library-ts/Util.ts:69
- Unused export 'isMutableArray' src/fable-library-ts/Util.ts:116
- Unused export 'isIterable' src/fable-library-ts/Util.ts:120
- Unused export 'disposeSafe' src/fable-library-ts/Util.ts:148
- Unused export 'getEnumerator' src/fable-library-ts/Util.ts:218
- Unused export 'enumerableToIterator' src/fable-library-ts/Util.ts:233
- Unused export 'comparerFromEqualityComparer' src/fable-library-ts/Util.ts:279
- Unused export 'assertEqual' src/fable-library-ts/Util.ts:296
- Unused export 'assertNotEqual' src/fable-library-ts/Util.ts:305
- Unused export 'lazyFromValue' src/fable-library-ts/Util.ts:338
- Unused export 'int16ToString' src/fable-library-ts/Util.ts:358
- Unused export 'int32ToString' src/fable-library-ts/Util.ts:363
- Unused export 'int64ToString' src/fable-library-ts/Util.ts:368
- Unused export 'fastStructuralHash' src/fable-library-ts/Util.ts:486
- Unused export 'safeHash' src/fable-library-ts/Util.ts:491
- Unused export 'physicalEquals' src/fable-library-ts/Util.ts:526
- Unused export 'clamp' src/fable-library-ts/Util.ts:640
- Unused export 'createAtom' src/fable-library-ts/Util.ts:644
- Unused export 'createObj' src/fable-library-ts/Util.ts:655
- Unused export 'jsOptions' src/fable-library-ts/Util.ts:663
- Unused export 'round' src/fable-library-ts/Util.ts:669
- Unused export 'sign' src/fable-library-ts/Util.ts:679
- Unused export 'unescapeDataString' src/fable-library-ts/Util.ts:683
- Unused export 'escapeDataString' src/fable-library-ts/Util.ts:687
- Unused export 'escapeUriString' src/fable-library-ts/Util.ts:694
- Unused export 'uncurry2' src/fable-library-ts/Util.ts:730
- Unused export 'curry2' src/fable-library-ts/Util.ts:737
- Unused export 'uncurry3' src/fable-library-ts/Util.ts:741
- Unused export 'curry3' src/fable-library-ts/Util.ts:748
- Unused export 'uncurry4' src/fable-library-ts/Util.ts:753
- Unused export 'curry4' src/fable-library-ts/Util.ts:762
- Unused export 'uncurry5' src/fable-library-ts/Util.ts:767
- Unused export 'curry5' src/fable-library-ts/Util.ts:776
- Unused export 'uncurry6' src/fable-library-ts/Util.ts:781
Minor — 174 finding(s)
- Outdated (npm): @adobe/css-tools
- Outdated (npm): @babel/code-frame
- Outdated (npm): @babel/compat-data
- Outdated (npm): @babel/core
- Outdated (npm): @babel/generator
- Outdated (npm): @babel/helper-annotate-as-pure
- Outdated (npm): @babel/helper-compilation-targets
- Outdated (npm): @babel/helper-globals
- Outdated (npm): @babel/helper-module-imports
- Outdated (npm): @babel/helper-module-transforms
- Outdated (npm): @babel/helper-plugin-utils
- Outdated (npm): @babel/helper-string-parser
- Outdated (npm): @babel/helper-validator-identifier
- Outdated (npm): @babel/helper-validator-option
- Outdated (npm): @babel/helpers
- Outdated (npm): @babel/parser
- Outdated (npm): @babel/plugin-syntax-jsx
- Outdated (npm): @babel/plugin-syntax-typescript
- Outdated (npm): @babel/plugin-transform-modules-commonjs
- Outdated (npm): @babel/plugin-transform-react-jsx
- Outdated (npm): @babel/runtime
- Outdated (npm): @babel/template
- Outdated (npm): @babel/traverse
- Outdated (npm): @babel/types
- Outdated (npm): @bcoe/v8-coverage
- Outdated: Fable.Core
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-2b3d6d1f230a43939edac7e0be37304b/history.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-history.json |
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-git --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-2b3d6d1f230a43939edac7e0be37304b/tree.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-tree.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --config /opt/semgrep-rules/watchdog-sast.yml --json --quiet --timeout 10 --timeout-threshold 3 --metrics off . | 92 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | dotnet | — | dotnet list Fable.sln package --vulnerable --include-transitive --format json | 4 | artifacts/raw/dotnet-vulnerable.json |
| D31 · IaC & Container Security | trivy | — | trivy config --format json --quiet . | 13 | artifacts/raw/trivy-config.json |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. semgrep could not parse 27 file(s) — `src/fable-library-py/fable_library/async_.py`, `src/fable-library-py/fable_library/async_builder.py`, `src/fable-library-py/fable_library/bases.py`, `src/fable-library-py/fable_library/choice.pyi`, `src/fable-library-py/fable_library/core/array.pyi`, … (+22 more) — so the PII/GDPR sweep did not cover the unparsed regions of them; rows reported elsewhere in those files are real. | 0 | — |
| D37 · Vulnerability-disclosure Policy | disclosure | — | disclosure: not applicable — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed. | 0 | — |
| D40 · Network Egress Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here. | 0 | — |
| D41 · Kernel & Syscall Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here. | 0 | — |
| D42 · Runtime Threat Enforcement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here. | 0 | — |
| D43 · Malicious Dependencies | trivy | — | trivy fs --scanners vuln --format json --quiet --severity CRITICAL,HIGH,MEDIUM,LOW --skip-dirs **/bin/** --skip-dirs **/obj/** . --skip-db-update | 0 | artifacts/raw/trivy-fs.json |