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

"constant evaluation error" points to nothing when crossing the crate boundary #38875

Closed
shepmaster opened this issue Jan 6, 2017 · 11 comments

Comments

@shepmaster
Copy link
Member

commented Jan 6, 2017

These error markers point to nothing, which is less than ideal. The note does at least help somewhat.

error[E0080]: constant evaluation error
 --> src/lib.rs:5:30
  |
5 |
  |                              ^^^^^^^^^^^ unimplemented constant expression: enum variants
  |
note: for repeat count here
 --> examples/main.rs:4:22
  |
4 |     let test_x = [0; constenum::CRATE_ONE];
  |                      ^^^^^^^^^^^^^^^^^^^^

src/lib.rs

pub enum MyEnum {
    ONE = 1,
}

pub const CRATE_ONE: usize = MyEnum::ONE as usize;

examples/main.rs

extern crate constenum;

fn main() {
    let test_x = [0; constenum::CRATE_ONE];
}

Execute via cargo build --example=main

@kennytm

This comment has been minimized.

Copy link
Member

commented Jan 6, 2017

Same as #23898?

@shepmaster

This comment has been minimized.

Copy link
Member Author

commented Jan 6, 2017

@kennytm that looks like the underlying issue (non-constness) thanks! But this particular issue was meant to focus on the silly error message specifically. I assume that is easier to fix than the constness ;-)

@shepmaster shepmaster changed the title "constant evaluation error" points to nothing "constant evaluation error" points to nothing when crossing the crate boundary Jan 6, 2017

@eddyb

This comment has been minimized.

Copy link
Member

commented Jan 6, 2017

@nikomatsakis @jonathandturner So how do we get sources cross-crate? I'd love to just have the snippet to print instead of hiding it somehow.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2017

@eddyb so it does seem plausible to store where the sources were, I guess, and re-load them...but how do we know if they've changed in the interim?

@eddyb

This comment has been minimized.

Copy link
Member

commented Jan 7, 2017

We could hash each file, perhaps?

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2017

@eddyb yeah I suppose so. seems like a non-trivial PR in any case.

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2017

Storing the place where the sources are won't help, since with const fn, an error can hypothetically occur in the standard library (like if b = 0 in a/b in const fn div(a: i32, b: i32) { a / b }), and the sources are not available then (especially not in the location given by debuginfo).

@eddyb

This comment has been minimized.

Copy link
Member

commented Jan 10, 2017

My point is that they should be. Most linux distros have a notion of "debuginfo" packages and "debugsource" ones, with the former using paths installed by the latter. In NixOS you can just install the source of a package which is how the racer support works (in that case there is a hash in the path so it can only ever refer to one exact version of the files, so if we did hashing ourselves it'd always match).

chamaken added a commit to chamaken/crslmnl that referenced this issue Jan 19, 2017
@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

commented May 19, 2017

So, this example compiles successfully today. I'm failing at coming up with an example that doesn't... could someone comment with one?

@shepmaster

This comment has been minimized.

Copy link
Member Author

commented May 19, 2017

So, this example compiles successfully today

It has a non-blank error message, I assume you mean? With rustc 1.17.0 (56124baa9 2017-04-24), I get:

error[E0080]: constant evaluation error
 --> examples/main.rs:4:22
  |
4 |     let test_x = [0; constexprcrate::CRATE_ONE];
  |                      ^^^^^^^^^^^ unimplemented constant expression: enum variants

It seems like it shouldn't have 11 ^; maybe that's because that's the length of MyEnum::ONE in the library crate's source?

The error is still misleading as-is. It points at the client's use of a const usize, but complains it is an enum variant.

It seems this issue is still valid.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

commented May 19, 2017

Now I'm very confused. I had it compiling fine... I thought.

ibabushkin added a commit to ibabushkin/rust that referenced this issue Jun 13, 2017
External spans: Added a test for rust-lang#38875.
A bug has been discovered and fixed in the process.
bors added a commit that referenced this issue Jun 18, 2017
Auto merge of #42593 - ibabushkin:on-demand-external-source, r=eddyb
Implement lazy loading of external crates' sources. Fixes #38875

This is a follow-up to #42507. When a (now correctly translated) span from an external crate is referenced in a error, warning or info message, we still don't have the source code being referenced.
Since stuffing the source in the serialized metadata of an rlib is extremely wasteful, the following scheme has been implemented:

* File maps now contain a source hash that gets serialized as well.
* When a span is rendered in a message, the source hash in the corresponding file map(s) is used to try and load the source from the corresponding file on disk. If the file is not found or the hashes don't match, the failed attempt is recorded (and not retried).
* The machinery fetching source lines from file maps is augmented to use the lazily loaded external source as a secondary fallback for file maps belonging to external crates.

This required a small change to the expected stderr of one UI test (it now renders a span, where previously was none).

Further work can be done based on this - some of the machinery previously used to hide external spans is possibly obsolete and the hashing code can be reused in different places as well.

r? @eddyb
bors added a commit that referenced this issue Jun 18, 2017
Auto merge of #42593 - ibabushkin:on-demand-external-source, r=eddyb
Implement lazy loading of external crates' sources. Fixes #38875

Fixes #38875. This is a follow-up to #42507. When a (now correctly translated) span from an external crate is referenced in a error, warning or info message, we still don't have the source code being referenced.
Since stuffing the source in the serialized metadata of an rlib is extremely wasteful, the following scheme has been implemented:

* File maps now contain a source hash that gets serialized as well.
* When a span is rendered in a message, the source hash in the corresponding file map(s) is used to try and load the source from the corresponding file on disk. If the file is not found or the hashes don't match, the failed attempt is recorded (and not retried).
* The machinery fetching source lines from file maps is augmented to use the lazily loaded external source as a secondary fallback for file maps belonging to external crates.

This required a small change to the expected stderr of one UI test (it now renders a span, where previously was none).

Further work can be done based on this - some of the machinery previously used to hide external spans is possibly obsolete and the hashing code can be reused in different places as well.

r? @eddyb

@bors bors closed this in #42593 Jun 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.