Skip to content
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

Closed
brson opened this issue Oct 14, 2012 · 7 comments
Closed

Stop rebuilding crates during testing #3770

brson opened this issue Oct 14, 2012 · 7 comments
Labels
I-compiletime Issue: Problems and improvements with respect to compile times.

Comments

@brson
Copy link
Contributor

brson commented Oct 14, 2012

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.

@nikomatsakis
Copy link
Contributor

Not critical for 0.6; removing milestone

@graydon
Copy link
Contributor

graydon commented May 15, 2013

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.

@pnkfelix
Copy link
Member

@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?

@graydon
Copy link
Contributor

graydon commented Jul 16, 2013

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?

@huonw
Copy link
Member

huonw commented Nov 21, 2014

We now have make NO_REBUILD=1 which almost always works for the conventional edit-test cycle in a single crate IME (some people say that it doesn't work reliably for them so there may still be problems with it), but nothing beyond this.

@steveklabnik
Copy link
Member

Triage: no updates. I'm not sure this is somthing that will ever get implemented.

@alexcrichton
Copy link
Member

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 tests/*.rs and otherwise upcoming incremental compilation I believe may render this issue moot anyway

flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 16, 2023
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.
flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 16, 2023
…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
RalfJung pushed a commit to RalfJung/rust that referenced this issue Aug 5, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-compiletime Issue: Problems and improvements with respect to compile times.
Projects
None yet
Development

No branches or pull requests

7 participants