Hiya! I wanted to ask a slightly uninformed question. I was interested in adding support for macros like
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
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
Gotcha, sounds good! I might send subsequent PRs for proptest once https://github.com/AltSysrq/proptest/pull/166 lands
FYI, I am cosidering switching rust-analyzer itself from proptest to quickcheck :)
$ cargo bloat --time 29.57s ra_ide_api 27.23s ra_hir 16.94s proptest :( 16.35s syn 14.24s clap 12.85s syn
I did see that! I'm not the biggest fan of the
Arbitrary typeclass and I like Hypothesis/Hedgehog-style generators more :)
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!
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
what is Night Owl? A theme for VS Code?
It might be a good idea to make a shared repo, yeah, but probably outside of rust-analyzer's main repo
I'd contribute the One True Theme: Emacs-flawored zenburn: https://github.com/matklad/config/blob/f49c2a52122550006cd81bda2221426ad869e3ba/vscode/settings.json#L96-L177 :D
Yep! One that I'm pretty happy with. https://github.com/sdras/night-owl-vscode-theme
Outside, for sure. feel free to make a repo, I can send a PR with the config!
remove the duplicated syn, switch from clap to pico-args, keep proptest ;)
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.
@lqd switching to pico-args is genuinely great idea: https://github.com/rust-analyzer/rust-analyzer/issues/1768
it's a little more verbose than clap/structopt for sure, but the 20s+ reduction on compile times (in release) seemed worth it
@matklad Funny enough, I can't actually _publish_ changes—I can only merge them :)
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?
So, there are different opinions about this, but, it's fair to say that this is not outright wrong
For example, this PR bumps MSRV of lazy_static while staying semver compatible https://github.com/rust-lang-nursery/lazy-static.rs/pull/156
regex policy also allows bumping regex without making a breaking release: https://github.com/rust-lang/regex#minimum-rust-version-policy
hmm, good to know. i'm sorry about my conservatism here—I don't want to make any dumb mistakes here :)
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"
failure is only used by
@David Barsky added you as a maintainer of https://github.com/rust-analyzer/VsCode-themes/
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