-
Notifications
You must be signed in to change notification settings - Fork 63
fail: does not fail, when first statement in block doesn't fail #160
Comments
Looking at the code for fail, it seems that indeed fail assumes that all statements inside the blog must fail. Idk, maybe this is behaving according to specs? |
A work around was found. Adding all the statements in a single line will do the trick. This one works: ```tut:fail This one does not: ```tut:fail |
I just got this bug on my project. Is there any plan to work on this issue? I may be able to help if the fix is not too difficult. |
I'm not sure how useful this is because if it meant "at least one thing must fail" then a failure in another line you expected to succeed would no longer trigger an error. It might make more sense to figure out how to merge adjacent code blocks so you could mix and match different options. |
Yes, merging adjacent code blocks would be even better! I only want to have a failing and a correct statement on the same block for aesthetic purposes. I can see how having the possibility to define different options per line would improve the structure of my documentation pages, too. Do you think that would be easy to implement? |
tut is really crufty already so I'm not sure how hard it would be. Probably irritating but certainly not impossible. It may be easier to do in a second pass over the output files. |
As a temporary workaround, you can also wrap the entire shed in a block.
|
This should fail, but it doesn't (meaning the build fails because tut finds the code to be ok, whereas we say that it should fail):
```tut:fail
case class X(i: Int)
valx=2;
```
Now this is good, the build passes because we say it should fail and it actually fails:
```tut:fail
valx=2;
```
Tried all version from 0.4.2 to 0.4.8 and they all behave the same. I didn't try any of the newer 0.5.0 series. Maybe I should? :/
The text was updated successfully, but these errors were encountered: