Spec: Parse `a.b {|(*)|}`. #2094

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
@Peeja

Peeja commented Dec 9, 2012

Implementing this should fix #2073.

I'm not sure if the example name is a good one. It's not clear to me
yet why someone would want to put parentheses around the *. It should
just get Ruby to unpack the argument before it throws it away.

Also, what's interesting about getting it to pass isn't so much its
behavior (which should match the un-parenthesesed version) as the fact
that it parses.

@dbussink

This comment has been minimized.

Show comment Hide comment
@dbussink

dbussink Dec 10, 2012

Owner

If you add specs in a pull request without fixing the issue, you should also add tags for the spec in a separate commit. Also see: http://rubyspec.org/mspec-tag/

Owner

dbussink commented Dec 10, 2012

If you add specs in a pull request without fixing the issue, you should also add tags for the spec in a separate commit. Also see: http://rubyspec.org/mspec-tag/

@Peeja

This comment has been minimized.

Show comment Hide comment
@Peeja

Peeja Dec 10, 2012

Thanks, @dbussink. I really don't understand how tags work, and that page just explains how to manipulate them using the mspec-tag command. Is there an overview of what they're for and what they mean?

Peeja commented Dec 10, 2012

Thanks, @dbussink. I really don't understand how tags work, and that page just explains how to manipulate them using the mspec-tag command. Is there an overview of what they're for and what they mean?

@dbussink

This comment has been minimized.

Show comment Hide comment
@dbussink

dbussink Dec 10, 2012

Owner

We tag specs that fail at the moment. This gives us a way to track what still needs to be fixed. We also use this to keep our continuous integration green, so we can catch regressions. So if we add specs that fail, we need to either fix the bug or add a tag for it so we explicitly say that it still, but don't want the build to fail because of it.

Owner

dbussink commented Dec 10, 2012

We tag specs that fail at the moment. This gives us a way to track what still needs to be fixed. We also use this to keep our continuous integration green, so we can catch regressions. So if we add specs that fail, we need to either fix the bug or add a tag for it so we explicitly say that it still, but don't want the build to fail because of it.

@Peeja

This comment has been minimized.

Show comment Hide comment
@Peeja

Peeja Dec 10, 2012

Got it. So if I tag it as --fail, it'll pass CI, because it's expected to fail, yes?

This commit adds one example to a rather large spec; won't tagging it make the whole spec stop running until it's implemented?

Peeja commented Dec 10, 2012

Got it. So if I tag it as --fail, it'll pass CI, because it's expected to fail, yes?

This commit adds one example to a rather large spec; won't tagging it make the whole spec stop running until it's implemented?

@dbussink

This comment has been minimized.

Show comment Hide comment
@dbussink

dbussink Dec 10, 2012

Owner

Tags work on the level of it {} blocks, so the other ones will keep running fine. --fail is also the default for mspec tag, so no need to specify it.

Owner

dbussink commented Dec 10, 2012

Tags work on the level of it {} blocks, so the other ones will keep running fine. --fail is also the default for mspec tag, so no need to specify it.

@Peeja

This comment has been minimized.

Show comment Hide comment
@Peeja

Peeja Dec 10, 2012

Ah. So. Problem.

The error is not at run time, but at compile time. That means that the error throws too early, none of the actual tests run, and (among other things) the tag can't be set.

One solution would be to put the code in an #eval to put the compilation into the context of the example. But is there in fact a better place for parser specs? I couldn't find one, but I may not have looked hard enough.

Peeja commented Dec 10, 2012

Ah. So. Problem.

The error is not at run time, but at compile time. That means that the error throws too early, none of the actual tests run, and (among other things) the tag can't be set.

One solution would be to put the code in an #eval to put the compilation into the context of the example. But is there in fact a better place for parser specs? I couldn't find one, but I may not have looked hard enough.

@dbussink dbussink closed this in 2ab0d14 Jul 29, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment