-
Notifications
You must be signed in to change notification settings - Fork 13k
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
rustc panic: Type parameter R/#1
(R/1) out of range when substituting...
#58987
Comments
I ran into a very similar ICE on the following code: use std::mem;
fn foo<T: ?Sized>(t: T) {
let _ = [(); 0 - !(mem::size_of::<&T>() == mem::size_of::<[usize; 2]>()) as usize];
} I'm not 100% sure they originate from the same bug. But I would assume so given the similarities in backtraces. Here is my stacktrace from trying to build on
|
Here's another repro case I came across:
The function call used as the array size doesn't have to be an intrinsic, or even a Full stack trace (rustc 1.34.0 stable, MacOS 10.12.6):
|
Does not seam to even require a function: #![feature(const_generics)]
struct NibblePack<const N: usize> ([u8; N / 1]); Playground: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=18a496cff8cef0ae5f57d52a69d4a92a Backtrace:
|
Other repo cases: #64048 |
I came across this error too. My code: pub struct Matrix<T, const R: usize, const C: usize> {
inner: [T; R * C]
} When compile, error occurred:
Rust version:
|
I believe this is another instance of the error: #![feature(const_generics)]
#![feature(const_compare_raw_pointers)]
fn func<A, const F: fn(inner: A)>(outer: A) {
F(outer);
} Backtrace:
Version:
|
Example in #58987 (comment) no longer ICEs as of #70452 #58987 (comment) still ICEs |
@aedoq Uh oh that's a bug in const generics, type parameters aren't in scope for As for the other examples, I feel like this issue is just a duplicate of #43408. |
@Alexendoo that's expected, #70452 only fixed repeat expressions ( |
This code produces ICE on both stable and nightly: fn foo<T: ?Sized>(ptr: *const T) {
let mut ptr_parts: [usize; std::mem::size_of::<*const T>() / std::mem::size_of::<usize>()]
= unsafe { std::mem::transmute(ptr) };
} Looks related to the issue. |
@vnetserg Yeah, that's textbook #43408. You can check by adding I am closing this issue as a duplicate of #43408 (which by this point should have "array lengths" in its title renamed to "type-level constants"). @varkor @yodaldevoid we still need to open an issue for @aedoq's example in #58987 (comment) |
Opened #71611. |
Please see this repo for more details. Commit 628894b, which is the only commit at this time, as I created the repo specifically for this issue. It's an in progress library with a lot of early experimentation in it.
Below is the compiler and build information. Based on the information, it appears the problem has to do
with rust's in-progress
const
semantics, although I might not know what I'm talking about. I just knowthat my use of
const
and generics in this library is fairly atypical (or at least I believe it to be),so it makes sense to me that the problem lies there.
I apologize for the state of this code base. It has no comments, no tests, and is full of experimentation
code to see what will compile and what won't. I did at least clean up all the warnings before posting
this, to make life a bit easier. It is a one-man hobby project, and I am still relatively new to rust. A
lot of the code here is my personal translation of C++ meta programming over to rust.
A note to keep in mind: Everything compiled until I added the threading code for
AsyncIO
insrc/detail/io.rs, which I find interesting since it appears to be complaining about something that
previously compiled with no problem, and is unrelated to the threading code.
Also note that if the compiler did not panic, there is a good chance there is something actually wrong
with the code that would fail to compile, which would be something in src/detail/io.rs.
The text was updated successfully, but these errors were encountered: