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.

Sign up for GitHub

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

Jump to bottom

x.py check doesn't check compiler/rustc_query_system or library/core/tests #79305

Closed
varkor opened this issue Nov 22, 2020 · 2 comments
Closed

x.py check doesn't check compiler/rustc_query_system or library/core/tests #79305

varkor opened this issue Nov 22, 2020 · 2 comments
Labels
C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@varkor
Copy link
Member

varkor commented Nov 22, 2020

I had compilation errors in these two modules, but x.py check succeeded (discovered when creating #79299).
@varkor varkor added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) C-bug Category: This is a bug. labels Nov 22, 2020
@Mark-Simulacrum
Copy link
Member

Hm, the tests are not checked because that's what happens in... any cargo check. You need to pass --all-targets for tests (including cfg(test) in the crate itself) to get checked, the same is true of x.py check.

The error in rustc_query_system came from cfg(parallel_compiler) code, which was not checked because you don't enable that locally.

I believe both of these are won't fix (or at least not x.py check problems, really).

@varkor
Copy link
Member Author

varkor commented Nov 22, 2020

Okay, thanks for clarifying. That does seem reasonable.

matthewjasper added a commit to matthewjasper/rust that referenced this issue Dec 20, 2020
@matthewjasper
Prevent caching projections in the case of cycles
2e92b13 
When normalizing a projection which results in a cycle, we would
cache the result of `project_type` without the nested obligations
(because they're not needed for inference). This would result in
the nested obligations only being handled once in fulfill, which
would avoid the cycle error.

Fixes rust-lang#79714, a regresion from rust-lang#79305 caused by the removal of
`get_paranoid_cache_value_obligation`.
Mark-Simulacrum pushed a commit to Mark-Simulacrum/rust that referenced this issue Dec 27, 2020
@matthewjasper @Mark-Simulacrum
Prevent caching projections in the case of cycles
2f925da 
When normalizing a projection which results in a cycle, we would
cache the result of `project_type` without the nested obligations
(because they're not needed for inference). This would result in
the nested obligations only being handled once in fulfill, which
would avoid the cycle error.

Fixes rust-lang#79714, a regresion from rust-lang#79305 caused by the removal of
`get_paranoid_cache_value_obligation`.
Mark-Simulacrum pushed a commit to Mark-Simulacrum/rust that referenced this issue Dec 31, 2020
@matthewjasper @Mark-Simulacrum
Prevent caching projections in the case of cycles
89164cd 
When normalizing a projection which results in a cycle, we would
cache the result of `project_type` without the nested obligations
(because they're not needed for inference). This would result in
the nested obligations only being handled once in fulfill, which
would avoid the cycle error.

Fixes rust-lang#79714, a regresion from rust-lang#79305 caused by the removal of
`get_paranoid_cache_value_obligation`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@varkor @Mark-Simulacrum