Skip to content

Fix stale diagnostics replayed after error is resolved#12863

Draft
Copilot wants to merge 3 commits intodevelopmentfrom
copilot/fix-old-diagnostics-errors
Draft

Fix stale diagnostics replayed after error is resolved#12863
Copilot wants to merge 3 commits intodevelopmentfrom
copilot/fix-old-diagnostics-errors

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Mar 24, 2026

DKMissingFields and similar diagnostics persisted across compilations even after the underlying error was fixed, and accumulated ("stacked") with each re-run.

Root cause

add_module_diagnostic and module_warning unconditionally wrote to m.m_extra.m_cache_bound_objects. For modules loaded from the HXB binary cache (e.g. stdlib Int/StdTypes), this DynArray is shared by reference with the binary cache entry — so each diagnostics run permanently mutated the cache. handle_cache_bound_objects then replayed all accumulated stale messages on every subsequent compilation.

The key offender: displayFields.ml handle_missing_field_raise calls add_module_diagnostic with the target type's module (e.g. StdTypes for Int), while the message position is in the calling file. This embeds a usage-site diagnostic into a stdlib module's cache where it never belongs.

Changes

  • add_module_diagnostic — only writes to m_cache_bound_objects when the message position's file matches the module's own file (msg_fkey = mod_fkey). This cleanly separates intrinsic module diagnostics (e.g. interface-compliance MissingFields on c.cl_module, where c.cl_name_pos is in the module's file) from usage-site diagnostics (field-access errors whose position is in the calling file, not the target type's file).

  • module_warning — only writes to m_cache_bound_objects when m.m_extra.m_processed = 0, i.e. the module is freshly typed this compilation. Cached HXB modules have m_processed = old_step > 0 (stored via save_class_state + add_binary_cache in a prior compilation), so their shared DynArray is never mutated.

Example

function main() {
    var v = "";
    // Uncommenting the next line caused a DKMissingFields diagnostic that
    // persisted (and stacked) even after re-commenting it:
    // var v = 0;
    final char = v.charAt(0);
}

After this fix, handle_missing_field_raise no longer pollutes Int's cached m_cache_bound_objects, so the diagnostic is cleared as soon as the error is gone.

Original prompt

This section details on the original issue you should resolve

<issue_title>Old diagnostics errors are not cleared</issue_title>
<issue_description>```haxe
function main() {
var v = "";
// uncomment and comment this line:
// var v = 0;
final char = v.charAt(0);
}


Impressive regression in https://github.com/HaxeFoundation/haxe/pull/12815

</issue_description>

<agent_instructions>Please check this!</agent_instructions>

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

<comments>
<comment_new><author>@Simn</author><body>
I can't seem to get diagnostics anymore at all, as in vshaxe isn't sending any requests for them.</body></comment_new>
</comments>


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Copilot AI and others added 2 commits March 24, 2026 15:06
add_module_diagnostic now only caches the message in m_cache_bound_objects
when the message position is in the same file as the module. This prevents
the shared m_cache_bound_objects DynArray (between a module loaded from the
HXB binary cache and the cache entry itself) from being mutated by display
diagnostics whose position is in a different file (e.g. a field-access
diagnostic generated for Int's module when the access is in the user's file).

Also add the m_processed=0 guard to module_warning to prevent the same
shared-DynArray pollution for cached modules.

Adds regression test Issue12861.

Co-authored-by: Simn <634365+Simn@users.noreply.github.com>
Agent-Logs-Url: https://github.com/HaxeFoundation/haxe/sessions/cada24b6-2ee7-42e2-b413-637d30bd2312
Copilot AI changed the title [WIP] Fix old diagnostics errors not cleared Fix stale diagnostics replayed after error is resolved Mar 24, 2026
Copilot AI requested a review from Simn March 24, 2026 15:09
Copilot finished work on behalf of Simn March 24, 2026 15:09
@Simn
Copy link
Copy Markdown
Member

Simn commented Mar 24, 2026

The common.ml change makes sense, though I'm not sure if m_processed is the canonical way to check this.

The other part sounds like something else is wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Old diagnostics errors are not cleared

2 participants