Rustc does display a correct error message on type missmatch but does not show line numbers

[Yatekii]

I have a case where rustc will show me properly that I have a Type missmatch.
Unfortunately it wont show me where exactly it is.

I tracked the error location down in my own code and can safely say that the code attached is the source, but I couldn't reproduce it yet.
Once I am able to reproduce it, I will report it here, but maybe someone already has a clue or similar experiences.

The faulty error report:

yatekii@partymobile:~/repos/schema_renderer$ cargo build --release
   Compiling schema_parser v0.1.0 (file:///home/yatekii/repos/schema_renderer)
error[E0308]: mismatched types
  |
  = note: expected type `euclid::TypedRect<f32, schema_parser::geometry::SchemaSpace>`
             found type `ncollide2d::bounding_volume::AABB<f32>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: Could not compile `schema_parser`.

To learn more, run the command again with --verbose.

And the code that triggers it:

// Error triggered by:

let bb = self.model.schema.get_bounding_box();
self.model.view_state.update_from_box_pan(bb);

// Where

pub fn get_bounding_box(&self) -> SchemaAABB {
    use ncollide2d::math::{ Point, Vector };
    let mut aabb = SchemaAABB::new(
        Point::new(0.0, 0.0),
        Point::new(0.0, 0.0)
    );
    for component in &self.drawables {
        let i = &component.instance;
        use schema_parser::helpers::Translatable;
        let bb = &i.get_boundingbox().translated(Vector::new(i.position.x, i.position.y));
        use ncollide2d::bounding_volume::BoundingVolume;
        aabb.merge(bb)
    }
    aabb
}

// and

pub fn update_from_box_pan(&mut self, rect: geometry::SchemaRect) {
    let m = (rect.max_x() - rect.min_x()).max(rect.max_y() - rect.min_y());
    if m > 0.0 {
        self.scale = 2.45 / m;
        self.center = (rect.bottom_left() + rect.top_right().to_vector()) / -2.0;
        self.update_perspective();
        println!("Rect: {}", rect);
    }
}

Rustc version is: nightly-x86_64-unknown-linux-gnu rustc 1.28.0-nightly (86a8f1a 2018-06-17)

[estebank]

Can you verify wether you hit the same output on 1.27?

[Yatekii]

I can try today in the evening, but I wont be successful with a 99% guarantee as I am dependant on multiple nightly-requiring crates, such as relm.

[Yatekii]

Just had the same bug at a different place:

error[E0599]: no method named `to_row_arrays` found for type `nalgebra::base::matrix::Matrix<f32, nalgebra::base::dimension::U4, nalgebra::base::dimension::U4, nalgebra::base::matrix_array::MatrixArray<f32, nalgebra::base::dimension::U4, nalgebra::base::dimension::U4>>` in the current scope

No linenumbers whatsoever. Every other error in the same compilation log displays linenumbers correctly.

[estebank]

That is odd. Could you provide a repo with a repro case? I'd like to see this for myself to try and identify the source of the problem.

[Yatekii]

Sure, I can provide you with the entire repo, the exact commits with the two problems and the excat rustc version when I get home. Could have done this a lot earlier, sorry.

[Yatekii]

Ok, so, the commits are:

• 2nd Faulty Error Output
• 1st Faulty Error Output

The repo should be publicly accessible. Rustc is: rustc 1.28.0-nightly (86a8f1a 2018-06-17). A simple cargo run --release test_data/kicad.lib test_data/kicad.sch should trigger the issue.

I hope this helps.

[Yatekii]

#![feature(proc_macro, wasm_import_module, wasm_custom_section)]

extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;

const MEM_SIZE: usize = 1024 * 1024;
const BLOCK_SIZE: usize = 1024;
const NUM_BLOCKS: usize = MEM_SIZE / BLOCK_SIZE;

struct FAT
{
    memory: [[u8; BLOCK_SIZE]; NUM_BLOCKS]
}

#[wasm_bindgen]
impl FAT
{
    pub fn new() -> FAT
    {
        FAT
        {
            memory: [[0; BLOCK_SIZE], NUM_BLOCKS]
        }
    }
}

#[cfg(test)]
mod tests
{
    use super::*;

    #[test]
    fn test_new_FAT()
    {
        let newFS = FAT::new();
        for blk in 0..NUM_BLOCKS
        {
            for b in 0..BLOCK_SIZE
            {
                assert_eq!(newFS.memory[blk][b], 0);
            }
        }
    }
}

seems to trigger the issue too. Courtesy to @Coolerz on #rust.

The common denominator of this and my code is proc-macro so maybe a look into it is worth it.

[estebank]

That is very likely the culprit, as with proc macros we (usually) lose the spans. I'd have to see if we have any other bit of context that could be used instead.

[Yatekii]

Yeah, I am sorry, I don't understand too much of it yet ;) Thanks for investigating =)

[p4l1ly]

Hi, my temporary hack to get better error information until this problem is solved is described in this gist (see the last paragraph of the README.md): https://gist.github.com/p4l1ly/6dbcb40fb3bbb450598876b068762939

[iddm]

Still happens for as well, on the latest nightly (1.39).

[iddm]

Issue in docker image: rust-lang/docker-rust-nightly#17

UPD: it has nothing to do with docker, it is a problem of rustc.

[iddm]

Is anybody working on this problem? Because I can't work on my project. Both nightly docker images I use don't show lines, only errors, it is really very hard to guess what is causing errors and where.

[estebank]

I don't believe anyone is actively working on this issue, as no one has self-assigned. @petrochenkov might have some insight.

@vityafx could you provide more information? Did it not use to happen in previous nightlies? Can you help us identify when it was introduced? What project are you seeing this in? As it stands we have @Yatekii's repro case, but we can't verify that it is the same issue you're seeing, and the underlying solution might be changes to the proc macro you're likely using.

[iddm]

@estebank I was not using nightly actively for quite a while, but I think I did not have this problem on 1.36 nightly. It started happening on 1.38 and continues to happen on 1.39.

[estebank]

@vityafx could you point us in the direction of the project you're experiencing this with?

[iddm]

@vityafx could you point us in the direction of the project you're experiencing this with?

If this can help, right now I am using nightly only for my rocket HTTP server.

Code lines are not only invisible in cargo check and cargo build but also in cargo clippy.

[nikomatsakis]

One option @vityafx would be to use cargo-bisect-rustc to diagnose the exact nightly which caused the problem. That would be very helpful!

[iddm]

@nikomatsakis Can do!

[iddm]

• nightly-2019-05-07 - other errors (error: enum variants on type aliases are experimental) with code lines in the message.
• nightly-2019-06-20 - the same as above.
• nightly-2019-07-01 - the same as above.
• nightly-2019-07-02 - current errors without code lines in the message.
• nightly-2019-07-03 - current errors without code lines in the message.
• nightly-2019-07-06 - current errors without code lines in the message.
• nightly-2019-07-12 - current errors without code lines in the message.
• nightly-2019-08-04 - current errors without code lines in the message.

tested nightly-2019-07-02, got Yes
searched toolchains nightly-2019-05-07 through nightly-2019-08-04
regression in nightly-2019-07-02

• 0af8e87 - enum variants error with lines.
• 5748825 - regressed
• 765eebf - regressed.
• 17e62f7 - regressed

searched toolchains 0af8e872ea5ac77effa59f8d3f8794f12cb8865c through 17e62f77f954bed97aae839624bfd6dd68342daf
regression in 5748825cc8c74cccef0059cdd4043e6e9b4aa188

I think this does not show exactly when the problem started to appear. I still need to find an MCVE and repeat the procedure. Because it may be simply hidden by the enum variants error because on the code I was testing it the errors were caused after a borrow checker which is usually performed on later pipelines stages, AFAIK. But still, even with the enum variants error, there were lines of code shown in the message.

I'll see what I can do with MCVE and bisecting because I can't really work on the project without this...

[iddm]

Have found an MCVE, bisecting.

[iddm]

Could you guys tell me how to specify serde version less than 1.0.99? Rocket 0.4.0 needs toml 0.4.10, which needs serde 1.0.99, while serde 1.0.99 can't be compiled on rustc 1.35 (of April-May). Is there a way?

[iddm]

So far, I have only been able to achieve this:

#![feature(proc_macro_hygiene, decl_macro)]

type Result<T> = std::result::Result<T, ()>;

pub fn f<T>(f: &dyn Fn() -> Result<T>) -> Result<T> {
    f()
}

// Either comment this line below with `rocket::post`...
#[rocket::post("/")]
fn open_session() -> Result<String> {
    // ...or comment this if, or don't call "f" function
    if let Ok(_) = f(&|| Ok(())) {
    // This if also reproduces.
    // if let Ok(_) = &|| Ok(()) {
	return Ok("2".to_string())
    }

    Ok("1")
}

fn main() {
}

It can be that the minimal example can be still narrowed down.

UPD: simplifying the code I've come up with this:

#![feature(proc_macro_hygiene, decl_macro)]

// Either comment this line below with `rocket::post`...
#[rocket::post("/")]
fn problem() -> String {
    // If I surround the lambda with parens as below, everything is okay.
    //
    // if let Some(_) = (|| Some(())) {
    //
    // But if not, the code causing problems is not shown. Also, 
    // instead of a lambda there can be a function call.
    if let Some(_) = || Some(()) {
	return "2".to_string()
    }

    // This should be the line causing the error.
    1
}

fn main() {
}

[estebank]

probably_equal_for_proc_macro is failing to recognize the closure as the same, because the pretty printer unconditionally adds parenthesis around closures:

DEBUG 2019-09-07T21:45:23Z: syntax::tokenstream: probably_equal_for_proc_macro tts 
t1=Token(Token { kind: OrOr, span: Span { lo: BytePos(419), hi: BytePos(421), ctxt: #0 } })
t2=Delimited(DelimSpan { open: Span { lo: BytePos(102), hi: BytePos(122), ctxt: #0 }, close: Span { lo: BytePos(102), hi: BytePos(122), ctxt: #0 } }, Paren, TokenStream(Some([(
   Token(Token { kind: OrOr, span: Span { lo: BytePos(102), hi: BytePos(122), ctxt: #0 } }), NonJoint),
  (Token(Token { kind: Ident(Some, false), span: Span { lo: BytePos(102), hi: BytePos(122), ctxt: #0 } }), NonJoint),
  (Delimited(DelimSpan { open: Span { lo: BytePos(102), hi: BytePos(122), ctxt: #0 }, close: Span { lo: BytePos(102), hi: BytePos(122), ctxt: #0 } }, Paren, TokenStream(Some([(Delimited(DelimSpan { open: Span { lo: BytePos(102), hi: BytePos(122), ctxt: #0 }, close: Span { lo: BytePos(102), hi: BytePos(122), ctxt: #0 } }, Paren, TokenStream(None)), NonJoint)]))), NonJoint)
])))

We should probably look at Nonterminal::to_tokenstream to normalize the closure representation.

CC @petrochenkov #43081

Modifying the following to unconditionally return tokens; made the output in the repro repo correct,

rust/src/libsyntax/parse/token.rs

Lines 806 to 808 in 43a5ff4

	if tokens.probably_equal_for_proc_macro(&tokens_for_real) {
	return tokens
	}

but I am looking at whether the "AST modified directly diverges from the pprinted version" problem is actually still happening but I haven't been able to reproduce a real case, and on the contrary some tests actually start behaving correctly (we seem to have had the same issue with extern fn bar())

[estebank]

I couldn't compile the project linked in #51635 (comment)

The case in #51635 (comment) is already fixed

#51635 (comment) is fixed by #64277, but that PR might need some back and forth before it is mergeable.

[pnkfelix]

triage: Still needs MCVE; in particular, I think it would be very valuable to have an MCVE that includes its own definition of a proc-macro, rather than relying on some third-party crate to provide it.

[iddm]

I suggest adding a check into the compiler - if the compiler is unable to deduce context but found an error there, don't just print out the error, print out a message like "The compiler couldn't print out the context, please consider filing a bug report on https://github.com/rust-lang/rust/issues/". This will not solve problems but will be helpful in some sense.

[matclab]

FYI I've got a similar problem (error without line number) in stable rustc 1.41.0 (5e1a799 2020-01-27)

[maackle]

I'm having this problem too. I made a repo with a minimal reproduction FWIW.

I'm not sure if this completely explains the problem, but in this repo I defined two trivial proc macro attributes, one which spits out the code unchanged (#[noop]), another which quotes the code and then spits that out unchanged ([#quoter]). I tried various combinations of these two macros, and all of them preserve line numbers for type errors except when applying noop and then quoter. Here is the line that demonstrates the combination that causes line numbers to be erased: https://github.com/maackle/nested-proc-macro-mcve/blob/master/app/src/main.rs#L21

(cross-posted to #68430 (comment))

[najamelan]

@maackle I cannot reproduce your MCVE with rustc 1.45.0-nightly (7ced01a73 2020-04-30). All pass correctly.

@pnkfelix A simple change however allows to trigger the problem in the example given by @maackle:

fn gen<T>() -> Option<T> { None }

#[quoter]
fn beta() {
    gen::< Result<(),()> >();

    let _ = 1 + 1.0;
}

error, has no line numbers and won't show in IDE's:

error[E0277]: cannot add a float to an integer
  |
  = help: the trait `std::ops::Add<{float}>` is not implemented for `{integer}`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `app`.

To learn more, run the command again with --verbose.

Change the first line to:

gen::<()>();

and line numbers are correctly printed.

[simonrepp]

I've been seeing similar issues in a client project for some weeks using recent nightly rusts (up to and including rustc 1.45.0-nightly (a74d1862d 2020-05-14) as of writing this), I'm using rocket and the issue disappears when I remove the #[get(...)] macro on the endpoint's function, so clearly this seems to be related to macros. I can't disclose any code but it wouldn't be a minimal repro case anyway, also my employer doesn't understand open source so I won't be given time to provide one either, this is just to confirm that this is a thing out in the wild still. But at the very least I'll offer my gratitude: Thanks everyone for putting work into this, you rock. 👍

[Aaron1011]

The general problem of losing line numbers with proc-macros is tracked at #43081. I suspect that the gen::< Result<(),()> >(); issue mentioned by @najamelan will be fixed by #72306

[Aaron1011]

This should be fixed on the latest nightly.

[estebank]

Confirmed that #51635 (comment) and #51635 (comment) are now fixed on nightly. Couldn't verify #51635 (comment) due to a failure on the pear crate, but don't see why the original issue wouldn't be resolved by the recent changes. Thank you @Aaron1011 for the ton of work you've poured into this!

Closing on favor of #43081 for any outstanding tasks (namely #80689).