`rustc` doesn't output anything but exits with 101 and doesn't emit any files

[LukasKalbertodt]

trait Foo {
    type Out;
}

impl<T> Foo for Box<T> {
    type Out where T: Clone = T;
}

fn main() {}

Compiling this code results in no output by rustc. But rustc exits with 101 and does not produce any artifacts. (On Playground)

The error happens with:

• rustc 1.27.1 (5f2b325f6 2018-07-07),
• rustc 1.27.2 (58cc626de 2018-07-18), and
• rustc 1.29.0-nightly (874dec25e 2018-07-21)

[shepmaster]

$ rustc -Z time-passes a.rs
  time: 0.001	parsing
  time: 0.000	recursion limit
  time: 0.000	crate injection
  time: 0.000	plugin loading
  time: 0.000	plugin registration
  time: 0.000	pre ast expansion lint checks
    time: 0.037	expand crate
    time: 0.000	check unused macros
  time: 0.037	expansion
  time: 0.000	maybe building test harness
  time: 0.000	maybe creating a macro crate
  time: 0.000	creating allocators
  time: 0.000	AST validation
  time: 0.000	name resolution
  time: 0.000	complete gated feature checking
  time: 0.000	lowering ast -> hir
  time: 0.000	early lint checks
  time: 0.000	indexing hir
  time: 0.000	load query result cache
  time: 0.000	looking for entry point
  time: 0.000	looking for plugin registrar
  time: 0.000	loop checking
  time: 0.000	attribute checking
  time: 0.000	stability checking

If I set breakpoints on

• rustc::middle::stability::check_unstable_api_usage
• rustc_typeck::check_crate
• rustc_passes::rvalue_promotion::check_crate

It hits the first two but not the third, seemingly pointing to rustc_typeck::check_crate returning an Err.

[kennytm]

The silent exit is a regression. From godbolt,

• 1.23.0

  error: expected `=`, found `where`
   --> <source>:6:14
    |
  6 |     type Out where T: Clone = T;
    |              ^^^^^
  error[E0046]: not all trait items implemented, missing: `Out`
   --> <source>:5:1
    |
  2 |       type Out;
    |       --------- `Out` from trait
  ...
  5 | / impl<T> Foo for Box<T> {
  6 | |     type Out where T: Clone = T;
  7 | | }
    | |_^ missing `Out` in implementation
  error: aborting due to 2 previous errors
  

  exit code = 101

• 1.24.0–1.25.0

  error: cannot continue compilation due to previous error
  

  exit code = 101

• 1.26.0–1.28.0(beta)

  No message, exit code = 101

• 1.29.0(nightly)

  No message, exit code = 1

[Mark-Simulacrum]

cc @rust-lang/compiler -- it'd be good to find out why we stopped providing any output at all here

[estebank]

I'm worried it might be one of my parser changes to provide better diagnostics... I would probably check for any odd looking err.cancel().

[estebank]

rust/src/libsyntax/parse/parser.rs

Line 1349 in 11f812a

self.parse_trait_item_assoc_ty()?

rust/src/libsyntax/parse/parser.rs

Lines 4940 to 4963 in 11f812a

	/// Parses the following grammar:
	/// TraitItemAssocTy = Ident ["<"...">"] [":" [GenericBounds]] ["where" ...] ["=" Ty]
	fn parse_trait_item_assoc_ty(&mut self)
	-> PResult<'a, (Ident, TraitItemKind, ast::Generics)> {
	let ident = self.parse_ident()?;
	let mut generics = self.parse_generics()?;
	// Parse optional colon and param bounds.
	let bounds = if self.eat(&token::Colon) {
	self.parse_generic_bounds()?
	} else {
	Vec::new()
	};
	generics.where_clause = self.parse_where_clause()?;
	let default = if self.eat(&token::Eq) {
	Some(self.parse_ty()?)
	} else {
	None
	};
	self.expect(&token::Semi)?;
	Ok((ident, TraitItemKind::Type(bounds, default), generics))
	}

[estebank]

It's not the parsing itself, it's that in 1.24 the feature was introduced: #45904.

[nikomatsakis]

@estebank do you think you see what the problem is?

[nikomatsakis]

Calling P-high but we don't yet have an obvious assignee. Still, seems bad that there is no diagnostic output at all! Not a good look.

[varkor]

The core issue is reported in #47206. However, the example here also demonstrates that where clauses aren't being feature gated properly.

[varkor]

I've made #53235 to address the surface problem, which is that you can trigger this on stable, without declaring the generic_associated_types feature. I thought it was better to fix that part of the problem straight away.