Stream: t-compiler/wg-rls-2.0

Topic: Additional Test Runnables


David Barsky (Sep 05 2019 at 16:46, on Zulip):

Hiya! I wanted to ask a slightly uninformed question. I was interested in adding support for macros like tokio::test/runtime::test to the runnables in https://github.com/rust-analyzer/rust-analyzer/blob/7d72ca80003b7915ed7fc64907b5b6dc5c88dacd/crates/ra_ide_api/src/runnables.rs#L39 as part of the "test" runnables, but I'm not sure if I should send a PR for that _or_ wait for proc macro expansion with a mechanism similar to https://github.com/rust-analyzer/rust-analyzer/issues/688#issuecomment-504171869

matklad (Sep 05 2019 at 16:46, on Zulip):

We don't have any support for proc macros yet, so doing this properly has a pretty large and hairy yak attached. However I'd be fine with just hard-coding tokio::test or runtime::test

David Barsky (Sep 05 2019 at 17:00, on Zulip):

Gotcha, sounds good! I might send subsequent PRs for proptest once https://github.com/AltSysrq/proptest/pull/166 lands

matklad (Sep 05 2019 at 17:03, on Zulip):

FYI, I am cosidering switching rust-analyzer itself from proptest to quickcheck :)

matklad (Sep 05 2019 at 17:03, on Zulip):
$ cargo bloat --time
29.57s ra_ide_api
27.23s ra_hir
16.94s proptest  :(
16.35s syn
14.24s clap
12.85s syn
David Barsky (Sep 05 2019 at 17:26, on Zulip):

I did see that! I'm not the biggest fan of the Arbitrary typeclass and I like Hypothesis/Hedgehog-style generators more :)

David Barsky (Sep 05 2019 at 17:27, on Zulip):

unrelated, if I wanted to share my syntax highlighting config—e.g., for Night Owl—should I open an issue for that? Could be handy to have a shared repo of highlighed syntax colors!

matklad (Sep 05 2019 at 17:28, on Zulip):

Yeah, I also love hypothesis, but I feel that such compile time is excessive, especially given that proptest ends up as a [dependency] and not a [dev-dependency]

matklad (Sep 05 2019 at 17:28, on Zulip):

what is Night Owl? A theme for VS Code?

matklad (Sep 05 2019 at 17:29, on Zulip):

It might be a good idea to make a shared repo, yeah, but probably outside of rust-analyzer's main repo

matklad (Sep 05 2019 at 17:30, on Zulip):

I'd contribute the One True Theme: Emacs-flawored zenburn: https://github.com/matklad/config/blob/f49c2a52122550006cd81bda2221426ad869e3ba/vscode/settings.json#L96-L177 :D

David Barsky (Sep 05 2019 at 17:31, on Zulip):

Yep! One that I'm pretty happy with. https://github.com/sdras/night-owl-vscode-theme

David Barsky (Sep 05 2019 at 17:32, on Zulip):

Outside, for sure. feel free to make a repo, I can send a PR with the config!

lqd (Sep 05 2019 at 17:32, on Zulip):

remove the duplicated syn, switch from clap to pico-args, keep proptest ;)

matklad (Sep 05 2019 at 17:36, on Zulip):

To remove duplicated syn, I think we should poke @David Barsky to release failure 0.1 with upgraded syn :-)

Bumping MSRV in non-semver breaking way can be ok: lazy_static recently bumped from 1.24 to 1.27. Bumping to 1.31 is more questionable though.

matklad (Sep 05 2019 at 17:37, on Zulip):

@lqd switching to pico-args is genuinely great idea: https://github.com/rust-analyzer/rust-analyzer/issues/1768

lqd (Sep 05 2019 at 17:40, on Zulip):

it's a little more verbose than clap/structopt for sure, but the 20s+ reduction on compile times (in release) seemed worth it

David Barsky (Sep 05 2019 at 17:51, on Zulip):

@matklad Funny enough, I can't actually _publish_ changes—I can only merge them :)

David Barsky (Sep 05 2019 at 17:52, on Zulip):

To make sure I'm on the same page—bumping failure's syn/quote dependency to 1.0 is okay _even if_ the MSRV goes up to 1.31?

matklad (Sep 05 2019 at 17:55, on Zulip):

So, there are different opinions about this, but, it's fair to say that this is not outright wrong

matklad (Sep 05 2019 at 17:56, on Zulip):

For example, this PR bumps MSRV of lazy_static while staying semver compatible https://github.com/rust-lang-nursery/lazy-static.rs/pull/156

matklad (Sep 05 2019 at 17:56, on Zulip):

regex policy also allows bumping regex without making a breaking release: https://github.com/rust-lang/regex#minimum-rust-version-policy

David Barsky (Sep 05 2019 at 18:00, on Zulip):

hmm, good to know. i'm sorry about my conservatism here—I don't want to make any dumb mistakes here :)

matklad (Sep 05 2019 at 18:00, on Zulip):

So I'd say it's definitely OK to bump MSRV to "at least two year old Rust", and it's definitelly not OK to bump MSRV of a widely supported crate to "current stable". I'd say the latter is not OK even with a breaking semver release, but is more exusable that way.

It's unclear where on this spectrum 1.31 lays, but, given that rand recently bumped to 1.32, I guess it's closer to "two year old Rust"

Laurențiu Nicola (Sep 05 2019 at 18:05, on Zulip):

failure is only used by chalk, right?

matklad (Sep 05 2019 at 18:07, on Zulip):

right: https://github.com/rust-lang/chalk/pull/236

matklad (Sep 05 2019 at 18:11, on Zulip):

@David Barsky added you as a maintainer of https://github.com/rust-analyzer/VsCode-themes/

David Barsky (Sep 05 2019 at 18:16, on Zulip):

@matklad thanks!

David Barsky (Sep 05 2019 at 18:18, on Zulip):

I worry more about turning failure into rand—I know some people have their complaints about its maintence. in fairness, failure probably also has a similar reputation, but _far_ off into the other direction

Last update: Nov 19 2019 at 18:50UTC