Closed ecstatic-morse closed 2 years ago
The primary motivation for [[]]
is to hack around rustfmt suboptimal formatting. With one set of brackets, it adds two extra newlines per expect macro.
The primary motivation for
[[]]
is to hack around rustfmt suboptimal formatting. With one set of brackets, it adds two extra newlines per expect macro.
Ah, I didn't think of that. Worth noting that this isn't true for single-line expects, for which the terser syntax is most impactful.
Yeah, so let's do this:
expect![[r#"foo"#]]
, and we update this to bar
, we don't take the original form into account and use expect!["bar"]
. Not that this is for the cases where we do update. If the test passes, it should pass with whatever flavor of delimiters. do not preserve user spelling. Ie, if the user writes
expect![[r#"foo"#]]
, and we update this tobar
, we don't take the original form into account and useexpect!["bar"]
. Not that this is for the cases where we do update. If the test passes, it should pass with whatever flavor of delimiters.
This is implemented now (it requires #28). It does add some complexity, however. Let me know what you think.
Ping @matklad, in case this got lost during the holidays. Seems like chalk
will start using expect-test
soon-ish, and some form of this would be nice to have.
Sorry, this felt through the cracks, it looks good to me now!
bors r+
Pairs of braces are no longer necessary that we parse string literals. Allow users to omit the inner
[]
.This represents a significant change to the public API, and you might have other tooling that depends on the paired braces, so I understand if you don't want it upstream. I think it reads a bit nicer, though.
Depends on #26 (although it could be separated), and is similarly lacking in integration tests for now.