Unmatched specification in opaque signature ascription causes uncaught exception

[zbyrn]

Version

110.99.4 (Latest)

Operating System

• Any
• Linux
• macOS
• Windows
• Other Unix

OS Version

MacOS Sonoma

Processor

• Any
• Arm (using Rosetta)
• PowerPC
• Sparc
• x86 (32-bit)
• x86-64 (64-bit)
• Other

System Component

Core system

Severity

Minor

Description

If a structure fails to match the signature, the core system crashes with an uncaught exception Bind. This behavior only happens when the structure uses opaque ascription :> but not :.

Transcript

[test.sml]:

structure A :> sig
  val nonexistent: int
end = struct
end

$ sml test.sml 
Standard ML of New Jersey (64-bit) v110.99.4 [built: Tue Aug 01 16:07:38 2023]
[opening test.sml]
test.sml:1.2-4.4 Error: unmatched value specification: nonexistent

uncaught exception Bind [nonexhaustive binding failure]
  raised at: ../compiler/Elaborator/elaborate/elabmod.sml:624.13-624.67
             ../compiler/Elaborator/elaborate/elabmod.sml:1363.32
             ../compiler/Basics/stats/stats.sml:198.40
             ../compiler/TopLevel/interact/evalloop.sml:45.54
             ../compiler/TopLevel/interact/evalloop.sml:306.20-306.23

Or directly in the command line:

$ sml
Standard ML of New Jersey (64-bit) v110.99.4 [built: Tue Aug 01 16:07:38 2023]
- structure A :> sig val nonexistent : int end = struct end;
stdIn:1.2-1.59 Error: unmatched value specification: nonexistent

unexpected exception (bug?) in SML/NJ: Bind [nonexhaustive binding failure]
  raised at: ../compiler/Elaborator/elaborate/elabmod.sml:624.13-624.67
             ../compiler/Elaborator/elaborate/elabmod.sml:1363.32
             ../compiler/Basics/stats/stats.sml:198.40
             ../compiler/TopLevel/interact/evalloop.sml:45.54

Expected Behavior

The system should report the error and continue.

Steps to Reproduce

- structure A :> sig val nonexistent : int end = struct end;

Additional Information

No response

Email address

byronzhong@cs.uchicago.edu

[zbyrn]

After bisecting, I can locate the first commit that introduces this bug is 9c7dd2b, which is bizarre since the only change in that commit is the version number. I suspect that this might be related to bootstrapping.

For reference, this is the script that I passed to git bisect run:

rm -rf boot.amd64-unix.tgz bin lib && config/install.sh > /dev/null 2> /dev/null
if [[ ! -f "bin/sml" ]]; then
  exit 125 # skip this commit
fi

if bin/sml test.sml | grep -q "Bind"; then
  exit 1
else
  exit 0
fi

[dmacqueen]

The cause of the Bind exception is in the function constrStr (being renamed to "constrainStr") in Elaborator/elaborate/elabmod.sml. This function depends on the behavior of the matchStr function in Elaborator/modules/sigmatch.sml. The matchStr function is being changed so that it returns an option (instead of a "bogus" record), which will be NONE if the signature match fails. Then the constrainStr function will also return NONE when the signature match fails, and calls of constrainStr in elabmod.sml have to modified to deal with this change. Also, when matchStr fails we need to ensure that anyErrors is set to true to make sure that compilation beyond the elaboration phase will be blocked. This work is partially done but still needs some debugging -- it involves nontrivial changes in both sigmatch.sml and elabmod.sml.

This bug is a typical case of what can go wrong in the error handling logic, where through much of the elaboration phase errors are not immediately fatal, but it is arranged for the elaboration to continue (and perhaps discover and report further errors) after an error by returning "harmless" dummy values (e.g. ERRORty) at the point where an error is detected, where these dummy values are designed to allow the elaborator to "stumble on". But the elaboration-time errors should set the anyErrors flag to true, which cuts off compilation phases after elaboration.

[dmacqueen]

This issue is duplicated by Issue #289. See the comment there about a simple fix that unfortunately has a mysterious side effect that prevents legacy from bootstrapping.

[dmacqueen]

"Fixed" in 110.99.5. See closing comment for Issue #298, which is a related problem.