Overflow in span subtraction / astencode #23115
Labels
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Comments
|
exciting! Another entry for the bug log. |
|
Got similar error but with different caller.
|
|
(hopefully) |
|
@isurakka What was the code you were compiling? Perhaps the following lines: should be That would explain why this underflow didn't break anything before. I've never seen an underflowed span in rustc output. The function was introduced in #22235, @michaelwoerister do you think that the above fix is enough? |
|
I was compiling glium. |
|
@Manishearth Normally this should not make a difference, since at this point Anyway, I actually would not swap the additions and subtractions here. It would probably get rid of the underflow, but we actually want to fail immediately here instead of hiding the error. Something has to be wrong with either the input data (span and/or filemap) or with the binary search determining the filemap index. |
Yeah, that's what I was unsure of. I might have a look at this later (not now, busy) |
|
@Manishearth That would be great. I won't have time to look into this until Wednesday. |
|
I've taken a short look at this but I'm having a hard time reproducing the ICE. |
steveklabnik
added
the
I-ICE
|
Hi, guys, I faced with the same issue when tried to use "pub use"ed structs in my integration test src/lib.rs #[macro_use]
mod lexer;
#[macro_use]
pub mod expr;
#[macro_use]
mod parser;
mod scope;
pub use parser::Parser;
pub use scope::Scope;tests/lib.rs #[macro_use]
extern crate lust;
use lust::{Parser, Scope};
#[test]
fn test_macro_expansion() {
let ref mut scope = Scope::new_std();
let input = "(def m (macro (a) '(+ 1 ~a)))";
let expr = Parser::new(input.chars())
.parse().ok().unwrap()
.expand(scope).ok().unwrap()
.eval(scope).ok().unwrap();
....Line let expr = Parser::new(input.chars())causes a backtrace Everything was fine with this code until I updated to the latest nightly. Versions of cargo and rustc Hope this will help to reproduce the bug. |
|
There seem to be several crates which have this ICE:
|
|
I've allocated today for looking into this... |
|
I'm making some progress on this. It seems that |
|
OK, so here's the problem, the parser contains code like the following: // from Parser::parse_more_binops
let lhs_span = lhs.span;
let rhs_span = rhs.span;
let binary = self.mk_binary(codemap::respan(cur_op_span, cur_op), lhs, rhs);
let bin = self.mk_expr(lhs_span.lo, rhs_span.hi, binary);Now, in the case of macros In the expansion of the macro, |
|
@michaelwoerister yeah I remember when I discovered that the supposed We probably should try to put in tests that deliberate exercise cases like this (perhaps by even directly constructing such spans, rather than relying on the particulars of how certain patterns of source code are parsed). |
|
We could just put a debug-assert (or some sort of assert that doesn't reach the nightlies) in |
|
@Manishearth I don't think that's a good idea for the short term. I tried to put in such an assertion some time ago, and its a real rat hole. (That is why I instead suggested that we put in some tests that exercise such strange spans instead.) |
|
Ah, so should we not be relying on this assumption about spans? That seems like a bigger rat hole to be honest :/ |
|
(but then again, I am not going to object if someone else wants to put into the effort necessary to try to enforce |
|
I would have liked to tackle this as part of a bigger reform of span representation along the lines I described here: http://internals.rust-lang.org/t/rfc-compiler-refactoring-spans/1357/23 I guess this kind of thing can happen anywhere where some AST node span is constructed from the spans of the node's children, respectively whenever a child-node span also constitutes a border of the parent-node. That's the case for many things: // binary operators
$e1 + $e2
// unary operators
! $e
// closures
|x| $e
// parameters
fn foo($e: $t) {}
// type parameters
fn bar<$ident: $type>
// type ascription
$e : $type
// path expressions (?)
$x::foo()
// C-style enums
enum Foo {
$ident = $e,
}
// derived types
& &mut $t
// call expressions (?)
$e()
// ... and who knows what else ...Handling all these cases in the parser is definitely quite a bit of work. It's also not entirely clear how to handle this. I would suggest that spans that are partly in a macro are defined completely in the macro. That is, for the example above, the ...regardless of where |
|
I opened an issue (#23480) describing the underlying problem. In order to get rid of this ICE I will create a temporary workaround, probably validating spans before they get exported. This may lead to some strange debuginfo-source locations when macros are involved but not worse than is already the case. |
Manishearth
added a commit
to Manishearth/rust
that referenced
this issue
Mar 20, 2015
…erflow-bug, r=alexcrichton This should solve issues rust-lang#23115, rust-lang#23469, and rust-lang#23407. As the title says, this is just a workaround. The underlying problem is that macro expansion can produce invalid spans. I've opened issue rust-lang#23480 so we don't forget about that.
|
@Manishearth This should be fixed already. Please close if you can verify. |
|
Seems to be. Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://travis-ci.org/GuillaumeGomez/rust-GSL/builds/53335854
Offending code:
and the code calling it:
We might want a bounds check there (resolving to 0?), but there seems to be something broken in the astencode code too.
cc @GuillaumeGomez @pnkfelix
The text was updated successfully, but these errors were encountered: