2020-04-01 10:13 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000496mercuryBugpublic2020-02-05 11:45
Reporterjuliensf 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusassignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000496: Determinism error in 20.01 for code that compiles successfully in 14.01.1
DescriptionThe attached predicate compiles successfully with Mercury 14.01.1 but
gets a determinism error with 20.01. (It also compiles successfully with
rotd-2018-05-10.)
TagsNo tags attached.
Attached Files
  • ? file icon bug496.m (1,807 bytes) 2020-02-05 10:20

-Relationships
+Relationships

-Notes

~0001074

zs (developer)

The cause of this bug is the fix for another bug: github 64.
That fix did come with an announcement that reqressions like this
would happen.

I also think this bug is probably a duplicate of Mantis bug 480.

The problem is that the code that constructs the final value of !:Actions
gives it an inst that contains unique components (specifically, the constants
action_canonicalise and action_split). In the presence of insts containing unique
components, cse_detection.m refuses to automatically transform the switch
on AllActions to the commented-out version, which directly leads to the bug.

As mentioned in the discussion of bug 480, fixing this properly is hard.
I can see a possible band-aid solution that *could* fix this and similar instances,
though of course not all others. This would involve changing the test in
cse_detection.m from "does the inst of the variant concerned (AllActions) include
any unique components" to "does it contains any unique components on
non-constants" (since constants do not have cells on the heap). The "could"
part above is because I am pretty sure this change would revive github bug 64,
but don't know whether fixing that in the constants-only case is possible.

Even if it didn't, it would have the downside that it would make the rules
followed by determinism analysis (when viewed from a user's point of view,
and so including cse) more complex still.

Who thinks this tradeoff is worth making?

~0001075

juliensf (administrator)

I don't think the tradeoff is worth making; it's going to make an already complicated situation even more complicated.

Question: how feasible is it to detect the above situation and make the error message suggest the refactoring?

~0001076

zs (developer)

It should be easy to

- have cse record, in the proc_info the fact that it declined to pull a common unification
  out of a disjunction due to uniqueness concerns, and

- have determinism analysis look at this flag, and if set, and there are determinism errors,
  print a message about this fact being a possible cause of the errors.

What I am not sure about is whether we can give this message a useful context,
for two reasons. One: by definition, a common deconstruction involves at least
two contexts, maybe more, and listing them all probably wouldn't be useful.
We can probably use the smallest context (i.e. the one with the smallest
line number). Two, when cse pulls a deconstruction unification out of the arms
of a disjunction, the pulled-out unification does not come from any one place,
so there is no one "right" context it can record for it. Again, we can probably
use the smallest context among the pulled-out unifications. This would then
be a context we could report if there is a problem in the *next* invocation
of cse on that procedure body. But given the approximations above, I am not sure
whether the context they would yield would useful in the common cases.

However, given that the pointer to the cause of the error would be useful
even without a specific context, I will implement it.
+Notes

-Issue History
Date Modified Username Field Change
2020-02-05 10:20 juliensf New Issue
2020-02-05 10:20 juliensf File Added: bug496.m
2020-02-05 11:01 juliensf Summary Determinism error in 20.01 for code that complies successfully in 14.01.1 => Determinism error in 20.01 for code that compiles successfully in 14.01.1
2020-02-05 11:04 zs Note Added: 0001074
2020-02-05 11:25 juliensf Note Added: 0001075
2020-02-05 11:45 zs Note Added: 0001076
2020-02-05 11:45 zs Assigned To => zs
2020-02-05 11:45 zs Status new => assigned
+Issue History