Attach DebuggableAttribute to FSI multi-emit manifests under --debug+#19921
Attach DebuggableAttribute to FSI multi-emit manifests under --debug+#19921T-Gro wants to merge 4 commits into
Conversation
…buggableAttribute (#14572) Phase 1 (RED) of TDD for issue #14572. Adds four xUnit Facts under Scripting.MultiEmit.DebuggableAttributeManifest that reflect on Assembly.GetExecutingAssembly() inside an FSI submission to inspect the manifest-level DebuggableAttribute that the multi-emit code path is expected to attach when --debug+ is in effect. On current main: * multi-emit submission with --debug+ has DebuggableAttribute with DisableOptimizations -> FAILS (manifest has no DebuggableAttribute) * multi-emit submission with --debug- has no DebuggableAttribute -> passes (negative control) * single-emit submission with --debug+ keeps DebuggableAttribute (regression) -> passes (uses --optimize- to exercise the ilreflect.fs codepath that gates on optimize=false) * multi-emit + --debug+ does not duplicate user-declared DebuggableAttribute -> FAILS (no attribute attached at all yet) The production fix lives in a separate sprint; no source files under src/ are touched here. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…#14572) When FSI is configured for multi-assembly emit (--multiemit+) the per-submission dynamic assembly's manifest now carries System.Diagnostics.DebuggableAttribute with DisableOptimizations|Default whenever --debug is enabled, matching the single-emit path (ilreflect.fs) and the regular compiler (CreateILModule.fs). Dedups against a user-declared assembly DebuggableAttribute. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
❗ Release notes requiredYou can open this PR in browser to add release notes: open in github.dev
|
github-actions
Bot
added
the
AI-Tooling-Check-Bypassed
| [ | ||
| tcGlobals.MakeInternalsVisibleToAttribute(dynamicCcuName tcConfigB.fsiMultiAssemblyEmit) | ||
| if generateDebugInfo && not hasUserDebuggableAttr then | ||
| tcGlobals.mkDebuggableAttributeV2 (tcConfigB.jitTracking, true) |
There was a problem hiding this comment.
This gates on --debug and always passes jitOptimizerDisabled = true, which doesn''t match either path cited as the reference. Single-emit (ilreflect.fs) gates on not LocalOptimizationsEnabled, and the batch compiler (CreateILModule.fs) passes not JitOptimizationsEnabled rather than a hardcoded true. As a result --multiemit+ --debug+ --optimize+ disables JIT optimizations here but not in the batch compiler, and --multiemit+ --optimize- --debug- attaches nothing here but does in single-emit. Is the debug-based gating with unconditional DisableOptimizations the intended semantics?
| ) | ||
|
|
||
| [<Fact>] | ||
| let ``multi-emit + --debug+ does not duplicate user-declared DebuggableAttribute`` () = |
There was a problem hiding this comment.
In --multiemit+ each Eval is a separate assembly. The user-declared attribute lands on the first submission''s assembly, but the reflection helper runs in a later submission and inspects that assembly via GetExecutingAssembly(), which never carried a user attribute. So flags.Length = 1 holds even with the hasUserDebuggableAttr guard removed — the test passes without exercising the dedup path it''s named for.
github-project-automation
Bot
moved this from New
to In Progress
in F# Compiler and Tooling
2 participants
Fixes #14572
--multiemit+submissions now getDebuggableAttribute(DisableOptimizations|Default)ontheir manifest when
--debug+is set, matching single-emit and batch-compiler behavior.