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 generating debuginfo for non-primitive const generics #86893

Closed
goffrie opened this issue Jul 5, 2021 · 2 comments · Fixed by #87082
Closed

ICE generating debuginfo for non-primitive const generics #86893

goffrie opened this issue Jul 5, 2021 · 2 comments · Fixed by #87082
Assignees
Labels
C-bug Category: This is a bug. F-const_generics `#![feature(const_generics)]` 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

@goffrie
Copy link
Contributor

goffrie commented Jul 5, 2021

Code

#![feature(const_generics)]
fn shuffle<const IDX: ()>() {}
pub fn foo() {
    shuffle::<{()}>();
}

Playground link

Meta

rustc --version --verbose:

rustc 1.55.0-nightly (b3d11f95c 2021-07-04)
binary: rustc
commit-hash: b3d11f95cc5dd687fdd185ce91e02ebe40e6f46b
commit-date: 2021-07-04
host: x86_64-unknown-linux-gnu
release: 1.55.0-nightly
LLVM version: 12.0.1

This ICE is a regression. Bisection implicates #85269.

Error output

warning: the feature `const_generics` is incomplete and may not be safe to use and/or cause compiler crashes
 --> src/lib.rs:1:12
  |
1 | #![feature(const_generics)]
  |            ^^^^^^^^^^^^^^
  |
  = note: `#[warn(incomplete_features)]` on by default
  = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information

error: internal compiler error: /rustc/b3d11f95cc5dd687fdd185ce91e02ebe40e6f46b/compiler/rustc_middle/src/ty/consts.rs:195:32: expected bits of (), got Const {
    ty: (),
    val: Value(
        ByRef {
            alloc: Allocation {
                bytes: [],
                relocations: Relocations(
                    SortedMap {
                        data: [],
                    },
                ),
                init_mask: InitMask {
                    blocks: [],
                    len: Size {
                        raw: 0,
                    },
                },
                align: Align {
                    pow2: 0,
                },
                mutability: Not,
                extra: (),
            },
            offset: Size {
                raw: 0,
            },
        },
    ),
}

thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1006:9

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.55.0-nightly (b3d11f95c 2021-07-04) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: aborting due to previous error; 1 warning emitted

error: could not compile `asdf`
Backtrace

stack backtrace:
   0: std::panicking::begin_panic
   1: std::panic::panic_any
   2: rustc_errors::HandlerInner::bug
   3: rustc_errors::Handler::bug
   4: rustc_middle::ty::context::tls::with_opt
   5: rustc_middle::util::bug::opt_span_bug_fmt
   6: rustc_middle::util::bug::bug_fmt
   7: rustc_codegen_ssa::debuginfo::type_names::push_generic_params_internal
   8: rustc_codegen_ssa::debuginfo::type_names::push_generic_params
   9: rustc_codegen_llvm::debuginfo::<impl rustc_codegen_ssa::traits::debuginfo::DebugInfoMethods for rustc_codegen_llvm::context::CodegenCx>::dbg_scope_fn::get_template_parameters
  10: rustc_codegen_llvm::debuginfo::<impl rustc_codegen_ssa::traits::debuginfo::DebugInfoMethods for rustc_codegen_llvm::context::CodegenCx>::dbg_scope_fn
  11: rustc_codegen_ssa::mir::codegen_mir
  12: rustc_codegen_ssa::base::codegen_instance
  13: <rustc_middle::mir::mono::MonoItem as rustc_codegen_ssa::mono_item::MonoItemExt>::define
  14: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
  15: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task
  16: rustc_codegen_llvm::base::compile_codegen_unit
  17: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  18: rustc_interface::passes::QueryContext::enter
  19: rustc_interface::queries::Queries::ongoing_codegen
  20: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  21: rustc_span::with_source_map
  22: rustc_interface::interface::create_compiler_and_run
  23: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

@goffrie goffrie added C-bug Category: This is a bug. 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. labels Jul 5, 2021
@goffrie
Copy link
Contributor Author

goffrie commented Jul 5, 2021

This also occurs with types like [u32; 2], causing e.g. packed_simd to break.

@jonas-schievink jonas-schievink added the F-const_generics `#![feature(const_generics)]` label Jul 5, 2021
@michaelwoerister michaelwoerister self-assigned this Jul 9, 2021
@michaelwoerister
Copy link
Member

I'll take a look.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jul 13, 2021
…-type-names-fix, r=oli-obk,wesleywiser

Handle non-integer const generic parameters in debuginfo type names.

This PR fixes an ICE introduced by rust-lang#85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits.

The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question, we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value.

The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully.

I'd be interested in ideas on how to do this better.

r? `@wesleywiser`

cc `@dpaoliello` (do you see any problems with this approach?)
cc `@Mark-Simulacrum` & `@nagisa` (who I've seen comment on debuginfo issues recently -- anyone else?)

Fixes rust-lang#86893
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jul 13, 2021
…-type-names-fix, r=oli-obk,wesleywiser

Handle non-integer const generic parameters in debuginfo type names.

This PR fixes an ICE introduced by rust-lang#85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits.

The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question, we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value.

The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully.

I'd be interested in ideas on how to do this better.

r? ``@wesleywiser``

cc ``@dpaoliello`` (do you see any problems with this approach?)
cc ``@Mark-Simulacrum`` & ``@nagisa`` (who I've seen comment on debuginfo issues recently -- anyone else?)

Fixes rust-lang#86893
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jul 13, 2021
…-type-names-fix, r=oli-obk,wesleywiser

Handle non-integer const generic parameters in debuginfo type names.

This PR fixes an ICE introduced by rust-lang#85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits.

The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question, we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value.

The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully.

I'd be interested in ideas on how to do this better.

r? ```@wesleywiser```

cc ```@dpaoliello``` (do you see any problems with this approach?)
cc ```@Mark-Simulacrum``` & ```@nagisa``` (who I've seen comment on debuginfo issues recently -- anyone else?)

Fixes rust-lang#86893
@bors bors closed this as completed in 4f0c568 Jul 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. F-const_generics `#![feature(const_generics)]` 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.

3 participants