Fix overly-wide exception catches in the display/typing pipeline

[Copilot]

Generic | _ -> catch patterns throughout the display/typing pipeline were silently swallowing control-flow exceptions like Globals.Cancelled (cooperative server cancellation) and DisplayJson.JsonCompleted (JSON-RPC response sent signal), preventing them from bubbling up to the compilation entry point as required.

Critical fix

• compiler.ml compile_safe: Globals.Cancelled was absent from the re-raise list, so a cancelled server compilation in production mode would be silently converted into a spurious error message instead of propagating to run_request's Cancelled handler.

Display/typing path fixes

Each broad | _ -> catch-all is replaced with an enumeration of only the specific compilation-error exception types that the try block is legitimately expected to raise. Any exception not in the enumerated list — including Globals.Cancelled, DisplayJson.JsonCompleted, and any future control-flow exceptions — naturally bubbles up to the appropriate handler.

• displayProcessing.ml load_display_module_in_macro — catches Error.Fatal_error _ | Error.Error _ | Failure _ | Not_found | Lexer.Error _ | Parser.Error _ | Typecore.Forbid_package _ | Typecore.WithTypeError _
• macroContext.ml — both parse_metadata functions narrowed to Lexer.Error _ | Failure _ (only exceptions that can escape the ParseError branch)
• displayToplevel.ml — maybe_resolve_macro_field and the removed-files parse loop
• display.ml — get_import_status catches Not_found | Error.Fatal_error _ | Error.Error _ | Failure _
• typerDisplay.ml — retype helper and the constructor-filter predicate catch typing error exceptions
• syntaxExplorer.ml — explore_uncached_modules module load loop
• commonCache.ml — native lib build task
• displayPath.ml — complete_type_path_inner
• displayFields.ml — all three broad catches in handle_missing_field_raise

Pattern used

(* Before *)
with _ ->
    fallback_value

(* After — enumerate only the expected compilation-error exceptions *)
with Error.Fatal_error _ | Error.Error _ | Failure _ | Not_found
| Lexer.Error _ | Parser.Error _ | Typecore.Forbid_package _ ->
    fallback_value

This approach is robust against future additions: any new control-flow exception will automatically bubble up without requiring per-exception patches at each catch site.

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[Simn]

@copilot Please update the branch, there is a conflict now.

But also, while this might be a good ad-hoc fix, it doesn't actually address the underlying problem. What we should really investigate is why these catch-all sites exist in the first place and if they should be restructured to either cover less ground or catch more specific exceptions. Otherwise we'll have the same issue with the next "global" exception that we want to bubble up.

[Copilot]

@copilot Please update the branch, there is a conflict now.

But also, while this might be a good ad-hoc fix, it doesn't actually address the underlying problem. What we should rea...

Resolved the conflict and addressed the underlying concern in 7e4d39b.

Instead of ad-hocly re-raising Globals.Cancelled from generic | _ -> catch-alls, each site now enumerates only the specific compilation-error exception types it legitimately expects:

• Module-load sites catch: Error.Fatal_error _ | Error.Error _ | Failure _ | Not_found | Lexer.Error _ | Parser.Error _ | Typecore.Forbid_package _ | Typecore.WithTypeError _
• Type-inference sites catch: Error.Fatal_error _ | Error.Error _ | Typecore.Forbid_package _ | Failure _
• parse_metadata narrowed to: Lexer.Error _ | Failure _

With specific catches, any exception not in the list — including Globals.Cancelled, DisplayJson.JsonCompleted, and any future control-flow exceptions — naturally bubbles up without needing per-exception holes.

[Simn]

@copilot Somehow there's still a conflict and you've made a branching mess. See that your changes are based on 517a97a, which is the latest commit on development.

[Copilot]

@copilot Somehow there's still a conflict and you've made a branching mess. See that your changes are based on 517a97a, which is the latest commit on...

Resolved in 18b891e. The branch is now a single commit directly on top of 517a97a — no merge commits, no divergence. The force-pushed branch should no longer show a conflict in the PR view.

[Simn]

Oh man I'll have to carefully review this. But I do think it's worthwhile because the catches can be VERY confusing in some cases.