Apply T! macro where posible

[pasa]

apply T! macro implemented in #1248

[matklad]

Awesome!

This looks so much better now! Let's remove braces from the PR though: T!['}'] does not look exactly right

[matklad]

Hm, interesting, I've missed that while reviewing the original PR.

Indeed, we need quotes here, because { break token tree structure. The API looks to sigil heavy as a result though.

Let's maybe scale this back, remove support for {, }, (, ), [, ] from T and stick with L_CURLY and friends?

[matklad]

Hm, OTOH, T!['{'] is inline with how various parser generators handle things.

Let's just merge this, we can always revert to L_CURLY later :D

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[jens1o]

I've got the feeling that this increases compile time a lot. Is this known?

[matklad]

Hm, no, I haven't check it, will run some benchmarks, thanks for the report.

If you have already measured the impact of this change on compile time, I'd be interested in seeing the results!

We might also look at the travis build times I guess.

[matklad]

Hm, I've checked locally, and compile time seems the same.

Specififivally, I've check f711237
and 64ab5ab by

repeateadly running

$ find ./target/debug -type f -maxdepth 1 -delete && rm -fr ./target/debug/{deps,.fingerprint}/{*ra_*,*test*,*tools*,*gen_lsp*,*thread_worker*}
$ cargo check

and

$ find ./target/debug -type f -maxdepth 1 -delete && rm -fr ./target/debug/{deps,.fingerprint}/{*ra_*,*test*,*tools*,*gen_lsp*,*thread_worker*}
$ cargo test --no-run

in both cases compile itme was more or less the same for both commits

@jens1o could you give a little more details about where you are observing longer compile times?

[jens1o]

I digged a little bit further. At some point yesterday, I just quit compiling(I guessed that all the macro resolving took that much time). I now let it run for some while, only to notice that ra_ide_api results into overflow evaluating the requirement (something with salsa). Might be like rust-lang/rust#47032? I do not know how to get rid of it, though. :/ When it really overflows, then this might be the reason why it takes sooo long.

[matklad]

Hm, whihc version of rustc are you using?

[matklad]

I think this is the same as #1283: on the latest nightly I also get a very long compile time + overflow at the end.

[jens1o]

Ah, yes it is! Thank you very much and pardon me!

[matklad]

Thanks for the report! Tacking that overflowing error is important: it has been my main gripe with rustc since all hands :D