-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Type inference results in overflow evaluating the requirement
#127411
Labels
C-bug
Category: This is a bug.
Comments
rustbot
added
the
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
label
Jul 6, 2024
@rustbot label fixed-by-next-solver |
Somewhat minimized: Codefn conjure<T>() -> T {
unimplemented!()
}
fn conjure_two<T>() -> (T, T) {
unimplemented!()
}
fn f() {
let (crypto_sender, crypto_receiver) = conjure_two();
run_worker(crypto_receiver);
let mut context = Context::<State<_>> {
schedule: conjure::<Erase<_, _, ScheduleState<_>>>(),
crypto_worker: crypto_sender,
};
}
fn run_worker<S, C: Send, E>(_: ErasedEvent<(), Erase<S, C, E>>) {}
struct State<A>(A);
struct Context<O: On> {
schedule: O::Schedule,
crypto_worker: O::CryptoWorker,
}
trait On {
type Schedule;
type CryptoWorker;
}
impl<A> On for State<A> {
type Schedule =
Erase<State<A>, Context<State<A>>, ScheduleState<ErasedEvent<State<A>, Context<State<A>>>>>;
type CryptoWorker = ErasedEvent<
(),
Erase<State<A>, Context<State<A>>, ErasedEvent<State<A>, Context<State<A>>>>,
>;
}
struct ScheduleState<M>(M);
type ErasedEvent<S, C> = Box<dyn FnOnce(&mut S, &mut C) + Send>;
struct Erase<S, C, E>(S, C, E); |
Thanks a lot for the further minimization @theemathas! You really saved me a day :) |
Noratrieb
removed
the
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
label
Jul 7, 2024
Minimized: use std::marker::PhantomData;
struct Wrap<U>(U);
trait Trait {
type InContext;
}
impl<U> Trait for Wrap<U> {
type InContext = Context<Wrap<U>>;
}
struct Context<T: Trait> {
// this is PhantomData<Self>
phantom: PhantomData<T::InContext>,
}
fn require_send<T: Send>() {}
fn f() {
require_send::<Context::<Wrap<_>>>();
} Annotating the type as The correct error should be "type annotation required". Error output
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The full reproducible case is here. Before committing further efforts on reducing it I would like to learn about maintainer's opinion on such issues. Whether it should be considered as bug? If so, will it be fixed straight way or need to go through some formalization first?
The skeleton is like this
If compiled like this it will fail with
(By the way, a minor issue here is that the trace does not properly fold the repeating steps. It also results in outputting hundreds of "long type" files (and even more if increasing recursion limit).)
If switch to define
crypto_task
at the commented location, it just compiles. Thecrypto_task
andclient_task
are independent definitions so it is semantically same to define in either order (in my original case they are futures so even nothing executed effectively by this two definitions).Giving annotation to the first
unbounded_channel()
call with at least::<ErasedEvent<State<()>, _>
makes it compile in the original order.It has always been the case where type inference does not work in some definition order, but most of the time a "type annotation required" error is reported. Should we fix this case to the extent that at least a less confusing error is reported? On the other hand I am actually curious about the internal mechanism here:
Send
, but eventually get stuck in checkingSized
, what's happening here?Thanks for any clarification!
Meta
rustc --version --verbose
:Also reproduced on nightly
Backtrace
The text was updated successfully, but these errors were encountered: