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

Don't rebuild everything on test-or-comment-only changes #6522

Closed
emberian opened this issue May 16, 2013 · 13 comments
Closed

Don't rebuild everything on test-or-comment-only changes #6522

emberian opened this issue May 16, 2013 · 13 comments

Comments

@emberian
Copy link
Member

The build system currently rebuilds everything for test-only changes, which is really painful. Ideally, it should get a diff (using git), and check if any of the changes are outside #[test] items before deciding that the build is stale.

@catamorphism
Copy link
Contributor

#2369 would solve this, but in the short term this suggestion is probably a good idea.

@emberian
Copy link
Member Author

Would #2369 actually solve it? It'd help for stage0, but the other stages always need to be rebuilt, yeah?

@ben0x539
Copy link
Contributor

Can we amend this to test-or-docs-only changes? :)

@emberian
Copy link
Member Author

done :)

@pnkfelix
Copy link
Member

This seems difficult to express via make, at least given our existing infastructure, where so much is based around file timestamps rather than diff analysis.

I propose that we table doing this until after we have moved to using rustpkg as the basis for bootstrapping (Issue #2237).

@pnkfelix
Copy link
Member

(i also am deliberately not nominating this for a maturity milestone. I don't see this particular tooling issue as being worth attaching to any particular release; then again, I don't necessarily see that we should put it in at all.)

@catamorphism
Copy link
Contributor

I would love for this to happen, but since we're not planning to port all of Rust to rustpkg in the immediate future, it's blocked on #2237 and also far off in the future.

@catamorphism
Copy link
Contributor

I've thought about making rustc use workcache internally for compiling individual items, which would address this, but that's also a pretty big project and not an immediate priority.

@steveklabnik
Copy link
Member

Triage: oh yes this is still so very painful.

@emberian
Copy link
Member Author

This is basically foregone at this point.

@jhasse
Copy link
Contributor

jhasse commented May 22, 2015 via email

@Gankra
Copy link
Contributor

Gankra commented May 22, 2015

Translation: this is unlikely to ever happen.

@emberian
Copy link
Member Author

The current build system makes this pretty much impossible to do. We could technically do it, but it'd be more trouble than it's worth.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 15, 2021
fixes rust-lang#6522

changelog: field_reassign_with_default: don't expand macros in lint suggestion (rust-lang#6522)
flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 15, 2021
field_reassign_with_default: don't expand macros in suggestion

fixes rust-lang#6522

changelog: field_reassign_with_default: don't expand macros in lint suggestion (rust-lang#6522)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants