My program segfaults and/or aborts when I abuse generic_associated_types #71210
Description
I tried this code:
// segfaults when running on 1.44.0-nightly (94d346360 2020-04-09)
#![allow(incomplete_features)]
#![feature(generic_associated_types)]
use std::collections::hash_map::{HashMap, Iter};
pub enum Papadimoulian { True, FileNotFound } // any two will do
fn visit_directory<FS: FileSystem>(fs: &FS) -> () {
let _unused = "----------------------------------------------------------------------------".to_string();
let mut iterator = fs.directory_iterator();
iterator.next();
}
pub trait FileSystem {
type DirectoryIterator<'a>: Iterator<Item = Result<Box<u8>, Papadimoulian>>;
fn directory_iterator<'a>(&'a self) -> Self::DirectoryIterator<'a>;
}
impl FileSystem for HashMap<(), ()> {
type DirectoryIterator<'a> = Iter<'a, (), ()>;
fn directory_iterator<'a>(&'a self) -> Iter<'a, (), ()> {
self.iter()
}
}
/*****/ fn main() { visit_directory(&HashMap::new()) }
#[test] fn segv() { visit_directory(&HashMap::new()) }When I feed this main.rs into rustc it happily gives me a main program. When I run said main program, I get [1] 32118 segmentation fault (core dumped) RUST_BACKTRACE=1 ./main from zsh. (The main program also segfaults without RUST_BACKTRACE=1.)
Instead, I expected the compiler to reject my program with a type error: The HashMap iterator has Self::Item = (&'a K, &'a V) which is not a Result<Box<u8>, Papadimoulian>—yet if my program is to mean what I think it should mean, it's claiming that to be the case.
If I compile without --release and remove a dash from the unused string, I instead get munmap_chunk(): invalid pointer. If I remove all the dashes, or I remove the unused variable alltogether (and still compile without --release), I get free(): invalid pointer.
If I change Box<u8> to Box<()> I get a test success.
If I keep Box<u8> and replace Papadimoulian with Option<()> I get a segfault. I also get segfaults if I replace Papadimoulian with bool or u8, but not if I replace it with () (in all cases keeping Box<u8>.)
These two issues seem to be exploring the same feature, but with different results: #69184 and #67089.