-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop rebuilding crates during testing #3770
Comments
Not critical for 0.6; removing milestone |
Hm, tricky. coretest is 700k larger than core (5.2m vs. 4.5m) and stdtest is 4mb larger than std (9.0m vs. 5.0m). I think increasing our binary distribution by that much is pretty unappealing, and even if limited to maintainer-mode, it'd mean probably doubling cycle time for in-workspace development before you start running the unit tests. |
@graydon What do you think about this other point brson made: "We could also move all tests to their own libraries, but it would preclude testing private functions." ? In particular, we could leave the private function tests in place, but move the bulk (well, hopefully the bulk) of the tests out into separately built libraries? |
It's plausible, yeah. Arguably the public interface is the right level to be doing unit tests at anyways (private tests may be too brittle). One can also design stable "test interfaces" into libraries for cases where this wouldn't otherwise be so: design-for-test is a real thing. How many private library tests do we have presently? |
We now have |
Triage: no updates. I'm not sure this is somthing that will ever get implemented. |
This is quite an old bug at this point, and I think that we've got enough options for this today. With Cargo we can have external test suites in |
CC rust-lang#3770 From rust-lang/rust-clippy#3770 (comment) (@flip1995): > Oh I thought I replied to this: I definitely see now that having this > as a correctness lint might be the wrong categorization. What we might > want to do is to just allow this lint, if there are comments in the > arm bodies. But a good first step would be to downgrade this lint to > style or complexity. I would vote for style since merging two arms is > not always less complex.
…exendoo Change `if_same_then_else` to be a `style` lint CC rust-lang#3770 From rust-lang/rust-clippy#3770 (comment) (`@flip1995):` > Oh I thought I replied to this: I definitely see now that having this > as a correctness lint might be the wrong categorization. What we might > want to do is to just allow this lint, if there are comments in the > arm bodies. But a good first step would be to downgrade this lint to > style or complexity. I would vote for style since merging two arms is > not always less complex. changelog: [`if_same_then_else`]: Change to be a `style` lint
Some FileDescriptor/FileDescription refactorings follow-up to rust-lang/miri#3763 (comment) I opted not to change the method names, as I think they are already pretty good (and the common one is the short name), and the docs should explain what they actually do, but if you feel like the names you proposed would be better, I'll just do that.
We have unit tests inline with crates, and testing them involves recompiling the crates in test mode. This is bad for development times. We are currently doing this for core, std, rustc, rustdoc, and cargo.
My preference is just to always compile the crates with tests and use an external test runner to invoke them. It will add some compile time to non-testing builds, and some size to the binaries so maybe we can have a way to turn them off.
We could also move all tests to their own libraries, but it would preclude testing private functions.
The text was updated successfully, but these errors were encountered: