Skip to content
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

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

Closed
LukasKalbertodt opened this issue Jul 31, 2018 · 11 comments · Fixed by #53235
Closed

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

LukasKalbertodt opened this issue Jul 31, 2018 · 11 comments · Fixed by #53235
Labels
C-bug Category: This is a bug. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@LukasKalbertodt
Copy link
Member

LukasKalbertodt commented Jul 31, 2018

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 shepmaster added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Jul 31, 2018
@shepmaster
Copy link
Member

shepmaster commented Jul 31, 2018

$ 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
Copy link
Member

kennytm commented Aug 1, 2018

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 Mark-Simulacrum added the regression-from-stable-to-stable Performance or correctness regression from one stable version to another. label Aug 1, 2018
@Mark-Simulacrum
Copy link
Member

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

@estebank
Copy link
Contributor

estebank commented Aug 1, 2018

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
Copy link
Contributor

estebank commented Aug 1, 2018

self.parse_trait_item_assoc_ty()?

/// 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
Copy link
Contributor

estebank commented Aug 1, 2018

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

@nikomatsakis
Copy link
Contributor

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

@nikomatsakis nikomatsakis added the P-high High priority label Aug 9, 2018
@nikomatsakis
Copy link
Contributor

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
Copy link
Member

varkor commented Aug 9, 2018

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

@varkor
Copy link
Member

varkor commented Aug 9, 2018

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.

@varkor
Copy link
Member

varkor commented Aug 9, 2018

Narrowing it down a little more:

hir::TyKind::Path(hir::QPath::Resolved(ref maybe_qself, ref path)) => {
debug!("ast_ty_to_ty: maybe_qself={:?} path={:?}", maybe_qself, path);
let opt_self_ty = maybe_qself.as_ref().map(|qself| {
self.ast_ty_to_ty(qself)
});
self.def_to_ty(opt_self_ty, path, false)
}

path.def is Def::Err at this point when the where clauses are defined, so something's going wrong before that point.

kennytm added a commit to kennytm/rust that referenced this issue Aug 11, 2018
Feature gate where clauses on associated type impls

Fixes rust-lang#52913. This doesn't address the core problem, which is tracked by rust-lang#47206. However, it fixes the stable-to-stable regression: you now have to enable `#![feature(generic_associated_types)]` to trigger the weird behaviour.
kennytm added a commit to kennytm/rust that referenced this issue Aug 13, 2018
Feature gate where clauses on associated type impls

Fixes rust-lang#52913. This doesn't address the core problem, which is tracked by rust-lang#47206. However, it fixes the stable-to-stable regression: you now have to enable `#![feature(generic_associated_types)]` to trigger the weird behaviour.
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Aug 22, 2018
Feature gate where clauses on associated type impls

Fixes rust-lang#52913. This doesn't address the core problem, which is tracked by rust-lang#47206. However, it fixes the stable-to-stable regression: you now have to enable `#![feature(generic_associated_types)]` to trigger the weird behaviour.
bors added a commit that referenced this issue Aug 23, 2018
Feature gate where clauses on associated type impls

Fixes #52913. This doesn't address the core problem, which is tracked by #47206. However, it fixes the stable-to-stable regression: you now have to enable `#![feature(generic_associated_types)]` to trigger the weird behaviour.
@Centril Centril added the F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs label Aug 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants