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

Unknown type in basic hyper code #14369

Closed
lowr opened this issue Mar 17, 2023 · 2 comments
Closed

Unknown type in basic hyper code #14369

lowr opened this issue Mar 17, 2023 · 2 comments
Labels
A-ty type system / type inference / traits / method resolution C-bug Category: bug

Comments

@lowr
Copy link
Contributor

lowr commented Mar 17, 2023

This is not really a rust-analyzer bug but a chalk bug, nevertheless filing this here to make it known and so we have an open issue to point to.

Below is a modified example from hyper tutorial. Note that some of the functions have been removed for hyper 1.0, so make sure to use hyper 0.14.x to reproduce.

use std::convert::Infallible;
use std::net::SocketAddr;
use hyper::{Body, Request, Response, Server};
use hyper::service::{make_service_fn, service_fn};

async fn hello_world(_req: Request<Body>) -> Result<Response<Body>, Infallible> { todo!() }

async fn test() {
    let addr = SocketAddr::from(([127, 0, 0, 1], 3000));

    let make_svc = make_service_fn(|_conn| async {
        Ok::<_, Infallible>(service_fn(hello_world))
    });

    let server = Server::bind(&addr).serve(make_svc);
      //^^^^^^ `Server<AddrIncoming, MakeServiceFn<closure>, Exec>`
      //       this type *does* implement `Future<Output = hyper::Result<()>>`
    let result = server.await;
      //^^^^^^ {unknown}, because chalk **disproves** `Server<_, _, _>: Future`.
}

cc #13450, #14264, #14322, #14324, I believe they are all caused by this issue.

rust-analyzer version: rust-analyzer version: 0.0.0 (b4d7ea0 2023-03-14)

rustc version: rustc 1.68.0 (2c8cc3432 2023-03-06)

relevant settings: none
@lowr lowr added A-ty type system / type inference / traits / method resolution C-bug Category: bug labels Mar 17, 2023
@lowr lowr mentioned this issue Mar 24, 2023
Merged
This was referenced Apr 22, 2023
Open
Open
@lowr lowr mentioned this issue Jun 9, 2023
Closed
bors added a commit to rust-lang/chalk that referenced this issue Jun 14, 2023
@bors
Auto merge of #792 - lowr:fix/generalize-alias-alias-eq-clause, r=jac…
88fd1c2 
…kh726

Generalize program clause for `AliasEq` goal with nested alias

Consider a goal: `AliasEq(<<?0 as X>::A as Y>::B = <<?1 as X>::A as Y>::B)`. This is expected to (eventually) flounder when the traits are non-enumerable and the variables are yet to be known, but it's currently **disproven**:

1. the goal is canonicalized as follows:
    - `forall<T, U> AliasEq(<<T as X>::A as Y>::B = <<U as X>::A as Y>::B)`
1. we produce the following `ProgramClause` that could match:
    - `forall<T, U, ..> AliasEq(<<T as X>::A as Y>::B = <<U as X>::A as Y>::B) :- AliasEq(..), AliasEq(..)`
1. the consequence of the (instantiated) clause is unified with the goal, which produces a subgoal:
    - `AliasEq(<<?0 as X>::A as Y>::B = <<?1 as X>::A as Y>::B)`
    - this is because when we unify rhs of `AliasEq`, we see two `AliasTy`s that we cannot unify structurally, forcing us to produce the subgoal
1. boom, cycle emerged, goal disproven!

The problem is that because we're reusing the original goal as the consequence of the program clause we expect them to unify structurally, however we cannot unify aliases structurally in general (e.g. `<?0 as X>::A = <?1 as X>::A` does not imply `?0 = ?1`).

This PR solves it by placing a fresh variable in rhs of the consequence `AliasEq` instead of reusing the original term. This ensures that rhs of the original `AliasEq` goal is preserved via unification without producing subgoals even if it's an alias.

See rust-lang/rust-analyzer#14369 for a real world case where this issue arises.
@Throne3d
Copy link
Contributor

It looks like the other issues linked here were closed, and I can't reproduce this locally - the inference for result seems to be Result<(), Error>, not {unknown}, for me locally. Is this still a problem on recent versions of RA?

image

@lnicola
Copy link
Member

lnicola commented Jul 29, 2024

Indeed, this seems to work now (hyper = { version = "0.14", features = ["http1", "server", "tcp"] }).

@lnicola lnicola closed this as completed Jul 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-ty type system / type inference / traits / method resolution C-bug Category: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lnicola @Throne3d @lowr