Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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-type-system Area: 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-type-system Area: 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.heygears.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.heygears.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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-type-system Area: 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