Fix units-of-measure changes not invalidating incremental builds

[Copilot]

Incremental builds failed to detect when units-of-measure changed in type definitions (e.g., int<kg> → int<m>), causing stale errors and requiring full rebuilds.

Root cause

hashMeasure in TypeHashing.fs only hashed measure variables ('u) but ignored measure constants (kg, m), so int<a> and int<b> produced identical signature hashes.

Changes

• TypeHashing.fs: Updated hashMeasure to hash both measure variables and constants via ListMeasureConOccsWithNonZeroExponents
• ImpliedSignatureHashTests.fs: Added test case verifying UOM changes produce different hashes

// Before: only hashed variables
let private hashMeasure unt =
    ListMeasureVarOccsWithNonZeroExponents unt
    |> hashListOrderIndependent (fun (typar, exp) -> ...)

// After: hashes both variables and constants
let private hashMeasure g unt =
    let varHash = ListMeasureVarOccsWithNonZeroExponents unt |> ...
    let conHash = ListMeasureConOccsWithNonZeroExponents g false unt |> ...
    varHash @@ conHash

Fixes #10967383

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Units-of-measure changes between F# projects aren't always noticed by Build, requiring Rebuild to fix errors</issue_title>
<issue_description>This issue has been moved from a ticket on Developer Community.

---

Repro case is in https://github.com/marklam/UnitsMismatch - the README is copied below:

This repository demonstrates a bug in the F# build system related to type providers and units of measure across different projects.
The issue is that changing the unit of measure in a record type is not always noticed by the build system, causing errors to not appear, or not go away
(depending on whether your edit is causing or fixing a units-of-measure mismatch).

Steps to Reproduce

1. **Initial State (build error) **

   • In ClassLibrary1/TypeWIthUnits.fs, the record is defined as:

     type RecordWithUnits =
         {
             Value: int<a>
         }

   • In UnitsMismatch/Usage.fs), a value of type int<b> is supplied to RecordWithUnits.
   • Result: The project will not build due to a units-of-measure mismatch error.

2. Change the UOM (to fix the error)

   • Change the declaration of RecordWithUnits to:

     type RecordWithUnits =
         {
             Value: int<b>
         }

   • Action: Perform a Build (not Rebuild).
   • Result: The build fails with the same error as before, even though the code should now be correct.

3. Perform a Rebuild

   • Now perform a Rebuild operation.
   • Result: The build succeeds as expected.

4. Change Back to Original UOM (to cause a build error)

   • Change the declaration of RecordWithUnits back to:

     type RecordWithUnits =
         {
             Value: int<a>
         }

   • Action: Perform a Build.
   • Result: The build succeeds, even though it should fail due to the units-of-measure mismatch.

5. Rebuild Again

   • Perform a Rebuild.
   • Result: The expected build error appears.

Summary

• Build does not always pick up changes to units of measure in record types, leading to stale or incorrect build results.
• Rebuild is required to get the correct build status after such changes.

Expected Behavior

Changing the unit of measure in a type definition should always result in the correct build errors or success, even with an incremental Build.

Actual Behavior

Build does not always detect changes to units of measure, leading to confusing or incorrect build results. Only a full Rebuild produces the correct outcome.

---

Original Comments

Feedback Bot on 9/17/2025, 05:08 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

<agent_instructions>This issue reports a problem with build (via dotnet build) not being invalidated when unit of measure changes.

I assume this is related to the MVID calculation feature (it is written in ilwrite) and how we hash contents. Reason is, unit of measure causes the IL to be the same. It is only the unit of measure that changes, and that is only recorded in the F# signature blod (.NET resource) as result of SignatureHash.fs hashing. Find the place where types are hashed and how units of measure are hashed - I believe this is the problem.

Try to test this by creating 2 different on-disk projects, calling dotnet build, then just changing the unit of measure, and calling dotnet build again. Just like in the repro steps.

Since this involves msbuild machinery, if we want to keep it around as an automated test, we should use the "mvid" tests which are part of ComponentTests suite. i.e. a piece of code, after changing unit of measure, should get different mvid. The tests will be called something like .mvid., or possibly "deterministic".</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Note

Custom agent used: F# agent
Generic agent for F# coding following the coding guidelines of F# from MsLearn

• Fixes Units-of-measure changes between F# projects aren't always noticed by Build, requiring Rebuild to fix errors #19049

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.