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

Make InferCtxt::can_eq and InferCtxt::can_sub return booleans #108010

Merged
merged 1 commit into from
Feb 16, 2023

Conversation

compiler-errors
Copy link
Member

Nobody matches on the result, nor does the result return anything useful...

@rustbot
Copy link
Collaborator

rustbot commented Feb 13, 2023

r? @lcnr

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 13, 2023
@compiler-errors
Copy link
Member Author

compiler-errors commented Feb 13, 2023

After #107940 lands, this these functions should additionally use TyCtxt::check_tys_might_be_eq when the new solver is enabled, to check for deep type equality with lazy norm... but I'll leave that up to another PR.

@BoxyUwU
Copy link
Member

BoxyUwU commented Feb 13, 2023

I feel like if !self.infcx.can_eq(a, b) { is less clear than if self.infcx.can_eq(a, b).is_err(). Could we just make the return type Result<(), ()>. if we start handling nested obligations we wont be able to always return a TypeError anyway so getting rid of it would have to happen

@compiler-errors
Copy link
Member Author

The answer to a "can" question being a boolean makes pretty good sense to me, and !self.can_do_thing() is pretty clearly "can't do thing".

We also have FnCtxt::can_coerce which has a handful of !self.can_coerce calls around the codebase already.

@lcnr
Copy link
Contributor

lcnr commented Feb 14, 2023

Ignoring for a moment that can_eq is kinda bad as a whole because it ignores nested obligations causing stuff like lazy norm to end up changing behavior I am in favor of this change.

Definitely in favor of yeeting TypeError from can_eq because I can't think of a case where you should use that TypeError to actually do anything 😅

wrt TyCtxt::check_tys_might_be_eq and lazy norm I don't yet have an opinion. I slightly prefer returning bool over result here.

@lcnr
Copy link
Contributor

lcnr commented Feb 15, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Feb 15, 2023

📌 Commit eb286dd has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 15, 2023
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 16, 2023
…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#107034 (Migrating rustc_infer to session diagnostics (part 4))
 - rust-lang#107972 (Fix unintentional UB in ui tests)
 - rust-lang#108010 (Make `InferCtxt::can_eq` and `InferCtxt::can_sub` return booleans)
 - rust-lang#108021 (make x look for x.py if shell script does not exist)
 - rust-lang#108047 (Use `target` instead of `machine` for mir interpreter integer handling.)
 - rust-lang#108049 (Don't suggest `#[doc(hidden)]` trait methods with matching return type)
 - rust-lang#108066 (Better names for illegal impl trait positions)
 - rust-lang#108076 (rustdoc: Use more let chain)
 - rust-lang#108088 (clarify correctness of `black_box`)
 - rust-lang#108094 (Demonstrate I/O in File examples)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 8f65e25 into rust-lang:master Feb 16, 2023
@rustbot rustbot added this to the 1.69.0 milestone Feb 16, 2023
@compiler-errors compiler-errors deleted the can_eq-returns-bool branch August 11, 2023 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants