compiler panic impl Trait #43021
Comments
sfackler
added
A-impl-trait
|
Minimal code to reproduce ( struct Example {}
fn example(input: &Example) -> impl Iterator<Item = &Example> {
::std::iter::once(input)
}Edit: debug log and backtrace: https://gist.github.com/PlasmaPower/7f1ffb636aa5d17119e639aaca7dc9eb It appears to be a bug with lifetime inference, as this works: struct Example {}
fn example<'a>(input: &'a Example) -> impl Iterator<Item = &'a Example> {
::std::iter::once(input)
} |
This code is currently causing the compiler to panic (rust-lang/rust#43021); I'm commiting the full snapshot in the hopes that it'll aid in debugging the issue.
|
I'm having the same issue, trying to compile the following code using the fn run<T>(socket: TcpStreamNew, test: &T)
-> impl Future<Item=Status, Error=Error>
where T: Test {
let request = socket.and_then(move |socket|
io::write_all(socket, T::request().as_bytes()));
let response = request
.and_then(|(socket, _req)| io::read_to_end(socket, Vec::new()) )
.and_then(|(_socket, bytes)| {
let mut headers = [EMPTY_HEADER; MAX_HEADERS];
let mut response = Response::new(&mut headers);
future::result(
response.parse(&bytes)
.map(|_| response)
.map_err(|e| Error::new(ErrorKind::Other, e)))
});
let status = response.map(T::check);
status
}Backtrace: https://gist.github.com/hawkw/f69c536918266225c70402458ad867f2 |
|
@hawkw I'm assuming either |
|
@PlasmaPower Interesting, I tried your example, and it doesn't ICE, but it won't compile with: fn derp<'a> (cfg: &'a ControlFlowGraph) -> impl Iterator<Item = &'a ControlFlowTarget> {
cfg.vertices().filter_map(|vx| cfg.vertex_label(vx))
}but this may be an unrelated error, haven't thought too much about it, though the error message doesn't really make sense to me |
|
Like this just seems still symptomatic of the bug: the double tick after but has nothing in it... Note: |
|
@m4b Do |
|
/// Node of the function graph.
#[derive(Serialize,Deserialize,Debug,Clone)]
pub enum ControlFlowTarget {
/// A basic block
Resolved(BasicBlock),
/// An unresolved indirect jump
Unresolved(Rvalue),
/// An error occured while disassembling
Failed(u64, Cow<'static, str>),
}
/// Graph of basic blocks and jumps
pub type ControlFlowGraph = AdjacencyList<ControlFlowTarget, Guard>;#[derive(Clone, Debug, Serialize,Deserialize)]
pub struct AdjacencyList<N, E> {
vertex_labels: HashMap<AdjacencyListVertexDescriptor, N>,
edge_labels: HashMap<AdjacencyListEdgeDescriptor, E>,
out_edges: HashMap<AdjacencyListVertexDescriptor, Vec<AdjacencyListEdgeDescriptor>>,
in_edges: HashMap<AdjacencyListVertexDescriptor, Vec<AdjacencyListEdgeDescriptor>>,
edges: HashMap<AdjacencyListEdgeDescriptor, (AdjacencyListVertexDescriptor, AdjacencyListVertexDescriptor)>,
next_edge: AdjacencyListEdgeDescriptor,
next_vertex: AdjacencyListVertexDescriptor,
} |
|
Interesting, I think that should compile (but it fails, probably due to the |
|
Oh wait, nevermind. The error message is deceiving, but here's the solution: fn derp<'a> (cfg: &'a ControlFlowGraph) -> impl Iterator<Item = &'a ControlFlowTarget> {
cfg.vertices().filter_map(move |vx| cfg.vertex_label(vx))
}It needs to be a move closure to work. Edit: to clarify, it's not moving |
|
Ah yea of course! The error message definitely is totally wrong though, hehe :) There's still some work to do for lifetimes and this feature I think EDIT: @PlasmaPower actually does not even work with the (correct) move annotation, same empty `` message: fn derp<'a> (cfg: &'a ControlFlowGraph) -> impl Iterator<Item = &'a ControlFlowTarget> {
cfg.vertices().filter_map(move |vx| cfg.vertex_label(vx))
} |
|
We could name the implicit lifetime as the closure, instead of just ``. Past that, we couldn't make the error message better without resolving implicit lifetimes for We could add in a |
|
Yea the error message needs to be improved. Ftr, this will compile: fn derp<'a> (cfg: &'a ControlFlowGraph) -> impl Iterator<Item = &'a ControlFlowTarget> + 'a {
cfg.vertices().filter_map(move |vx| cfg.vertex_label(vx))
}(note the additional This is exactly the same definition as the Boxed version I wrote, because I didn't want to write the type, so this is a perfect usecase for Consequently, I think this is as @PlasmaPower you suggest, a problem with lifetime inference. However, @hawkw example is a bit puzzling, because, afaik, you can't typedef a ref unless the lifetime is also exposed in the typedef, or it's EDIT removing the |
As I said earlier,
The best we can do now is to identify the currently unnamed lifetime. The compiler doesn't currently know the constraints on the lifetime, so it can't output a message similar to the one above (generated when using a box). |
|
Interesting. If run with Edit: requires rustc to be built with debugging information. |
|
This seems to be fixed now (the snippet in #43021 (comment) works fine on the latest nightly). Closing. |
Trying to Compile
Panic
The text was updated successfully, but these errors were encountered: