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] C-variadic functions are only valid with one or more fixed arguments #63430

Closed
eddyb opened this issue Aug 10, 2019 · 3 comments · Fixed by #63459
Closed

[ICE] C-variadic functions are only valid with one or more fixed arguments #63430

eddyb opened this issue Aug 10, 2019 · 3 comments · Fixed by #63459
Labels
A-typesystem Area: The type system I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@eddyb
Copy link
Member

eddyb commented Aug 10, 2019

This ICEs (see title) because of the call:

extern {
    fn foo(...);
}

fn main() {
    unsafe { foo(1, 2, 3); }
}

That's because the definition of foo errored in 1.34, but doesn't since 1.35:

extern {
    fn foo(...);
}

cc @dlrobertson (found while working on #44930 (comment))

@Centril Centril added 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. I-nominated labels Aug 10, 2019
@eddyb eddyb added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. and removed I-nominated labels Aug 10, 2019
@Centril Centril added I-nominated A-typesystem Area: The type system labels Aug 10, 2019
@Centril
Copy link
Contributor

Centril commented Aug 10, 2019

Backtrace
Standard Error

   Compiling playground v0.0.1 (/playground)
error: internal compiler error: src/librustc_typeck/check/callee.rs:413: C-variadic functions are only valid with one or more fixed arguments
 --> src/main.rs:6:14
  |
6 |     unsafe { foo(1, 2, 3); }
  |              ^^^^^^^^^^^^

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:579:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: rustc::util::common::panic_hook
   7: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:481
   8: std::panicking::begin_panic
   9: rustc_errors::Handler::span_bug
  10: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  11: rustc::ty::context::tls::with_opt::{{closure}}
  12: rustc::ty::context::tls::with_context_opt
  13: rustc::ty::context::tls::with_opt
  14: rustc::util::bug::opt_span_bug_fmt
  15: rustc::util::bug::span_bug_fmt
  16: rustc_typeck::check::callee::<impl rustc_typeck::check::FnCtxt>::confirm_builtin_call
  17: rustc_typeck::check::callee::<impl rustc_typeck::check::FnCtxt>::check_call
  18: rustc_typeck::check::expr::<impl rustc_typeck::check::FnCtxt>::check_expr_with_expectation_and_needs
  19: rustc_typeck::check::FnCtxt::check_stmt
  20: rustc_typeck::check::FnCtxt::check_block_with_expected
  21: rustc_typeck::check::expr::<impl rustc_typeck::check::FnCtxt>::check_expr_with_expectation_and_needs
  22: rustc_typeck::check::FnCtxt::check_block_with_expected
  23: rustc_typeck::check::expr::<impl rustc_typeck::check::FnCtxt>::check_expr_with_expectation_and_needs
  24: rustc_typeck::check::expr::<impl rustc_typeck::check::FnCtxt>::check_return_expr
  25: rustc_typeck::check::check_fn
  26: rustc::ty::context::GlobalCtxt::enter_local
  27: rustc_typeck::check::typeck_tables_of
  28: rustc::ty::query::__query_compute::typeck_tables_of
  29: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::typeck_tables_of>::compute
  30: rustc::dep_graph::graph::DepGraph::with_task_impl
  31: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  32: rustc::ty::<impl rustc::ty::context::TyCtxt>::par_body_owners
  33: rustc_typeck::check::typeck_item_bodies
  34: rustc::ty::query::__query_compute::typeck_item_bodies
  35: rustc::dep_graph::graph::DepGraph::with_task_impl
  36: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  37: rustc::util::common::time
  38: rustc_typeck::check_crate
  39: rustc_interface::passes::analysis
  40: rustc::ty::query::__query_compute::analysis
  41: rustc::dep_graph::graph::DepGraph::with_task_impl
  42: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  43: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  44: rustc_interface::passes::create_global_ctxt::{{closure}}
  45: rustc_interface::interface::run_compiler_in_existing_thread_pool
  46: std::thread::local::LocalKey<T>::with
  47: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
query stack during panic:
#0 [typeck_tables_of] processing `main`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error


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.38.0-nightly (534b42394 2019-08-09) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type bin

@eddyb
Copy link
Member Author

eddyb commented Aug 10, 2019

Ah, the problem is that this wasn't updated (args now contains a CVarArgs):

if c_variadic && args.is_empty() {
self.span_err(sp,
"C-variadic function must be declared with at least one named argument");
}

Thankfully, at the same time, the ICE was added, so calls wouldn't have been possible to such functions.

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Aug 11, 2019
syntax: account for CVarArgs being in the argument list.

Fixes rust-lang#63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.

Note that the error has basically been impossible to trigger since the change that caused rust-lang#63430, so perhaps we need an audit of untested errors.

Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.

r? @petrochenkov cc @dlrobertson
@dlrobertson
Copy link
Contributor

Good catch

Centril added a commit to Centril/rust that referenced this issue Aug 12, 2019
syntax: account for CVarArgs being in the argument list.

Fixes rust-lang#63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.

Note that the error has basically been impossible to trigger since the change that caused rust-lang#63430, so perhaps we need an audit of untested errors.

Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.

r? @petrochenkov cc @dlrobertson
Centril added a commit to Centril/rust that referenced this issue Aug 13, 2019
syntax: account for CVarArgs being in the argument list.

Fixes rust-lang#63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.

Note that the error has basically been impossible to trigger since the change that caused rust-lang#63430, so perhaps we need an audit of untested errors.

Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.

r? @petrochenkov cc @dlrobertson
Centril added a commit to Centril/rust that referenced this issue Aug 13, 2019
syntax: account for CVarArgs being in the argument list.

Fixes rust-lang#63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.

Note that the error has basically been impossible to trigger since the change that caused rust-lang#63430, so perhaps we need an audit of untested errors.

Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.

r? @petrochenkov cc @dlrobertson
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Aug 14, 2019
syntax: account for CVarArgs being in the argument list.

Fixes rust-lang#63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.

Note that the error has basically been impossible to trigger since the change that caused rust-lang#63430, so perhaps we need an audit of untested errors.

Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.

r? @petrochenkov cc @dlrobertson
Centril added a commit to Centril/rust that referenced this issue Aug 14, 2019
syntax: account for CVarArgs being in the argument list.

Fixes rust-lang#63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.

Note that the error has basically been impossible to trigger since the change that caused rust-lang#63430, so perhaps we need an audit of untested errors.

Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.

r? @petrochenkov cc @dlrobertson
Centril added a commit to Centril/rust that referenced this issue Aug 14, 2019
syntax: account for CVarArgs being in the argument list.

Fixes rust-lang#63430 by testing for `1` argument (the `CVarArgs` itself) instead of `0`.

Note that the error has basically been impossible to trigger since the change that caused rust-lang#63430, so perhaps we need an audit of untested errors.

Also, this check probably belongs in AST validation/HIR lowering, but I'd rather fix it in place for now.

r? @petrochenkov cc @dlrobertson
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-stable Performance or correctness regression from one stable version to another. 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.

3 participants