Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
Collaborator

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
# for free to join this conversation on GitHub. Already have an account? # 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