Given the following:

  ty-exp0 := <type-task(|ctx)> exp0;
  cty-exp0 := <type-task-coerce(|ctx)> (ty-exp0, |[ Bool ]|);
  check1 := <type-match(type-boolean-is|ctx)> cty-exp0;
  <task-create-error-on-failure(|ctx, check1, <ERR_UNOP_UNAPPLICABLE(|ctx, "?", ty-exp0)>)> exp0

The error task does not execute even if check1 fails. Check1 is a Rewrite task. If i rewrite the code above to:

  ty-exp0 := <type-task(|ctx)> exp0;
  cty-exp0 := <type-task-coerce(|ctx)> (ty-exp0, |[ Bool ]|);
  check1 := <type-match(|ctx, |[ Bool ]|)> cty-exp0;
  <task-create-error-on-failure(|ctx, check1, <ERR_UNOP_UNAPPLICABLE(|ctx, "?", ty-exp0)>)> exp0

Then it starts working.

In both of the examples above tasks cty-exp0, check1 actually fail (by design).

Submitted by Vlad Vergu on 10 December 2013 at 10:42

On 10 December 2013 at 11:22 Guido Wachsmuth commented:

Is the error task actually created in both variants?
And is type-match(s|ctx) your own creation?


On 10 December 2013 at 11:28 Vlad Vergu commented:

Yes, and yes. <type-match(s|ctx)> t will produce t iff <s> t succeeds during task evaluation.


On 10 December 2013 at 11:46 Guido Wachsmuth commented:

To understand this better, can you please

  1. use both variants in parallel,
  2. provide the task IDs for ty-exp0, cry-exp0, check1 in both variants, and the error task in both variants,
  3. provide the results of task check1 in both variants (which should be failure, I assume),
  4. provide the stored dependencies of check1 in both variants and the error task in both variants.

On 10 December 2013 at 11:48 Gabriël Konat commented:

It’s an issue with the dependency failure propagation, I am looking into it.


On 10 December 2013 at 15:44 Gabriël Konat commented:

Seems like it is not possible to automatically detect whether to show a message by looking at dependency failure. I added message factories where you can explicitly specify which tasks will cause the message not to show when those tasks fails in https://github.com/metaborg/runtime-libraries/commit/e9abc12f8b7f39b0dc7c4743830afcf6a50aa7ce.


On 13 December 2013 at 11:47 Gabriël Konat closed this issue.

Log in to post comments