[cknitt]

Fixes #9072.

Analysis modelled module M = F(X) by F's own body, so hover and completion on M's items showed the body's parameter types (array<O.t>). M is now modelled by the signature the compiler computed for the application.

That signature keeps the identifiers of F's body, whose stamps already name the body's items in the file's stamp table. So it is renamed with Subst first, from a stamp counter raised far above the stamps in a typed tree.

New analysis test: AppliedFunctor.

Members of the applied module are also connected to their declarations in the functor's body, so Find References and rename cover both within a file, including nested modules.

Known limitation: across files, references and rename don't connect a use such as StrSet.add to add in the functor's file. That needs external references for renamed members; go to definition and hover links do resolve to the functor's file.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Kbf3gLMawVgtmiKy3TMBc3

[github-actions]

Changelog

🐛 Bug fix

• Hover and completion on a module created by applying a functor show the applied types, such as array<int>, instead of the functor body's array<O.t>.

Semantic Diff

15 commits · Full page

Use the applied signature for modules created by functor application

_{011b3ef · cknitt + Claude · Oct 27, 2026, 12:59 UTC}

Why

Editor analysis modelled module M = F(X) by F's own body, so hover and completion on M's items showed the types of the functor's body, with the parameter's types such as O.t, instead of the argument's. M is now modelled by the signature the compiler computed for the application. That signature keeps the identifiers of F's body, whose stamps already name the body's items, so it is renamed first.

Diagnostic modified (completion on an applied functor)

module type Ord = {
  type t
  let compare: (t, t) => int
}
module MakeSet = (O: Ord) => {
  type t = array<O.t>
  let add = (s: t, x: O.t) => s->Array.concat([x])
}
module IntSet = MakeSet({
  type t = int
  let compare = (a: int, b) => a - b
})
// IntSet.

text · tests/analysis_tests/tests/src/AppliedFunctor.res

-"detail": "(t, O.t) => array<O.t>"
+"detail": "(t, int) => array<int>"

Diagnostic modified (hover on a type of an applied functor)

text

-type IntSet.t = array<O.t>
+type IntSet.t = array<int>

Review

• Why raise the stamp counter before renaming? The renamed identifiers get stamps from the analysis process's own counter, which starts low and would hand out stamps that the typed tree already uses; above 2^40 they cannot meet one.

Keep the functor's file for members of an applied functor

_{daa9c2a · cknitt + Claude · Oct 27, 2026, 17:45 UTC}

Codex review on #9084: the members of module M = Other.Make(X) were registered in the current file with the locations of Other's functor body, so Go to Definition and hover's type-definition link combined Other's location with the current file. Their module path now records the functor, as it does for included modules, so both resolve to the functor's file.

Link signature help type definitions to their declaring file

_{3dcad77 · cknitt + Claude · Oct 27, 2026, 20:22 UTC}

Codex review on #9084: signature help built its Type definition link from the caller's file, so for a type of an applied functor from another file it pointed into the caller. It now takes the file from the type's declaration, as hover does; the link function requires it, so no caller can fall back to the wrong file.

Connect renamed members of an applied functor to their declarations

_{1a1151c · cknitt + Claude · Oct 27, 2026, 20:22 UTC}

Codex review on #9084: the members of an applied functor are registered under fresh stamps, so references to IntSet.add were no longer references to MakeSet.add; Find References missed them and renaming the declaration left them unchanged. Each renamed stamp now maps to the stamp it was renamed from: a use of the member is also recorded as a use of the original, and references starting from the member start from the original.

Connect nested modules of an applied functor to their declarations

_{a2bc738 · cknitt + Claude · Oct 27, 2026, 21:23 UTC}

Codex review on #9084: uses of a module path such as M.Nested were recorded only under the renamed stamp. They are now also recorded under the original, like value uses. The originals are taken from the functor's result signature: when the argument is a path, the application's signature was already renamed by the compiler and doesn't carry the body's stamps.

Resolve applied fields and constructors to the functor's declarations

_{204f37d · cknitt + Claude · Oct 28, 2026, 07:45 UTC}

Codex review on #9084: an applied functor's record fields and constructors are read from its signature, where they have no location. Go to Definition returned that missing location, and rename added it as a reference, producing edits at character -1. Their lookups now go through the type they were renamed from, which has the body's locations, and fields and constructors without a location are not registered as references.

Register module types of an applied functor's signature

_{73c883f · cknitt + Claude · Oct 29, 2026, 06:11 UTC}

Codex review on #9084: the applied signature's module types were dropped, because the signature walk handled modules but not module types, so a member declared with one, such as Applied.Nested.value with module Nested: S, no longer resolved. Module types are registered like those of a structure now.

Map the members of an applied functor's module types to their declarations

_{3f52f6e · cknitt + Claude · Oct 29, 2026, 09:53 UTC}

Codex review on #9084: only a module type's own identifier was mapped to the functor body's, not those inside its signature, so a member reached through the applied module type, such as X.value with X: Applied.S, was missing from the references and renames of S.value. Module type signatures are now walked like those of modules.

Register an inline functor's parameters before applying it

_{3a9e8da · cknitt + Claude · Oct 29, 2026, 10:03 UTC}

Codex review on #9084: an immediately applied inline functor was no longer walked, so its parameters and declarations were missing and O.compare in its body had no definition. The functor is walked again before its application. The results of curried applications now take the body's identifiers from the functor applied first, as the compiler had already renamed those of the inner application.

Locate items of a functor applied from another file in that file

_{86c22e5 · cknitt + Claude · Oct 29, 2026, 10:32 UTC}

Codex review on #9084: Go to Definition on a nested module and Go to Type Definition paired the functor file's locations with the caller's URI. Both now take the URI from the declaration's module path, like value definitions. Fields and constructors of such a functor are found in its file, and its items no longer register locations and references at the same positions of the caller's file.

Refer uses of a functor applied from another file to that file's members

_{54d0b93 · cknitt + Claude · Oct 29, 2026, 10:39 UTC}

A use of a member of a functor applied from another file referred to the caller's copy, so references and renames no longer crossed files as they did when the application resolved to the functor. Such a use refers to the functor's member again, for values, types, fields, constructors and modules, and a signature's nested modules now name their items' paths.

Follow a functor's aliases to its file for the members it creates

_{8001cc1 · cknitt + Claude · Oct 29, 2026, 18:03 UTC}

Review fix: a functor from another file applied through a local alias, such as module Make = AppliedFunctor.MakeSet then Make(IntOrd), kept the alias as the members' source, so Go to Definition and type-definition links pointed into the caller at the functor's line numbers, and uses didn't reach the functor's references and renames. The source is now the path the compiler resolved the alias chain to, through modules too.

Analysis modified (go to definition of an applied member)

module Make = AppliedFunctor.MakeSet
module Aliased = Make(AppliedFunctor.IntOrd)
let a = Aliased.add([], 1)

text · definition of add

-file:///AppliedFunctorUse.res 7:6-7:9
+file:///AppliedFunctor.res 7:6-7:9

Follow a partial functor application to the declarations it renamed

_{2614e3b · cknitt + Claude · Nov 01, 2026, 06:44 UTC}

Review fix: a curried functor applied in separate bindings, such as module First = MakeTwo(IntOrd) then module Final = First(IntOrd), mapped Final's members to the identifiers the compiler gave First's result rather than to the declarations in MakeTwo's body, so Find References and rename missed Final.second from the declaration and the declaration from the use. The compiler's own renaming of each application is now recorded too, a functor reached by a path through another module is matched with that module's type, and each renamed stamp is mapped to the end of its chain once the whole file is read.

Analysis modified (references of a partially applied functor's member)

module MakeTwo = (A: Ord, B: Ord) => {
  let second = (A.compare, B.compare)
}
module First = MakeTwo(IntOrd)
module Final = First(IntOrd)
let fs = Final.second

text · references of second at 1:6

 1:6-1:12
+5:15-5:21

Review

• Why record the compiler's renaming and not only the analysis's? Final's functor position has the identifiers the compiler gave First's result, which no declaration has; only First's application relates them to MakeTwo's body.

Record one renaming step per functor application

_{84aa247 · cknitt + Claude · Nov 01, 2026, 07:10 UTC}

Simplification: the renamed members of an applied functor were linked to the functor body's declarations by three overlapping mechanisms: the body's type found through curried applications, the compiler's renaming, and functor paths resolved after the whole file was read. Each application now records its own steps instead: the analysis's renaming of its type, the compiler's renaming of the functor's result, and, for a functor reached by a path, the copy that path made of the module's type. The chains that end at the declarations are followed once the file is read, as before. Module types are registered when their structure is entered, so the applied functor paths need no list of their own. References, renames and hovers are unchanged.

Share the lookup of a renamed member's original stamp

_{268200f · cknitt + Claude · Nov 01, 2026, 07:11 UTC}

Simplification: Find References repeated the lookup that fields and constructors already used to reach the declaration a renamed member of an applied functor comes from; both now use one helper.

[codecov]

Codecov Report

❌ Patch coverage is 84.94624% with 28 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.79%. Comparing base (8e26a9c) to head (268200f).

Files with missing lines	Patch %	Lines
analysis/src/references.ml	66.66%	14 Missing ⚠️
analysis/src/process_cmt.ml	89.02%	9 Missing ⚠️
analysis/src/process_extra.ml	92.72%	4 Missing ⚠️
analysis/src/shared_types.ml	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9084      +/-   ##
==========================================
+ Coverage   81.74%   81.79%   +0.04%     
==========================================
  Files         460      460              
  Lines       64944    65067     +123     
==========================================
+ Hits        53091    53224     +133     
+ Misses      11853    11843      -10     

Files with missing lines	Coverage Δ
analysis/src/hover.ml	77.63% <100.00%> (+0.14%)	⬆️
analysis/src/markdown.ml	100.00% <100.00%> (ø)
analysis/src/signature_help.ml	80.37% <100.00%> (ø)
analysis/src/shared_types.ml	80.41% <0.00%> (-0.28%)	⬇️
analysis/src/process_extra.ml	87.40% <92.72%> (+0.06%)	⬆️
analysis/src/process_cmt.ml	86.31% <89.02%> (+1.90%)	⬆️
analysis/src/references.ml	70.87% <66.66%> (+2.64%)	⬆️

... and 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript@9084

@rescript/belt

npm i https://pkg.pr.new/@rescript/belt@9084

@rescript/darwin-arm64

npm i https://pkg.pr.new/@rescript/darwin-arm64@9084

@rescript/linux-arm64

npm i https://pkg.pr.new/@rescript/linux-arm64@9084

@rescript/linux-x64

npm i https://pkg.pr.new/@rescript/linux-x64@9084

@rescript/runtime

npm i https://pkg.pr.new/@rescript/runtime@9084

@rescript/win32-x64

npm i https://pkg.pr.new/@rescript/win32-x64@9084

commit: 268200f

[github-actions]

Developer playground preview: https://rescript-lang.github.io/rescript/dev-playground/?version=pr-9084

[cknitt]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-01T07:54:46.884572Z	268200f	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eeb4965510

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cknitt]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c4cc7a1a84

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cknitt]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5ca5862e19

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cknitt]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ec52147ce9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cknitt]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c989f879df

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ff8f5bef7b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cknitt]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 268200f11d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Follow partial applications when resolving source provenance

When an external curried functor is applied in separate bindings, such as module First = Other.MakeTwo(IntOrd) followed by module Final = First(IntOrd), this records the local First path as Final's source. Resolve_path.get_source_uri resolves that path to a local stamp and returns the caller's URI without following First's application provenance, although Final's declaration locations still belong to Other.res. Consequently, Go to Definition and hover's type-definition links for Final's members target unrelated positions in the caller. The new stamp-chain handling covers local reference identity, but source resolution also needs to follow named partial applications back to their defining file.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Retain individual included members' source provenance

For a local functor that includes another file, for example module F = () => { include Other } followed by module M = F(), materializing the result signature replaces the included members' provenance with IncludedModule(F, ...). Their locations still point into Other.res, but References.definition now obtains the current file's URI from F, so Go to Definition on M.value jumps into the wrong file. Previously, following F's body retained the IncludedModule(Other, ...) metadata established by the Tstr_include branch. Preserve per-member include provenance when constructing the specialized signature rather than attributing every result item to the functor's file.

Useful? React with 👍 / 👎.