aboutsummaryrefslogtreecommitdiffstats
path: root/lib/parsetools/src/Makefile
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2013-01-18 14:34:08 +0100
committerBjörn Gustavsson <[email protected]>2013-01-18 16:51:08 +0100
commit67195b2a1dddf1ec2590e1404b552188893d4473 (patch)
tree6aa43b9eed7666f5740bb9ffdb6c091d1c578294 /lib/parsetools/src/Makefile
parent2bd44c7f5462bbfaaf38eed6f708bf01b0c97469 (diff)
downloadotp-67195b2a1dddf1ec2590e1404b552188893d4473.tar.gz
otp-67195b2a1dddf1ec2590e1404b552188893d4473.tar.bz2
otp-67195b2a1dddf1ec2590e1404b552188893d4473.zip
compiler: Eliminate internal consistency failure in binary matching
The following code: check(<<"string">>, a1) -> one; check(_, a2) -> two; check(undefined, a3) -> three. produces an internal consistency failure: check: function check/2+17: Internal consistency check failed - please report this bug. Instruction: {test,is_eq_exact,{f,7},[{x,0},{atom,undefined}]} Error: {match_context,{x,0}}: Actually, in the current implementation of the run-time system, comparing a match context to an atom is safe, so I briefly considered updating the beam_validator to let this code pass through. I abandoned that approach because not all terms would be safe to compare to a match context, and the implementation might change in the future. Therefore, fix this problem by not allowing any matching of non-variables (in the argument position for binary being matched) following binary matching. That solution is simple and safe, and since this kind of code seems to be rare in practice, there is no need to pursue any more compilicated solution. Reported-by: Viktor Sovietov
Diffstat (limited to 'lib/parsetools/src/Makefile')
0 files changed, 0 insertions, 0 deletions