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

ICE when non-const in const path. #28172

Closed
ghost opened this issue Sep 2, 2015 · 9 comments
Closed

ICE when non-const in const path. #28172

ghost opened this issue Sep 2, 2015 · 9 comments
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@ghost
Copy link

ghost commented Sep 2, 2015

This is that backtrace and error.

ico@arch ted $ cargo run
   Compiling ted v0.1.0 (file:///home/ico/code/projects/ted)
src/text/buffer.rs:112:21: 112:27 error: paths in constants may only refer to constants or functions [E0014]
src/text/buffer.rs:112             0.0 ... vwidth => {
                                           ^~~~~~
src/text/buffer.rs:112:21: 112:27 help: run `rustc --explain E0014` to see a detailed explanation
src/text/buffer.rs:112:21: 112:27 error: non-constant path in constant expr
src/text/buffer.rs:112             0.0 ... vwidth => {
                                           ^~~~~~
src/text/buffer.rs:112:13: 112:20 error: internal compiler error: literals of different types in range pat
src/text/buffer.rs:112             0.0 ... vwidth => {
                                   ^~~~~~~
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'Box<Any>', ../src/libsyntax/diagnostic.rs:176

stack backtrace:
   1:     0x7f461dc9b679 - sys::backtrace::write::h8f163fbc2fd53e94Gds
   2:     0x7f461dca3506 - panicking::on_panic::hf28d92e1ddd2bb33rex
   3:     0x7f461dc694ee - rt::unwind::begin_unwind_inner::hba29b41ea2e4f2655Gw
   4:     0x7f461ac6de17 - rt::unwind::begin_unwind::h12470989743939357431
   5:     0x7f461ac6ddd6 - diagnostic::SpanHandler::span_bug::hee88dc31e7766ce0kZA
   6:     0x7f461bb52d93 - session::Session::span_bug::he4c27021eec2e8b8W7v
   7:     0x7f461bc5698e - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_pat::h6fd474360a009684h2f
   8:     0x7f461bc5d8fe - visit::walk_arm::h14700536703337769097
   9:     0x7f461bc5d719 - visit::walk_expr::h10555032929647284522
  10:     0x7f461bc554f0 - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_expr::hd39087c11f22e55el6f
  11:     0x7f461bc572ba - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_block::hc9ec746ad3afb9d783f
  12:     0x7f461bc56009 - middle::check_const::CheckCrateVisitor<'a, 'tcx>::fn_like::closure.86088
  13:     0x7f461bc55c54 - middle::check_const::CheckCrateVisitor<'a, 'tcx>::fn_like::he12f169b1eb8f048AMf
  14:     0x7f461bc5b1ea - visit::walk_impl_item::h13192287562712281624
  15:     0x7f461bc5acd0 - visit::walk_item::h2458628646849006222
  16:     0x7f461bc5a4f0 - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_item::hee874e109ff405c7NWf
  17:     0x7f461bc5a8df - visit::walk_item::h2458628646849006222
  18:     0x7f461bc5a4f0 - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_item::hee874e109ff405c7NWf
  19:     0x7f461bc5a8df - visit::walk_item::h2458628646849006222
  20:     0x7f461bc5a4f0 - middle::check_const::CheckCrateVisitor<'a, 'tcx>.Visitor<'v>::visit_item::hee874e109ff405c7NWf
  21:     0x7f461bc6319a - middle::check_const::check_crate::h8c2477442470bbbdxDg
  22:     0x7f461e1e80e0 - driver::phase_3_run_analysis_passes::closure.20587
  23:     0x7f461e1c6e95 - middle::ty::ctxt<'tcx>::create_and_enter::h9762542764631600212
  24:     0x7f461e1c1ffd - driver::phase_3_run_analysis_passes::h5985136415815979015
  25:     0x7f461e1a5716 - driver::compile_input::hcbc3a92ec764e7e5Tba
  26:     0x7f461e31038b - run_compiler::h0a02618e9f046bf8Obc
  27:     0x7f461e30dc57 - boxed::F.FnBox<A>::call_box::h16881755907780588363
  28:     0x7f461e30d6c4 - rt::unwind::try::try_fn::h16221945257817858538
  29:     0x7f461dca30a8 - __rust_try
  30:     0x7f461dc8f902 - rt::unwind::try::inner_try::h9ca0fee771d29e74YCw
  31:     0x7f461e30d858 - boxed::F.FnBox<A>::call_box::h16992707776166869464
  32:     0x7f461dca24f3 - sys::thread::Thread::new::thread_start::hda9462d1945ff67eLMv
  33:     0x7f46178a74a3 - start_thread
  34:     0x7f461d92d12c - clone
  35:                0x0 - <unknown>

Could not compile `ted`.

To learn more, run the command again with --verbose.
ico@arch ted $

This is the code that caused it.

fn next_letter_position(&self, x_index: f32, y_index: f32, width: f32) -> (f32, f32) {
    let vwidth = &self.viewport.x / 2.0;

    match x_index * width {
        0.0 ... vwidth => {
            (x_index + 1.0, y_index)
        },
        _ => (0.0, y_index - 1.0)
    }
}

rustc version

 rustc 1.4.0-nightly (10d69db0a 2015-08-23)
@huonw huonw added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Sep 2, 2015
@alexispurslane
Copy link
Contributor

I managed to reproduce this bug, and found it can be avoided by making vwidth constant.

@alexispurslane
Copy link
Contributor

It looks like rust throws an ICE when it can't compare values in a range, here:

...
                match const_eval::compare_lit_exprs(self.tcx, start, end) {
                    Some(Ordering::Less) |
                    Some(Ordering::Equal) => {}
                    Some(Ordering::Greater) => {
                        span_err!(self.tcx.sess, start.span, E0030,
                            "lower range bound must be less than or equal to upper");
                    }
                    None => {
                        self.tcx.sess.span_bug(
                            start.span, "literals of different types in range pat");
                    }
                }
...

Edit: This is in librustc/middle/check_const.rs, lines 372-383

@alexispurslane
Copy link
Contributor

Maybe self.tcx.sess.span_bug should be changed to span_err! to make it a non-ICE. If I do, what E00 should it be? E0014?

@arielb1
Copy link
Contributor

arielb1 commented Sep 2, 2015

@ChristopherDumas

An error message is already issued. It should just ignore it.

@alexispurslane
Copy link
Contributor

@arielb1 I'm not sure what you mean. It looks to me like span_bug throws an ICE, and span_err! just issues a compile warning/error.

@arielb1
Copy link
Contributor

arielb1 commented Sep 3, 2015

@ChristopherDumas

Right, but global_expr already emitted an error (paths in constants may only refer to constants or functions). You don't want to emit another one.

@alexispurslane
Copy link
Contributor

Ok i get it!

@alexispurslane
Copy link
Contributor

It turns out that the error is already caught in compare_lit_exprs, so visit_pat should ignore the error, and let compare_lit_exprs handle it. The reason for two errors is that there are multiple things wrong with @ivegotasthma's code.

@oli-obk
Copy link
Contributor

oli-obk commented Jan 26, 2017

this doesn't ice anymore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

5 participants