Error in compilation #103181
Assignees
Labels
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
belooping
added
C-bug
|
I'm Rust newbie and I try to make a microservice. |
|
Hi, thank you for your report. Can you verify that this issue still occurs on the latest nightly version? |
|
Hi Nilstrieb, yes, same behavior with the nightly build. |
|
Looks like this is the same issue as #102588, which unfortunately also doesn't contain useful info. |
|
Thank you for the info.
Best regards
Didier
…On 18 Oct 2022, 16:14 +0200, Jesse Ruderman ***@***.***>, wrote:
error: internal compiler error: compiler/rustc_trait_selection/src/traits/query/normalize.rs:257:21: unexpected ambiguity: ...
This check was promoted to 'internal compiler error' in commit 7808f69 as part of pull request #99015 ***@***.***)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Minimized quite a lot: use hyper::http;
use std::{convert::Infallible, future::Future, net::SocketAddr, sync::Arc};
async fn request_handler(jvs_file: &str) -> http::Response<hyper::Body> {
todo!()
}
async fn service<H, F>(r_handler: Arc<H>) -> Result<http::Response<hyper::Body>, Infallible>
where
H: Fn(&str) -> F + Send,
F: Future<Output = http::Response<hyper::Body>> + Send,
{
r_handler(s).await;
todo!()
}
async fn serve<H, F>(socket: SocketAddr) -> hyper::Result<()>
where
H: Fn(&str) -> F + Send,
F: Future<Output = http::Response<hyper::Body>> + Send,
{
let request_handler = Arc::new(request_handler);
let service = hyper::service::make_service_fn(|_| {
let request_handler = request_handler.clone();
async move {
Ok::<_, Infallible>(hyper::service::service_fn(move |_| {
let request_handler = request_handler.clone();
service(request_handler)
}))
}
});
let server = hyper::server::Server::try_bind(&socket)?;
server.serve(service).await?;
Ok(())
}
fn main() {} |
|
Hello. Michael,
Many thanks, I will look at it and for sure learn a lot more
Regards
Didier Rigoli
Senior Manager
…On 18 Oct 2022, 20:20 +0200, Michael Goulet ***@***.***>, wrote:
Minimized quite a lot:
use hyper::http;
use std::{convert::Infallible, future::Future, net::SocketAddr, sync::Arc};
async fn request_handler(jvs_file: &str) -> http::Response<hyper::Body> {
todo!()
}
async fn service<H, F>(r_handler: Arc<H>) -> Result<http::Response<hyper::Body>, Infallible>
where
H: Fn(&str) -> F + Send,
F: Future<Output = http::Response<hyper::Body>> + Send,
{
r_handler(s).await;
todo!()
}
async fn serve<H, F>(socket: SocketAddr) -> hyper::Result<()>
where
H: Fn(&str) -> F + Send,
F: Future<Output = http::Response<hyper::Body>> + Send,
{
let request_handler = Arc::new(request_handler);
let service = hyper::service::make_service_fn(|_| {
let request_handler = request_handler.clone();
async move {
Ok::<_, Infallible>(hyper::service::service_fn(move |_| {
let request_handler = request_handler.clone();
service(request_handler)
}))
}
});
let server = hyper::server::Server::try_bind(&socket)?;
server.serve(service).await?;
Ok(())
}
fn main() {}
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
This regressed in 7808f69 -- I can't really work on it any further without a self-contained, minimized version of the ICE, which I attempted and failed to do. If someone wants to minimize it, then that would be greatly appreciated, and I can pick it up after that if nobody else has. @rustbot ping icebreakers-cleanup-crew |
rustbot
added
the
ICEBreaker-Cleanup-Crew
|
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good cc @AminArria @ayazhafiz @camelid @chrissimpkins @contrun @elshize @h-michael @HallerPatrick @hdhoang @hellow554 @henryboisdequin @imtsuki @JamesPatrickGill @kanru @KarlK90 @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @shekohex @sinato @smmalis37 @steffahn @Stupremee @tamuhey @turboladen @woshilapin @yerke |
|
Minimized more (playground): use std::convert::Infallible;
async fn smarvice() -> Result<hyper::http::Response<hyper::Body>, Infallible> {
ident_error;
todo!()
}
#[allow(dead_code)]
async fn iceice<A, B>(bldr: hyper::server::Builder<hyper::server::conn::AddrIncoming>)
where
A: Send,
B: Send,
{
let service = hyper::service::make_service_fn(|_| {
async {
Ok::<_, Infallible>(hyper::service::service_fn(|_| {
smarvice()
}))
}
});
bldr.serve(service).await.unwrap();
}
fn main() {}Error output
|
|
How could an ambiguity error be raised when the canonical request has no inference variables? This looks interesting. |
|
It's related to the variable name resolution error being emitted earlier, so maybe the inference context being tainted by errors causes something about evaluation to get messed up. |
|
Here's a cve without any external dependencies. Not quiet small, but it does the job. mod hyper {
use std::{fmt::Debug, future::Future, marker::PhantomData, pin::Pin, task::Poll};
pub trait HttpBody {
type Error;
}
impl HttpBody for () {
// don't implement `Error` here for the ICE
}
pub struct Server<I, S>(I, S);
pub fn serve<I, S>(_: S) -> Server<I, S> {
todo!()
}
impl<S, B> Future for Server<(), S>
where
S: MakeServiceRef<(), (), ResBody = B>,
B: HttpBody,
B::Error: Debug,
{
type Output = ();
fn poll(self: Pin<&mut Self>, _: &mut std::task::Context<'_>) -> Poll<Self::Output> {
todo!()
}
}
pub trait MakeServiceRef<Target, ReqBody> {
type ResBody;
}
impl<T, S> MakeServiceRef<(), ()> for T
where
T: for<'a> Service<&'a (), Response = S>,
S: Service<()>,
{
type ResBody = ();
}
pub struct MakeServiceFn<F>(pub F);
pub struct ServiceFn<F, R>(pub PhantomData<(F, R)>);
pub trait Service<Request> {
type Response;
}
impl<'t, F, Ret, Target, Svc> Service<&'t Target> for MakeServiceFn<F>
where
F: Fn() -> Ret,
Ret: Future<Output = Result<Svc, ()>>,
{
type Response = Svc;
}
impl<F, ReqBody, Ret, ResBody, E> Service<ReqBody> for ServiceFn<F, ReqBody>
where
F: Fn() -> Ret,
Ret: Future<Output = Result<ResBody, E>>,
{
type Response = ResBody;
}
}
async fn smarvice() -> Result<(), ()> {
Ok(())
}
fn service_fn<F, R, S>(f: F) -> hyper::ServiceFn<F, R>
where
F: Fn() -> S,
{
hyper::ServiceFn(std::marker::PhantomData)
}
async fn iceice() {
let service = hyper::MakeServiceFn(|| async { Ok::<_, ()>(service_fn(|| smarvice())) });
hyper::serve::<(), _>(service).await;
}
fn main() {} |
trait SendFuture: Send {
type Output;
}
impl<Fut: Send> SendFuture for Fut {
type Output = ();
}
async fn broken_fut() {
ident_error;
}
// triggers normalization of `<Fut as SendFuture>::Output`,
// which requires `Fut: Send`.
fn normalize<Fut: SendFuture>(_: Fut, _: Fut::Output) {}
async fn iceice<A, B>() // <- async fn is necessary
where
A: Send,
B: Send, // <- a second bound
{
normalize(broken_fut(), ());
}@rustbot label S-bug-has-mcve |
rustbot
added
the
S-has-mcve
|
@aliemjay interesting enough you seem to trigger the ICE in a different way than me? Maybe it's worth to test a possible solution to both inputs? |
|
I'm pretty sure I understand this error now. Either via @aliemjay's solution of having a However, we don't handle ambiguities properly with the normalization query call. I took a stab at fixing this in #102858, and I extended it a bit to also fix these cases, too. |
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this issue
Oct 20, 2022
compiler-errors
removed
the
ICEBreaker-Cleanup-Crew
notriddle
added a commit
to notriddle/rust
that referenced
this issue
Oct 22, 2022
…guity-bug, r=oli-obk Delay ambiguity span bug in normalize query iff not rustdoc Oli and I decided that the compiler debt of adding another usage of `tcx.sess.opts.actually_rustdoc` is fine, because we don't really want to add more complexity to the normalize query, and moving rustdoc to use fulfill normalization (`fully_normalize`, i.e. not use the normalize query) is unnecessary overhead given that it's skipping binders and stuff. r? oli-obk Fixes rust-lang#102827 Fixes rust-lang#103181
notriddle
added a commit
to notriddle/rust
that referenced
this issue
Oct 22, 2022
…guity-bug, r=oli-obk Delay ambiguity span bug in normalize query iff not rustdoc Oli and I decided that the compiler debt of adding another usage of `tcx.sess.opts.actually_rustdoc` is fine, because we don't really want to add more complexity to the normalize query, and moving rustdoc to use fulfill normalization (`fully_normalize`, i.e. not use the normalize query) is unnecessary overhead given that it's skipping binders and stuff. r? oli-obk Fixes rust-lang#102827 Fixes rust-lang#103181
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code
Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: