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

Global const expr with macro causes compiler panic #29093

Closed
leeopop opened this issue Oct 16, 2015 · 4 comments · Fixed by #41055
Closed

Global const expr with macro causes compiler panic #29093

leeopop opened this issue Oct 16, 2015 · 4 comments · Fixed by #41055
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@leeopop
Copy link
Contributor

leeopop commented Oct 16, 2015

I would like to have compile-time evaluation of my const values
from the environment variables.
I wonder whether I had some grammar mistakes, however the compiler panics.
This occurs all stable, beta, and nightly versions (from play.rust-lang.org).

I tried this code:

const DEFAULT_PACKET_BUFFER_SIZE : usize = 2048;

pub const PACKET_BUFFER_SIZE : usize = match option_env!("PACKET_BUFFER_SIZE") {
    None => DEFAULT_PACKET_BUFFER_SIZE,
    Some(num_str) => {
        match num_str.parse::<usize>() {
            Ok(num) => {
                match num.is_power_of_two() {
                    true => num,
                    _ => DEFAULT_PACKET_BUFFER_SIZE,
                }
                },
            _ => { DEFAULT_PACKET_BUFFER_SIZE },
        }
    }
};

fn main()
{
    println!("{}",DEFAULT_PACKET_BUFFER_SIZE);
}

I expected to see this happen:
compiles with environment variables, statically evaluated.

Instead, this happened:
compiler panic.

Meta

PS C:\workspace\git\FPS\src> cargo build --verbose
       Fresh winapi v0.2.4
       Fresh rustc-serialize v0.3.16
       Fresh libc v0.1.10
       Fresh winapi-build v0.1.1
       Fresh advapi32-sys v0.1.2
       Fresh rand v0.3.11
       Fresh num v0.1.27
   Compiling FPS v0.0.0 (file:///C:/workspace/git/FPS)
     Running `rustc lib.rs --crate-name fps --crate-type lib -g --out-dir C:\workspace\git\FPS\target\debug --emit=dep-i
nfo,link -L dependency=C:\workspace\git\FPS\target\debug -L dependency=C:\workspace\git\FPS\target\debug\deps --extern i
log2=C:\workspace\git\FPS\target\debug\deps\libilog2-d6c9b6aa20d924f8.rlib`
       Fresh ilog2 v0.2.2
N\env.rs:5:10: 5:17 error: internal compiler error: no enclosing scope found for scope: Misc(13)
N\env.rs:5     Some(num_str) => {
                    ^~~~~~~
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
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', ../src/libsyntax\diagnostic.rs:176


Could not compile `FPS`.

Caused by:
  Process didn't exit successfully: `rustc lib.rs --crate-name fps --crate-type lib -g --out-dir C:\workspace\git\FPS\ta
rget\debug --emit=dep-info,link -L dependency=C:\workspace\git\FPS\target\debug -L dependency=C:\workspace\git\FPS\targe
t\debug\deps --extern ilog2=C:\workspace\git\FPS\target\debug\deps\libilog2-d6c9b6aa20d924f8.rlib` (exit code: 101)
PS C:\workspace\git\FPS\src>
PS C:\workspace\git\FPS\src> rustc --version --verbose
rustc 1.3.0 (9a92aaf19 2015-09-15)
binary: rustc
commit-hash: 9a92aaf19a64603b02b4130fe52958cc12488900
commit-date: 2015-09-15
host: x86_64-pc-windows-gnu
release: 1.3.0

http://puu.sh/kM1Yo/036518bf32.png

@cristicbz
Copy link
Contributor

So, first match is not implemented in const exprs :( i.e. in general this doesn't work:

const X: i32 = match Some(0) { _ => 10 };

The compiler panic doesn't require a macro, this will ICE in exactly same way:

pub const PACKET_BUFFER_SIZE : usize = match Some(10) {
    Some(x) => 1,
    None => 1,
};

playground

It seems that any binding inside the match will ICE instead of just giving the 'unsupported expression type in const expression' error.

@leeopop
Copy link
Contributor Author

leeopop commented Oct 16, 2015

@cristicbz BTW, How can I achieve my first intend?
Receiving number from environment, and use it as const expr (to use in array length).

@cristicbz
Copy link
Contributor

The problem is you can't get the value out of an Option at compile time; once we get const fn in stable (a limited type of compile time function evaluation), you'll be able to write option_env!("PACKET_SIZE").unwrap_or(DEFAULT_PACKET_SIZE). In the meantime I don't think there is any workaround for this :( . Maybe we should provide a option_env_or! macro, but that seems short sighted given const fn.

@leeopop
Copy link
Contributor Author

leeopop commented Oct 16, 2015

@cristicbz Thank you for your helpful comment :)

@steveklabnik steveklabnik added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Oct 29, 2015
ryan-scott-dev pushed a commit to ryan-scott-dev/rust that referenced this issue Apr 4, 2017
@brson brson added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 4, 2017
bors added a commit that referenced this issue Apr 8, 2017
…, r=arielb1

Fixed ICEs with pattern matching in const expression

Fixed 2 ICEs with when pattern matching inside a constant expression.

Both of these ICEs now resolve to an appropriate compiler error.

1. ICE was caused by a compiler bug to implement discriminant const qualify.

    I removed this intentionally thrown bug and changed it to a FIXME as the unimplemented expression type is handled as a compiler error elsewhere.

2. ICE was caused during a drop check when checking if a variable lifetime outlives the current scope if there was no parent scope .

    I've changed it to stop checking if there is no parent scope for the current scope. It is valid syntax for a const variable to be assigned a match expression with no enclosing scope.

    The ICE seemed to mainly be used as a defensive check for bugs elsewhere.

Fixes #38199.
Fixes #31577.
Fixes #29093.
Fixes #40012.
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) ❄️ 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.

4 participants