ICE: #cfg usage in a macro call

[kaczmarczyck]

I get an ICE when trying to use #[cfg(feature = "with_ctap2_1")] inside a map-like macro call.

I tried this code:

https://github.com/kaczmarczyck/OpenSK/commits/internal-compiler-error The last commit does NOT reproduce the error, but shows the 2 line diff to commit https://github.com/kaczmarczyck/OpenSK/commit/4fec405fb5bb1b986a8fbbb518d4fe88f4dbd38f that is reproducing the problem.

Please clone the branch above, run ./setup.sh if you want to check that everything works, then execute: RUST_BACKTRACE=1 cargo test --release --features std --verbose

I expected a regular compiler error (or a successful test).

Instead, the above mentioned ICE occurred.

Meta

rustc --version --verbose:

rustc 1.42.0-nightly (f43c34a13 2020-02-02)
binary: rustc
commit-hash: f43c34a134358471726f25fe5973b8c7e177c825
commit-date: 2020-02-02
host: x86_64-unknown-linux-gnu
release: 1.42.0-nightly
LLVM version: 9.0

Backtrace:

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/librustc_resolve/late.rs:1994:35
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1052
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1428
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
  12: rust_begin_unwind
             at src/libstd/panicking.rs:378
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  14: core::panicking::panic
             at src/libcore/panicking.rs:52
  15: rustc_resolve::late::LateResolutionVisitor::resolve_expr
  16: rustc_resolve::late::LateResolutionVisitor::resolve_expr
  17: <rustc_resolve::late::LateResolutionVisitor as syntax::visit::Visitor>::visit_block
  18: rustc_resolve::late::LateResolutionVisitor::resolve_expr
  19: <rustc_resolve::late::LateResolutionVisitor as syntax::visit::Visitor>::visit_local
  20: <rustc_resolve::late::LateResolutionVisitor as syntax::visit::Visitor>::visit_block
  21: <rustc_resolve::late::LateResolutionVisitor as syntax::visit::Visitor>::visit_fn
  22: syntax::visit::walk_item
  23: rustc_resolve::late::LateResolutionVisitor::resolve_item
  24: syntax::visit::walk_item
  25: rustc_resolve::late::LateResolutionVisitor::resolve_item
  26: syntax::visit::walk_item
  27: rustc_resolve::late::LateResolutionVisitor::resolve_item
  28: syntax::visit::walk_item
  29: rustc_resolve::late::LateResolutionVisitor::resolve_item
  30: syntax::visit::walk_crate
  31: rustc_resolve::Resolver::resolve_crate
  32: rustc_interface::passes::configure_and_expand_inner
  33: rustc_interface::passes::configure_and_expand::{{closure}}
  34: rustc_data_structures::box_region::PinnedGenerator<I,A,R>::new
  35: rustc_interface::passes::configure_and_expand
  36: rustc_interface::queries::Queries::expansion
  37: rustc_interface::interface::run_compiler_in_existing_thread_pool
  38: scoped_tls::ScopedKey<T>::set
  39: syntax::attr::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: internal compiler error: unexpected panic
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: rustc 1.42.0-nightly (f43c34a13 2020-02-02) running on x86_64-unknown-linux-gnu
note: compiler flags: -C opt-level=3
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
end of query stack
error: could not compile `ctap2`.

[jyn514]

You are using rustc 1.42.0-nightly (f43c34a13 2020-02-02) which is a nightly version several months out of date. Can you reproduce with 1.45.0 stable or the latest nightly?

I can't reproduce with your provided repository:

RUST_BACKTRACE=1 cargo test --release --features std --verbose
    Updating crates.io index
error: failed to get `libtock` as a dependency of package `ctap2 v0.1.0 (/home/joshua/src/OpenSK)`

Caused by:
  failed to load source for dependency `libtock`

Caused by:
  Unable to update /home/joshua/src/OpenSK/third_party/libtock-rs

Caused by:
  failed to read `/home/joshua/src/OpenSK/third_party/libtock-rs/Cargo.toml`

Caused by:
  No such file or directory (os error 2)

[spastorino]

I'm going to remove I-prioritize label but if @jyn514 is right, it seems that we should close this issue. Anyway, let's wait to hear from @kaczmarczyck to be 100% sure about it.

[ia0]

Here is a smaller self-contained example failing on 1.46.0-nightly:

// test.rs
use std::collections::BTreeMap;

#[derive(PartialEq, Eq, PartialOrd, Ord)]
struct KeyType;
struct Value;

trait IntoCborKey {
    fn into_cbor_key(self) -> KeyType;
}
trait IntoCborValue {
    fn into_cbor_value(self) -> Value;
}

impl IntoCborValue for i32 {
    fn into_cbor_value(self) -> Value {
        Value
    }
}

impl IntoCborKey for i32 {
    fn into_cbor_key(self) -> KeyType {
        KeyType
    }
}

macro_rules! cbor_map {
    ( $( $key:expr => $value:expr, )+ ) => {
        cbor_map! ( $($key => $value),+ )
    };

    ( $( $key:expr => $value:expr ),* ) => {
        {
            let mut _map = BTreeMap::new();
            $(
                _map.insert($key.into_cbor_key(), $value.into_cbor_value());
            )*
            _map
        }
    };
}

fn main() {
    let _ = cbor_map! {
        1 => 1,
        2 => 2,
        3 => 3,
        #[cfg(test)]
        4 => 4,
    };
}

% rustc test.rs
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/librustc_resolve/late.rs:2124:52
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

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: rustc 1.46.0-nightly (50fc24d8a 2020-06-25) running on x86_64-unknown-linux-gnu

[gendx]

@spastorino Is the minimal example provided by @ia0 sufficient to put back this issue in the I-prioritize queue?

---

I can't reproduce with your provided repository:

RUST_BACKTRACE=1 cargo test --release --features std --verbose
    Updating crates.io index
error: failed to get `libtock` as a dependency of package `ctap2 v0.1.0 (/home/joshua/src/OpenSK)`

Caused by:
  failed to load source for dependency `libtock`

Caused by:
  Unable to update /home/joshua/src/OpenSK/third_party/libtock-rs

Caused by:
  failed to read `/home/joshua/src/OpenSK/third_party/libtock-rs/Cargo.toml`

Caused by:
  No such file or directory (os error 2)

@jyn514 FYI, this error was due to a git submodule that must be initialized in that repository before starting the compilation.

[lcnr]

Further minimized

macro_rules! cbor_map {
    ($key:expr) => {
        $key.signum();
    };
}

fn main() {
    cbor_map! { #[cfg(test)] 4};
}

[petrochenkov]

This is a fun case.

AST represents receiver.method(args...) as MethodCall(PathSegment, Vec<P<Expr>>, Span) where the vector is [receiver, args...]. I.e. the parser does some light lowering into a semantic form by merging the receiver and arguments into a single list.

The parser shouldn't do that because it changes observable behavior. Expressions that are a part of a list can be cfg-ed away into nothing, the list just shrinks in that case, but you cannot do that with single expressions.

fn main() {
    let x = #[cfg(test)] 4; // error: removing an expression is not supported in this position
}

So, merging the receiver and the arguments loses the part-of-the-list-ness property and should not be done until HIR.

[spastorino]

Assigning P-medium as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.