Closed
Description
This is partially due to the fact that our analysis
query
rust/src/librustc_interface/passes.rs
Line 775 in 537ccdf
optimized_mir
query on all items in the current crate, and also because we don't run monomorphization when building bin crates.
- run
optimized_mir
query inanalysis
- this may cause slowdowns for
cargo check
because we'd be doing optimizations now - All const propagation lints are emitted in
optimized_mir
, but we may add more in the future.
run monomorphization where possible.- Not sure how useful this is, it will only give us additional lints in very specific situations. (e.g. when we subtract something form an associated constant, we may get an overflow error depending on the value of the constant).
- This will also be significantly more expensive than just running
optimized_mir
cc @Centril
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
RalfJung commentedon Apr 8, 2020
Or maybe it is a bad idea to emit lints during optimization, and we should move the lints from const-prop to elsewhere?
ehuss commentedon Apr 8, 2020
This gets reported occasionally, like #49292 and #61330.
oli-obk commentedon Apr 8, 2020
the reason the lints are part of const prop is to ensure we don't do the work twice, once for linting and once for the const prop optimization. I'm not sure how we could do that differently.
Also I was envisioning adding more lints to the optimization pipeline instead of the other way around.
RalfJung commentedon Apr 30, 2020
Do we have a concrete example / test case demonstrating this?
mati865 commentedon Apr 30, 2020
RalfJung commentedon Apr 30, 2020
@ehuss has an example of this: it passes with
cargo check
, but failscargo build
, latest nightlyrustc 1.45.0-nightly (fa51f810e 2020-04-29)
.https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4998a76829fb44657cd8ed814fb2a191
cargo check
passes wherecargo build
fails rust-lang/cargo#86508 remaining items