Rust: const index out-of-bound 조건을 더 일찍 보고하십시오.

분명히 이것이 생성하는 "오류"는 컴파일 실패를 일으키지 않습니다. 코드가 생성되고 rustc는 0을 반환합니다. 인덱스가 물리적으로 범위를 벗어나면 LLVM은 불평할 것이며, 이는 현재 항상 범위를 벗어난 것과 동일합니다. index (내 생각에) 하지만 const 슬라이스의 경우에는 그렇지 않습니다.

이것은 테스트 중에 특히 예상치 못한 일이며(빠른 확인을 제외하고는 분명히?) 성공 시 출력/오류를 표시하지 않습니다.

0.6에서는 중요하지 않습니다. 디마일스톤

마일스톤 5 후보 지명, 생산 준비 완료

생산 준비 이정표 승인

이것이 이야기하고 있다고 생각하는 것의 예는 다음과 같습니다.

static a: &'static [int] = &[];
static b: int = a[1];

fn main() {}

수익률

$ rustc foo.rs
foo.rs:2:16: 2:19 error: const index-expr is out of bounds
foo.rs:2 static b: int = a[1];
                         ^~~
Assertion failed: (ReqTy && "extractvalue indices invalid!"), function getExtractValue, file ../../../../src/llvm/lib/IR/Constants.cpp, line 1982.
zsh: abort      rustc foo.rs

우리가 LLVM 주장을 하고 있는 것이 나쁜 것 같습니다.

P-low에 대해 허용됩니다.

분류: @alexcrichton 의 (9개월 된) 예제는 여전히 구문적으로 유효하며(예!) 해당 주장과 함께 여전히 실패합니다(우!).

나는 이것이 믿습니다 고정 .

@alexcrichton 의 예를 업데이트하는 경우:

#![allow(dead_code)]
const A: &'static [usize] = &[];
const B: usize = A[1];

fn main() {}

이제 불만 없이 성공적으로 컴파일됩니다.

잘못된 값 B 을 사용하려고 시도하면 rustc 에 문제가 발생합니다.

#![allow(dead_code)]
const A: &'static [usize] = &[];
const B: usize = A[1];

fn main() {
    println!("B={}", B);
}

<anon>:3:18: 3:22 error: const index-expr is out of bounds
<anon>:3 const B: usize = A[1];
                          ^~~~
rustc: /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/IR/Constants.cpp:2174: static llvm::Constant* llvm::ConstantExpr::getExtractValue(llvm::Constant*, llvm::ArrayRef<unsigned int>, llvm::Type*): Assertion `ReqTy && "extractvalue indices invalid!"' failed.
Aborted (core dumped)
playpen: application terminated with error code 134

오류: 값으로 다른 통계를 참조할 수 없습니다. 대신 주소 연산자 또는 상수를 사용하십시오.

예, 좋은 것 같습니다.

잠깐, @JustAPerson 의 예는 나에게 좋지 않은 것 같습니다. 재개장.

나는 이것이 이제 실제로 수정되었다고 생각합니다.

$ cat foo.rs
#![allow(dead_code)]
const A: &'static [usize] = &[];
const B: usize = A[1];

fn main() {
    println!("B={}", B);
}
$ rustc foo.rs
foo.rs:3:18: 3:22 error: const index-expr is out of bounds
foo.rs:3 const B: usize = A[1];
                          ^~~~
error: aborting due to previous error
$ rustc --version
rustc 1.0.0-dev (a691f1eef 2015-04-15) (built 2015-04-15)

그래서 지난 11일 동안:

hello.rs:3:18: 3:22 error: const index-expr is out of bounds
hello.rs:3 const B: usize = A[1];
                            ^~~~
rustc: /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::SequentialType; Y = llvm::Type; typename llvm::cast_retty<X, Y*>::ret_type = llvm::SequentialType*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.

soooo는 이미 퇴보 한 것 같습니까?

헐 이건 내 실수였어 LLVM 어설션이 비활성화된 상태로 컴파일된 도구 모음을 사용하여 위의 보고서를 작성했습니다(기본값인지 몰랐습니다).

(안녕하세요, 저는 신규 이민자들이 E-easy 문제에 더 쉽게 접근할 수 있도록 돕기 위해 노력하고

LLVM 어설션이 비활성화된 상태로 컴파일된 도구 모음을 사용하여 위의 보고서를 작성했습니다(기본값인지 몰랐습니다).

이 문제를 재현하려면 기본값이 아닌 설정으로 컴파일된 도구 모음을 사용해야 하는 것 같습니까? 그렇다면 어떻게 해야 할까요?

여기에서 무슨 일이 일어나기로 되어 있는지 혼란스럽습니다. 모든 마감-재개봉 일이 진행 중입니다. 누군가가 예상되는 동작이 무엇이며 현재 동작과 어떻게 다른지 명확히 할 수 있습니까?

./configure --enable-llvm-assertions

그러나 LLVM 주장이 활성화되어 있기 때문에 Rust를 밤마다 사용할 수 있습니다. http://is.gd/X2RztV는 여전히 야간에 어설션에 실패합니다.

<anon>:2:17: 2:21 error: const index-expr is out of bounds
<anon>:2 static b: i32 = a[1];
                         ^~~~
rustc: /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::SequentialType; Y = llvm::Type; typename llvm::cast_retty<X, Y*>::ret_type = llvm::SequentialType*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
Aborted (core dumped)
playpen: application terminated with error code 134

2013년에 고민했던 것이 수정된 것 같습니다. 만약 Rustc가 const index-expr is out of bounds 오류를 제공하면 LLVM 주장이 비활성화되어도 실패 상태로 종료됩니다(출력 파일을 작성하지 않음). 검사에서 누락된 오류를 찾을 수 없어야 했기 때문에 검사가 수행하는 세션/오류 항목에 대한 액세스 권한이 번역에 없었다고 생각합니다. 하지만 지금은 그렇지 않은 것 같습니다.

내 과거 자신이 언급한 또 다른 것은... 범위를 벗어났다는 것을 알면서도 인덱스를 LLVM에 전달하는 것처럼 들렸지만 이제는 대신 undef 합니다. 하지만 지금은 그 오류가 제대로 처리되었기 때문에 어떤 경우에도 그 부분은 처리됩니다.

오늘 우리가 보고 있는 LLVM 주장에 대해 추측할 수 있습니다. 오류를 보고한 후 다음을 수행합니다.

C_undef(type_of::type_of(cx, bt).element_type())

그리고 나는 우리가 다음과 같은 것을 원한다고 생각합니다(테스트되지 않음).

C_undef(val_ty(arr).element_type())

인덱싱되는 값이 슬라이스 또는 포인터인 경우 bt (해당 유형)는 배열 유형으로 표시되지 않으므로 element_type 가 실패합니다.

그러나 @graydon 이 이 문제를

나는 이것이 지금 완전히 고쳐졌다고 생각한다. @oli-obk?

아니요, check_const 에서 해결해야 하고 현재 보고 위치를 버그 위치로 변경해야 합니다.

@oli-obk 이것은 쉬운 픽스인가요? 그렇다면 멘토링을 하고 새로운 사용자가 크랙을 시도할 수 있도록 힌트를 남겨주시겠습니까?

쉬운 수정이지만(기본적으로 https://github.com/rust-lang/rust/blob/master/src/librustc/middle/check_const.rs#L470-L490을 훔쳐 ExprIndex 수행할 수 있습니다 unimplemented!() 바꿉니다.

그러나 사용하지 않은 const ARR: [u32; 0] = []; const X: u32 = ARR[5]; 현재 컴파일 오류를 일으키지 않기 때문에 이는 또한 획기적인 변경이 될 것입니다. 그리고 check_const 는 사용하지 않는 상수도 확인합니다.

또한 모든 const 평가를 두 번 수행하게 됩니다. 상수를 캐싱하여 문제가 되면 해결할 수 있습니다.

물론 const_err 보푸라기를 내보내는 것으로 주요 변경 사항을 해결할 수 있습니다.

이것은 LLVM 어설션이 아닌 사용 시 E0080 을 던지기 때문에 (MIRI로 인해) '해결된' 것으로 보입니다. 액세스가 사용되지 않으면 여전히 통과합니다.

const가 사용되지 않을 때 누락된 Lint는 https://github.com/rust-lang/rust/pull/50110에서 수정됩니다.

네, 6년 만에 이 문제를 끝낸 것 같아요.웃음: