1. 기능 게이트 추가
2. https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L347의 switch 및 switchInt 종결자는 사용자 정의 코드가 있어야 합니다. 기능 게이트가 활성화된 경우
3. 단일 현재 기본 블록(https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L328)을 갖는 대신 다음 목록이 있는 일부 컨테이너여야 합니다. 아직 처리해야 하는 기본 블록.

@oli-obk 복잡한 제어 흐름은 데이터 흐름 분석을 사용해야 하기 때문에 좀 더 까다롭습니다. @alexreg 로

@eddyb 좋은 출발점은 아마도 내 const-qualif 분기 를 가져 오고 (최상위 커밋 제외) 마스터 위에 리베이스한 다음(재미없을 예정임) 데이터 주석 항목을 추가하는 것입니다. 그렇죠?

이것에 대한 소식이 있습니까?

@mark-im 아아 아니. 지난 몇 주 동안 IRC에서 그를 핑(ping)할 수 없었기 때문에 @eddyb 는 참으로 매우 바빴습니다. 슬프게도 내 const-qualif 분기는 내가 master 위에 마지막으로 리베이스한 이후로 컴파일조차 되지 않습니다. (아직 밀었다는 게 믿기지 않는다.)

thread 'main' panicked at 'assertion failed: position <= slice.len()', libserialize/leb128.rs:97:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Could not compile `rustc_llvm`.

Caused by:
  process didn't exit successfully: `/Users/alex/Software/rust/build/bootstrap/debug/rustc --crate-name build_script_build librustc_llvm/build.rs --error-format json --crate-type bin --emit=dep-info,link -C opt-level=2 -C metadata=74f2a810ad96be1d -C extra-filename=-74f2a810ad96be1d --out-dir /Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/build/rustc_llvm-74f2a810ad96be1d -L dependency=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps --extern build_helper=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps/libbuild_helper-89aaac40d3077cd7.rlib --extern cc=/Users/alex/Software/rust/build/x86_64-apple-darwin/stage1-rustc/release/deps/libcc-ead7d4af4a69e776.rlib` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed
command did not execute successfully: "/Users/alex/Software/rust/build/x86_64-apple-darwin/stage0/bin/cargo" "build" "--target" "x86_64-apple-darwin" "-j" "8" "--release" "--manifest-path" "/Users/alex/Software/rust/src/librustc_trans/Cargo.toml" "--features" " jemalloc" "--message-format" "json"
expected success, got: exit code: 101
thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1085:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
failed to run: /Users/alex/Software/rust/build/bootstrap/debug/bootstrap -i build

좋아요, 재미있게도, 오늘 다시 베이스를 잡았고 지금은 잘 구축되고 있는 것 같습니다! 회귀가 있었던 것 같으며 방금 수정되었습니다. 이제 @eddyb 로

@alexreg 죄송합니다. 현지 수면 일정으로 변경했는데 제가 일어났을 때 당신이 저에게 핑을
당신의 지점에서 홍보를 해야 합니까? 우리가 그것으로 무엇을 해야 하는지 잊었습니까?

@eddyb 그렇군요 헤헤 . 나는 보통 GMT 오후 8시부터 시작하므로 일찍 잠자리에 들어야 합니다. 하지만 괜찮습니다! :-)

정말 죄송합니다. 문제의 일련의 패치가 Qualif::STATIC{,_REF} 제거해야 한다는 것을 깨닫는 데 시간이 걸렸습니다. 즉, 컴파일 타임에 정적 액세스에 대한 오류입니다. OTOH, 이것은 const fn s 및 static s에 대한 액세스 측면에서 이미 손상되었습니다.

#![feature(const_fn)]
const fn read<T: Copy>(x: &T) -> T { *x }
static FOO: u32 = read(&BAR);
static BAR: u32 = 5;
fn main() {
    println!("{}", FOO);
}

이것은 정적으로 감지되지 않고 대신 miri "dangling pointer was dereferenced"(이는 "dangling pointer" 대신 static s에 대해 실제로 말해야 함)에 대해 불평합니다.

그래서 나는 컴파일 타임에 static 읽는 것이 좋다고 생각하지만 어떤 사람들은 const fn 가 런타임에 "순수"(즉, "참조적으로 투명"하거나 그 정도)되기를 원합니다. const fn 인수가 괜찮로 얻은 참조 뒤에서 읽기하지만 const fn 에 대한 참조를 얻을 수해서는 안 static 밖으로 허공을 (를 포함하여 const ).

그러면 const , const fn 및 기타 상수 컨텍스트(승격 포함)에서 static 언급하는 것을 정적으로 거부할 수 있다고 생각합니다.
그러나 우리는 static 가 다른 static 의 참조를 가져오지만 (잘못 시도했지만 실패) 해당 참조 뒤에서 읽기 를 거부하는 STATIC_REF 해킹을 제거해야 합니다. .

이를 위해 RFC가 필요합니까?

정적에서 읽는 것이 공정하게 들립니다. RFC가 필요한지 의심이 들지만 아마도 분화구에서 뛰는 것일 수도 있지만 내가 말할 수 있는 최선은 아닐 것입니다.

우리 는 아무 것도 제한

아, 제가 잘못 읽었습니다. 따라서 const 평가는 여전히 건전하고 참조적으로 투명하지 않습니까?

마지막 단락은 참조적으로 투명한 접근 방식을 설명합니다(그러나 const s 및 const fn s에서 const static 언급하는 것을 허용하기 시작하면 해당 속성을 잃게 됩니다). 건전성에 대한 논의는 별로 없었던 것 같아요.

글쎄, "매달린 포인터"는 확실히 건전성 문제처럼 들리지만, 이것에 대해서는 당신을 믿겠습니다!

"dangling pointer"는 잘못된 오류 메시지이며 static 에서 읽기를 금지하는 것입니다. static 참조 할 수 있는 유일한 상수 컨텍스트는 다른 static . 따라서 해당 코드는 모두 컴파일 타임에 항상 한 번 실행되기 때문에 이러한 읽기를 "그냥" 허용할 수 있습니다.

(IRC에서) 요약하면 참조 투명 const fn 는 인수를 거치지 않고 고정 할당에만 도달할 수 있습니다. 즉, const 에는 동일한 제한이 필요하고 고정되지 않은 할당은 static 에서만 올 수 있습니다.

나는 @eddyb 의 아이디어가 환상적으로 들리도록 참조 투명성을 유지하는 것을 좋아합니다!

예, 저는 const fns도 순수하게 만드는 데 찬성합니다.

무해해 보이는 특정 계획은 참조 투명성을 망칠 수 있습니다. 예:

let x = 0;
let non_deterministic = &x as *const _ as usize;
if non_deterministic.count_ones() % 2 == 0 {
    // do one thing
} else {
    // do a completely different thing
}

이것은 컴파일 타임에 miri 오류로 실패하지만 런타임에는 비결정적입니다(미리처럼 해당 메모리 주소를 "추상"으로 표시할 수 없기 때문에).

편집 : @Centril 은 unsafe 내에서 특정 원시 포인터 작업(예: 비교 및 ​​정수로 변환)을 unsafe const fn ( const fn 안정화될 때까지 할 수 있음) ), 컴파일 타임에 미리가 허용하는 방식으로 만 사용할 수 있음을 명시합니다.
예를 들어, 두 포인터를 동일한 로컬로 빼는 것은 괜찮지만(유형 레이아웃, 배열 인덱스 등에 의존하는 상대 거리만 얻음) 참조 주소 형식 지정( {:p} ) 는 잘못된 사용이므로 fmt::Pointer::fmt 를 const fn 로 표시할 수 없습니다.
또한 원시 포인터에 대한 Ord / Eq 특성 impls는 안전하기 때문에 const 로 표시할 수 없습니다. 그러나 작업은 unsafe 에서 const fn 입니다.

"무해한"이란 말이 무엇을 의미하는지에 따라 다릅니다... 저는 우리가 그러한 비결정적 행동을 금지하려는 이유를 확실히 알 수 있습니다.

이 작업이 계속된다면 환상적일 것입니다.

@lachlansneff 움직이고 있습니다... 원하는 만큼 https://github.com/rust-lang/rust/pull/51110 에서 차단기를 기다리고 있습니다.

@alexreg 아, 감사합니다. 일치를 표시하거나 const fn에 있지 않을 때도 const로 표시할 수 있으면 매우 유용합니다.

#51110이 병합된 지금 상태 업데이트가 있습니까?

@programmerjake 병합되기 전에 https://github.com/rust-lang/rust/pull/52518 에서 @eddyb의 피드백을 기다리고 있습니다. 그는 최근에 매우 바빴습니다(항상 높은 수요가 있음). 그러나 그는 지난 며칠 동안 리뷰와 기타 등등으로 돌아왔습니다. 그래서 저는 희망적입니다. 그 후에는 적절한 데이터 흐름 분석을 추가하는 것이 복잡한 일이기 때문에 개인적으로 약간의 작업이 필요할 것입니다. 그래도 보자.

첫 번째 게시물의 TODO 목록 어딘가에 && 및 || 를 & 및 | 변환하는 현재의 끔찍한 해킹을 제거하기 위해 추가해야 합니다.

@RalfJung 이전 const eval의 일부가 아니

AFAIK 우리는 const_qualify 에 || / && 의해 생성될 SwitchInt 종결자를 거부하는 코드가 있기 때문에 HIR 낮추기의 어딘가에서 해당 번역을 수행합니다.

또한, 또 다른 요점: @oli-obk는 조건부가 순진하게 생각하는 것보다 어떻게 든 더 복잡하다고 어딘가에 (하지만 어디에서 찾을 수 없음) 말했습니다 ... 드롭 / 내부 변경 가능성에 대한 분석에 대한 "그냥"이었습니까?

낙하/내부 가변성에 대한 분석에 대한 "그냥"이었습니까?

나는 현재 그것을 지우려고 노력하고 있습니다. 모든 정보가 확보되면 다시 연락드리겠습니다.

이 상태는 어떻습니까? 인력이 필요한 걸까요, 아니면 문제 해결에 막힌 걸까요?

@mark-im const 자격에 대한 적절한 데이터 흐름 분석 구현이 차단되었습니다. @eddyb 는 이 분야에서 가장 지식이 풍부하며 이전에 이에 대한 작업을 수행했습니다. (나도 그랬지만 그런 종류의 정체는...) @RalfJung 이

58403은 데이터 흐름 기반 자격을 향한 작은 단계입니다.

@eddyb const fn 에서 참조 투명성을 유지한다고 언급했는데 좋은 생각이라고 생각합니다. const fn 에서 포인터를 사용하지 못하게 했다면? 따라서 이전 코드 샘플은 더 이상 컴파일되지 않습니다.

let x = 0;
// compile time error: cannot cast reference to pointer in `const fun`
let non_deterministic = &x as *const _ as usize;
if non_deterministic.count_ones() % 2 == 0 {
    // do one thing
} else {
    // do a completely different thing
}

참조는 계속 허용되지만 내부 검사는 허용되지 않습니다.

let x = 0;
let p = &x;
if *p != 0 {  // this is fine
    // do one thing
} else {
    // do a completely different thing
}

내가 완전히 기초에서 벗어나면 알려주십시오. 이것이 이것을 결정론적으로 만드는 좋은 방법이라고 생각했습니다.

@jyn514 는 이미 asize 캐스트를 불안정하게 만드는

이것에 대한 새로운 소식이 있습니까?

https://rust-lang.zulipchat.com/#narrow/stream/146212 -t-compiler.2Fconst-eval/topic/dataflow-based.20const.20qualification.20MVP에 대한 토론이 있습니다.

@oli-obk 링크가 작동하지 않습니다. 그것은 무엇을 말하는가?

그것은 나를 위해 작동합니다 ... 그러나 Zulip에 로그인해야합니다.

@alexreg 흠 예 데이터 흐름 기반 const 자격 작업에 관한 것이라고 가정합니다. @alexreg 상수에서 if 및 match에 필요한 이유를 알고 있습니까?

데이터 흐름 기반 버전이 없으면 실수로 상수 내부에서 &Cell<T> 허용하거나 실수로 None::<&Cell<T>> 금지합니다(안정에서 작동합니다. 데이터 흐름 없이 제대로 구현하는 것은 본질적으로 불가능합니다. 데이터 흐름의 잘못된 임시 버전이어야 함)

@est31 글쎄요, @oli-obk는 이것을 저보다 훨씬 더 잘 이해하고 있지만 상위 수준에서 기본적으로 분기와 관련된 모든 것은 당신이 많은 엣지 케이스를 원하지 않는 한 데이터 흐름 분석을 전제로 할 것입니다. 어쨌든, Zulip의 이 사람이 작업하려고 하는 것 같습니다. 만약 그렇지 않다면 oli-obk와 eddyb가 의도를 가지고 있다는 것을 압니다. 아마도 이번 달이나 다음(내가 그들에게 마지막으로 이야기했을 때부터)일 것입니다. '/그들을 대신하여 약속하지 않습니다.

@alexreg @mark-im @est31 @oli-obk 이번 주 언젠가 데이터 흐름 기반 const 자격의 WIP 구현을 게시할 수 있어야 합니다. 여기에는 많은 호환성 위험이 있으므로 실제로 병합하는 데 시간이 걸릴 수 있습니다.

감독자; 그것을 기대하다.

(요청당 #57563에서 복사)

bool && bool , bool || bool 등의 특수 케이스가 가능합니까? 현재 const fn 에서 수행할 수 있지만 그렇게 하려면 비트 연산자가 필요하며 이는 때때로 원하지 않습니다.

const 및 static 항목은 이미 특수 케이스로 되어 있습니다. 이를 비트 연산으로 변환합니다. 그러나 그 특수 케이스는 엄청난 해킹이며 이것이 실제로 올바른지 확인하기가 매우 어렵습니다. 당신이 말했듯이 때로는 원치 않는 경우도 있습니다. 따라서 이 작업을 더 자주 수행하지 않는 것이 좋습니다.

일을 올바르게 하는 것은 약간의 시간이 걸리지만 일어날 것입니다. 그 사이에 해킹을 너무 많이 하면 빠져나갈 수 없는 궁지에 몰리게 될 수도 있습니다(해당 해킹 중 일부가 잘못된 방식으로 상호 작용하여 실수로 원하지 않는 동작을 안정화하는 경우).

이제 #64470과 #63812가 병합되었으므로 이에 필요한 모든 도구가 컴파일러에 있습니다. 이 기능이 활성화된 상태에서 불필요하게 비효율적이지 않도록 const 자격과 관련된 쿼리 시스템을 약간 변경해야 합니다. 우리는 여기에서 진전을 이루고 있으며, 이것의 실험적 구현은 몇 달이 아니라 몇 주 안에 밤마다 사용할 수 있을 것이라고 믿습니다(유명한 마지막 단어:smile:).

@ecstatic-morse 반갑습니다! 이 작업을 수행하기 위해 협력해 주셔서 감사합니다. 저는 개인적으로 이 기능에 대해 잠시 동안 관심을 가지고 있었습니다.

이 작업이 완료된 후 CTFE에 대한 힙 할당 지원을 보고 싶습니다. 당신이나 다른 누군가가 이 작업에 관심이 있는지 모르겠지만 그렇지 않다면 내가 도울 수 있습니다.

@alexreg 감사합니다!

컴파일 시 힙 할당에 대한 논의는 rust-rfcs/const-eval#20에서 끝났습니다. AFAIK, 가장 최근의 발전은 주변에 있었다 ConstSafe / ConstRefSafe a의 최종 값의 참조 뒤에 / 직접 관찰 할 수있는 결정 패러다임 const . 그래도 디자인 작업이 더 필요하다고 생각합니다.

따라오는 사람들을 위해 #65949(그 자체가 몇 개의 더 작은 PR에 종속됨)가 이에 대한 다음 차단기입니다. 접선적으로만 관련이 있는 것처럼 보일 수 있지만 const-checking/qualification이 프로모션과 매우 밀접하게 연결되어 있다는 사실이 이 기능이 오랫동안 차단된 이유 중 일부였습니다. 나는 이전 const-checker를 완전히 제거하는 후속 PR을 열 계획입니다(현재 우리는 두 검사기를 병렬로 실행합니다). 이렇게 하면 앞서 언급한 비효율성을 피할 수 있습니다.

앞서 언급한 두 PR이 병합된 후 상수에서 if 및 match 는 몇 가지 진단 개선 사항과 기능 플래그가 제거됩니다! 아, 그리고 테스트도 많이 하고 테스트도 많이 하고...

테스트가 필요한 경우 어떻게 시작해야 할지 잘 모르겠지만 기꺼이 기여할 수 있습니다! 테스트가 어디로 가야 하는지/어떻게 생겼는지/어떤 브랜치를 기반으로 코드를 작성해야 하는지 알려주십시오. :)

다음 PR은 #66385입니다. 이렇게 하면 새 데이터 흐름 기반 버전을 위해 이전 const 자격 논리(분기를 처리할 수 없음)가 완전히 제거됩니다.

@jyn514 대단하군요 ! 구현 초안 작성을 시작할 때 ping을 보내드리겠습니다. 또한 야간에 if 및 match 가 사용 가능하면 사람들이 const 안전 (특히 HasMutInterior 부분)을 위반하려고 시도하는 것도 매우 도움이 됩니다.

66507에는 RFC 2342의 초기 구현이 포함되어 있습니다.

특히 진단과 관련하여 거친 가장자리를 제거하는 데 시간이 걸릴 것으로 예상하고 테스트 범위가 매우 희박합니다( @jyn514 해당 문제에 대해 조정해야 함). 그럼에도 불구하고 앞으로 몇 주 안에 기능 플래그 뒤에 이를 릴리스할 수 있기를 바랍니다.

이것은 #66507에서 구현되었으며 이제 최신 nightly 에서 사용할 수 있습니다. 새로 사용 가능한 작업과 내부 변경 가능성 또는 사용자 정의 Drop impl이 있는 유형과 관련된 기존 구현에서 발생할 수 있는 몇 가지 문제에 대해 자세히 설명하는 Inside Rust 블로그 게시물도 있습니다.

가서 구성하라!

평등이 const 아닌 것 같습니까? 아니면 내가 잘못 알고 있습니까?

error[E0019]: constant function contains unimplemented expression type
  --> src/liballoc/raw_vec.rs:55:22
   |
55 |         let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 };
   |                      ^^^^^^^^^^^^^^^^^^^^^^^^

error[E0019]: constant function contains unimplemented expression type
  --> src/liballoc/raw_vec.rs:55:19
   |
55 |         let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 };
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors

@mark-im 실제로 작동 해야

이것이 의도적인 것인지 확실하지 않지만 열거형과 일치시키려고 하면 오류가 발생합니다.

연결할 수 없는 코드가 있는 const fn이 안정적이지 않습니다.

열거형이 완전하고 동일한 상자에 정의되어 있음에도 불구하고.

@jhpratt 코드를 게시할 수 있습니까? 문제 없이 간단한 열거형에서 일치시킬 수 있습니다. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=585e9c2823afcb49c6682f69569c97ea

@jhpratt 코드를 게시할 수 있습니까? 문제 없이 간단한 열거형에서 일치시킬 수 있습니다.

여기:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=13a9fbc4251d7db80f5d63b1dc35a98b

몇 초만 이기세요. 그것은 나의 정확한 경우를 보여주는 최소한의 예입니다.

@jhpratt 확실히 의도한 것은 아닙니다. 문제를 열 ​​수 있습니까?

보고하려는 특정 기능 또는 문제의 구성을 새로운 문제로 리디렉션하고 F-const_if_match 적절하게 레이블을 지정하여 이 문제가 중요한 개발을 가리는 일시적인 댓글로 넘쳐나지 않도록 하십시오.

@Centril 당신의 댓글이 묻히지 않도록 상단 댓글에 넣는 것도 나쁘지 않습니다.

상태 업데이트:

이것은 구현 관점에서 안정화를 위한 준비가 되었지만 유형 기반(그러나 덜 강력함) 대신에 현재 가지고 있는 값 기반 데이터 흐름을 유지할 것인지에 대한 질문이 있습니다. 값 기반 데이터 흐름은 조금 더 비싸며(더 아래로 더 자세히 설명), 다음과 같은 기능에 필요합니다.

const fn foo<T>() {
    let x = Option::<T>::None;
    {x};
}

Option<T> 에는 현재 실행을 시도하고 따라서 비 const 코드를 실행할 수 있는 소멸자가 있을 수 있기 때문에 유형 기반 분석이 거부할 수 있습니다.

분기가 있는 순간 유형 기반 분석으로 대체할 수 있지만, 이는 우리가 거부한다는 것을 의미합니다.

const fn foo<T>(b: bool) {
    let x = Option::<T>::None;
    assert!(b);
    {x};
}

이것은 아마도 사용자들에게 매우 놀랄 것입니다.

@ecstatic-morse는 const fn뿐만 아니라 모든 기능에 대해 분석을 실행했으며 최대 5%의 속도 저하를 보았습니다(https://perf.rust-lang.org/compare.html?start=93dc97a85381cc52eb872d27e50e4d518926a27c&end=518926a27c&end=51cf46 이것은 const fn 가 되지도 않을 수도 없는 함수에서도 실행된다는 것을 의미하기 때문에 비관적인 버전입니다.

즉, const fn 함수를 많이 만들면 이 값 기반 분석으로 인해 컴파일 속도가 느려질 수 있습니다.

중간 근거는 유형 기반 분석이 실패한 경우에만 가치 기반 분석을 실행하는 것입니다. 즉, 소멸자가 없으면 존재하지 않는 소멸자가 실행되지 않는지 파악하기 위해 값 기반 분석을 실행할 필요가 없습니다(예, 여기에서 많은 부정). 다르게 표현하자면 소멸자가 있는 경우에만 가치 기반 분석을 실행합니다.

나는 이것을 @rust-lang/lang 토론을 위해 지명하여 우리가 함께 가고 싶은지 결정할 수 있습니다.

• 루프 또는 분기가 있는 경우 유형 기반 옵션(사용자에게 이상한 동작 제공)
• 전체 가치 기반 분석(더 비싸지만 사용자를 위한 완전한 표현력)
• 혼합 구성표, 여전히 사용자를 위한 완전한 표현, 일부 추가 impl 복잡성, 그러나 필요한 경우에 대해 컴파일 시간 문제를 줄여야 합니다.

@oli-obk

루프 또는 분기가 있는 경우 유형 기반 옵션(사용자에게 이상한 동작 제공)

이것을 확인하기 위해 : 직선 코드에서도 유형 기반 분석을하는 것은 옵션이 아닙니까? 우리가 이미 다음( 놀이터 )을 수락한다는 점을 감안할 때 이전 버전과 호환되지 않는다고 생각합니다.

struct Foo { }

impl Drop for Foo {
    fn drop(&mut self) { }
}

const T: Option<Foo> = None;

fn main() { }

개인적으로 사용자를 위해 더 일관되고 더 나은 경험을 제공해야 한다고 생각하는 경향이 있습니다. 우리는 필요에 따라 최적화할 수 있고 어떤 경우에도 비용이 그리 나쁘지 않은 것 같습니다. 하지만 이 더 비싼 분석에서 무슨 일이 일어나고 있는지 조금 더 정확히 이해하고 싶습니다. 기본적으로 "일정한 전파"를 수행하고 있다는 생각으로, 무언가가 떨어질 때마다 드롭되는 정확한 값을 분석하여 소멸자를 실행하는 데 필요한 값을 포함할 수 있습니까? (즉, None 인 경우 Option<T> 의 일반적인 예를 사용하기 위해)

이것을 확인하기 위해 : 직선 코드에서도 유형 기반 분석을하는 것은 옵션이 아닙니까? 우리가 이미 다음(놀이터)을 수락한다는 점을 감안할 때 이전 버전과 호환되지 않는 종류라고 생각합니다.

네, 이것이 우리가 완전히 유형 기반 분석으로 이동할 수 없는 이유입니다.

우리가 기본적으로 "일정한 전파"를 수행하고 있다는 아이디어가 무엇인가가 삭제될 때마다 삭제되는 정확한 값을 분석하여 소멸자를 실행하는 데 필요한 값을 포함할 수 있는지 여부를 결정하는 것입니까? (즉, None인 경우 Option의 일반적인 예를 사용하려면)

우리는 플래그 목록( Drop 및 Freeze , 설명하기 쉽기 때문에 여기에 Drop 표시했습니다)만 전파합니다. 우리가 도달하면 Drop 설정된하지 않고 종료를 Drop 깃발을 우리는 무시 Drop 종결을. 이렇게 하면 다음과 같은 코드가 허용됩니다.

{
    let mut x = None;
    // Drop flag for x: false
    let y = Some(Foo);
    // Drop flag for y: true
    x = y; // Dropping x is fine, because Drop flag for x is false
    // Drop flag for y: false, Drop flag for x: true
    x
    // Dropping y is fine, because Drop flag for y is false
}

평가 시에는 발생하지 않으므로 다음은 좋지 않습니다.

{
    let mut x = Some(Foo);
    if false {
        x = None;
    }
    x
}

가능한 모든 실행 경로로 인해 Drop 발생하지 않는지 확인합니다.

지속적인 전파는 좋은 비유입니다. 변수 간의 상태 복사를 처리하지 않는 gen/kill 세트로 전달 함수를 표현할 수 없는 또 다른 데이터 흐름 문제입니다. 그러나, 일정한 전파 각 변수의 실제 값을 저장해야하지만, CONST 검사뿐만 단일 비트가 변수가 지정되어 있는지 여부를 나타내는 저장해야 Drop IMPL 또는하지 Freeze 그것을 만들기 일정한 전파보다 약간 저렴합니다.

명확하게하기 위해, @ OLI-OBK의 첫 번째 예제 안정에 컴파일 오늘, 그리고 이후이 1.38.0 하지 않았다, # 64470를 포함한다.

게다가 const X: Option<Foo> = None; 는 1.0 이후로 컴파일되며, 다른 모든 것은 const eval이 얻은 새로운 기능과 함께 자연스럽게 확장된 것입니다.

네, 그렇다면 순전히 가치 기반 옵션을 채택하는 것이 합리적이라고 생각합니다.

우리가 회의에서 그것을 덮고 다시 보고할 수 있을 것 같아요 =)

요약

현재 의미 체계로 #![feature(const_if_match)] 를 안정화할 것을 제안합니다.

특히 if 및 match 표현식과 단락 논리 연산자 && 및 || 는 모든 const 컨텍스트 에서 유효

• const , static , static mut 또는 열거형 판별자의 이니셜라이저.
• const fn 의 본문입니다.
• const 제네릭의 값입니다(야간 전용).
• 배열 유형( [u8; 3] ) 또는 배열 반복 표현식( [0u8; 3] )의 길이입니다.

또한, 단락 논리 연산자는 더 이상 const 및 static 이니셜라이저에서 해당하는 비트 단위(각각 & 및 | )로 낮아지지 않습니다(참조 #57175). 결과적으로 let 바인딩은 해당 이니셜라이저에서 단락 논리와 함께 사용할 수 있습니다.

추적 문제: #49146
버전 대상: 1.45 (2020-06-16)

구현 이력

64470은 조건부 제어 흐름을 지원하고 데이터 흐름을 기반으로 하는 값 기반 정적 분석을 구현했습니다. 이것은 #63812와 함께 복잡한 제어 흐름 그래프에서 작동하는 오래된 const-checking 코드를 대체할 수 있게 해주었습니다. 기존 const-checker는 간단한 제어 흐름으로 프로그램에 동의하는지 확인하기 위해 데이터 흐름 기반의 것과 병렬로 한동안 실행되었습니다. #66385 데이터 흐름 기반을 위해 이전 const-checker를 제거했습니다.

66507은 현재 안정화를 위해 제안되고 있는 의미 체계로 #![feature(const_if_match)] 기능 게이트를 구현했습니다.

Const 자격

배경

[Miri]는 몇 년 동안 rustc 에서 CTFE(컴파일 타임 함수 평가)를 제공했으며 적어도 그 기간 동안 조건문을 평가할 수 있었습니다. CTFE 동안 우리는 사용자 정의 Drop impls를 호출 하거나 내부 변경 가능성이 있는 값에 대한 참조를 가져오는 것과 같은 특정 작업을 피해야 합니다. 집합적으로 이러한 부적격 속성을 "자격"이라고 하며, 프로그램의 특정 지점에서 값에 자격이 있는지 여부를 결정하는 프로세스를 "const 자격"이라고 합니다.

Miri는 규정된 값에 대해 잘못된 연산이 발생했을 때 오류를 완벽하게 내보낼 수 있으며 오탐 없이 그렇게 할 수 있습니다. 그러나 CTFE는 단형화 후 발생합니다. 즉, 다른 상자에서 발생할 수 있는 인스턴스화될 때까지 일반 컨텍스트에 정의된 상수가 유효한지 알 수 없습니다. pre-monomorphization 오류를 얻으려면 const 자격을 수행하는 정적 분석을 구현해야 합니다. 일반적인 경우 const 자격은 결정할 수 없으므로( Rice의 정리 참조) 모든 정적 분석은 Miri가 CTFE 동안 수행하는 검사에 대해서만 근사할 수 있습니다.

우리의 정적 분석은 내부 가변성이 있는 유형에 대한 참조(예: &Cell<i32> )가 const 의 최종 값에 나타나지 않도록 해야 합니다. 이것이 허용되면 런타임에 const 수정할 수 있습니다.

const X: &std::cell::Cell<i32> = std::cell::Cell::new(0);

fn main() {
  X.get(); // 0
  X.set(42);
  X.get(); // 42
}

그러나, 우리는 사용자가 정의 할 수 const 유형이 내부 가변성 (이 !Freeze 우리가 그 최종 값 증명할 수)만큼을 const 되지 않습니다. 예를 들어, 다음은 안정적인 녹의 초판 이후로 컴파일되었습니다.

const _X: Option<&'static std::cell::Cell<i32>> = None;

유형 기반이 아니라 값 기반이라고 부를 정적 분석에 대한 이 접근 방식은 사용자 정의 Drop impl이 호출될 수 있는 코드를 확인하는 데에도 사용됩니다. Drop impls를 호출하는 것은 const 확인되지 않고 const 컨텍스트에서 허용되지 않는 코드를 포함할 수 있기 때문에 문제가 됩니다. 가치 기반 추론이 let 문을 지원하도록 확장되었습니다. 즉, 다음 은 rust 1.42.0 stable 에서 컴파일됩니다 .

const _: Option<Vec<i32>> = {
  let x = None;
  let mut y = x;
  y = Some(Vec::new()); // Causes the old value in `y` to be dropped.
  y
};

현재 야간 의미 체계

#![feature(const_if_match)] 의 현재 동작은 데이터 흐름을 사용하여 복잡한 제어 흐름 그래프에서 작동하도록 값 기반 의미 체계를 확장합니다. 다시 말해서, 우리는 프로그램을 통해 가능한 모든 경로 를 따라 변수에 문제의 자격이 없음을 증명하려고 합니다.

enum Int {
    Zero,
    One,
    Many(String), // Dropping this variant is not allowed in a `const fn`...
}

// ...but the following code is legal under this proposal...
const fn good(x: i32) {
    let i = match x {
        0 => Int::Zero,
        1 => Int::One,
        _ => return,
    };

    // ...because `i` is never `Int::Many` on any possible path through the program.
    std::mem::drop(i);
}

프로그램을 통해 가능한 모든 경로에는 실제로 도달할 수 없는 경로가 포함됩니다. 위와 동일한 Int 열거형을 사용하는 예:

const fn bad(b: bool) {
    let i = if b == true {
        Int::One
    } else if b == false {
        Int::Zero
    } else {
        // This branch is dead code. It can never be reached in practice.
        // However, const qualification treats it as a possible path because it
        // exists in the source.
        Int::Many(String::new())
    };

    // ILLEGAL: `i` was assigned the `Int::Many` variant on at least one code path.
    std::mem::drop(i);
}

이 분석은 반환 값에 해당 유형의 값이 포함될 수 있다고 가정하고 함수 호출을 불투명하게 처리합니다. 또한 변수에 대한 변경 가능한 참조가 생성되는 즉시 변수에 대한 유형 기반 분석으로 대체합니다. const 컨텍스트에서 변경 가능한 참조를 만드는 것은 현재 안정적인 녹에서 금지되어 있습니다.

#![feature(const_mut_refs)]

const fn none() -> Option<Cell<i32>> {
    None
}

// ILLEGAL: We must assume that `none` may return any value of type `Option<Cell<i32>>`.
const BAD: &Option<Cell<i32>> = none();

const fn also_bad() {
    let x = Option::<Box<i32>>::None;

    let _ = &mut x;

    // ILLEGAL: because a mutable reference to `x` was created, we can no
    // longer assume anything about its value.
    std::mem::drop(x)
}

값 기반 분석이 내부 변경 가능성 및 사용자 지정 drop impls에 대해 보수적인 방법에 대한 더 많은 예와 보수적 분석이 테스트 스위트에서 불법적인 일이 발생할 수 없음 을 증명할 수 있는 일부 경우를

대안

기존 접근 방식에 대한 실용적이고 이전 버전과 호환되는 대안을 찾는 것이 어렵다는 것을 알게 되었습니다. const 컨텍스트에서 조건문이 사용되자마자 모든 변수에 대한 유형 기반 분석으로 대체할 수 있습니다. 그러나 이는 관련이 없어 보이는 추가로 인해 코드가 더 이상 컴파일되지 않게 되므로 사용자에게 설명하기 어려울 것입니다(예: @oli-obk의 다음 예제에서 assert .

const fn foo<T>(b: bool) {
    let x = Option::<T>::None;
    assert!(b);
    {x};
}

가치 기반 분석의 표현력 증가는 공짜가 아니다. const 뿐만 아니라 모든 항목 본문에 대해 const 자격을 수행한 perf 실행은 빌드 확인 에서 최대 const 로 만들어질 것이라고 가정하기 때문에 최악의 시나리오입니다. #71330에 있는 것과 같은 가능한 최적화는 스레드의 앞부분에서 논의되었습니다.

미래 작업

현재 const-checking은 drop elaboration 전에 실행됩니다. 즉, 실제로는 도달할 수 없는 일부 drop terminator가 MIR에 남아 있습니다. 이것은 Option::unwrap 가 const fn 가 되는 것을 방지합니다(#66753 참조). 이것은 해결하기가 그리 어렵지는 않지만 const-checking 패스를 두 단계(삭제 전 및 후 정교화)로 분할해야 합니다.

#![feature(const_if_match)] 가 안정화되면 많은 라이브러리 함수를 const fn 로 만들 수 있습니다. 여기에는 #53718에 열거된 원시 정수 유형에 대한 많은 메소드가 포함됩니다.

const 컨텍스트의 루프는 조건문과 동일한 const 자격 질문에서 차단됩니다. 현재 데이터 흐름 기반 접근 방식은 수정 없이 순환 CFG에도 작동하므로 #![feature(const_if_match)] 가 안정화되면 #52000에 대한 주요 차단기가 사라집니다.

감사의 말

특별 감사는 구현 대부분의 작업에 대한 기본 검토뿐만 아니라, 나를 const를 중심으로 관련 문제를 이해 돕는 @ 녹 LANG / WG-const를-평가의 나머지이었다 @ OLI-OBK와 @eddyb에 기인 자격. @solson이 만들고 현재 @RalfJung 과 @oli-obk가 유지 관리하는 Miri 없이는 이 모든 것이 불가능합니다.

이것은 FCP 이전의 안정화 보고서를 위한 것입니다. 그러나 FCP를 열 수 없습니다.

@ecstatic-morse 이 문제에 대한 모든 노고에 감사드립니다!

좋은 보고서!

내가 보고 싶다고 생각하는 한 가지는 @ecstatic-morse입니다.

• 동작을 관찰할 수 있도록 repo의 일부 대표적인 테스트에 대한 링크
• semver 또는 다른 것에 대한 의미가 있는지 여부 - 대답은 대체로 아니오 라고 생각합니다. 그렇죠? 즉, 우리는 const fn의 본문이 합법적인지 여부를 결정하는 데 사용되는 분석을 결정하지만 const fn이 주어지면 여기서 우리의 선택은 "const fn의 호출자가 수행할 수 있는 작업"과 같은 것을 결정하지 않습니다. 결과"라고요? 나는 내가 말하는 것의 예가 무엇인지 알아 내려고 노력 중입니다. 호출자는 열거 형의 어떤 변형이 사용되었는지 정확히 알지 못한다고 가정합니다. 값이 무엇이든 반환됨 -- 내부 변경 가능성이 없었습니다(매칭할 때 의존할 수 없기 때문에).

즉, 우리는 const fn의 본문이 합법적인지 여부를 결정하는 데 사용되는 분석을 결정하지만 const fn이 주어지면 여기서 우리의 선택은 "const fn의 호출자가 수행할 수 있는 작업"과 같은 것을 결정하지 않습니다. 결과"라고요? 나는 내가 말하는 것의 예가 무엇인지 알아 내려고 노력 중입니다. 호출자는 열거 형의 어떤 변형이 사용되었는지 정확히 알지 못한다고 가정합니다. 값이 무엇이든 반환됨 -- 내부 변경 가능성이 없었습니다(매칭할 때 의존할 수 없기 때문에).

예, const fn의 본문은 불투명합니다. 이는 const 항목의 이니셜라이저 표현식과 대조됩니다. 이라는 사실로 이것을 관찰할 수 있다.

const FOO: Option<Cell<i32>> = None;

&'static Option<Cell<i32>> 를 만드는 데 사용할 수 있습니다.

const BAR: &'static Option<Cell<i32>> = &FOO;

동일한 본문을 가진 const fn은 다음을 수행할 수 없습니다.

const fn foo() -> Option<Cell<i32>> { None }
const BAR: &'static Option<Cell<i32>> = &foo();

놀이터 데모

제어 흐름을 상수에 도입할 때 이는 다음을 의미합니다.

const FOO: Option<Cell<i32>> = if MEH { None } else { None };

MEH 값과 관계없이 작동합니다.

const FOO: Option<Cell<i32>> = if MEH { Some(Cell::new(42)) } else { None };

MEH 값과 관계없이 다시 작동하지 않습니다.

제어 흐름은 const fn 의 호출 사이트에 대해 아무 것도 변경하지 않으며 해당 const fn 내부에서 허용되는 코드에 대해서만 변경합니다.

리포지토리의 몇 가지 대표적인 테스트에 대한 링크를 통해 동작을 관찰할 수 있습니다.

흥미로운 테스트 사례로 연결되는 "Current Nightly Semantics" 섹션의 끝에 단락을 추가했습니다. 이것이 안정화되기 전에 더 많은 테스트(상황에 관계없이 사실인 진술)가 필요하다고 생각하지만, 현재 의미 체계가 바람직한지 여부를 결정하면 해결할 수 있습니다.

semver 또는 다른 것에 대한 의미가 있는지 여부.

위에서 @oli-obk가 말한 것 외에도 const 의 최종 값을 변경하는 것은 기술적으로 이미 상당한 변경 사항이라는 점을 지적하고 싶습니다.

// Upstream crate
const IDX: usize = 1; // Changing this to `3` will break downstream code!

// Downstream crate

extern crate upstream;

const X: i32 = [0, 1, 2][upstream::IDX]; // Only compiles if `upstream::IDX <= 2`

그러나 완벽한 정밀도로 const 한정을 수행할 수 없기 때문에 if 또는 match 를 사용하도록 상수를 변경하면 최종 값이 변경되지 않더라도 다운스트림 코드 가 손상

// Changing from `cfg` attributes...

#[cfg(not(FALSE))]
const X: Option<Vec<i32>> = None;
#[cfg(FALSE)]
const X: Option<Vec<i32>> = Some(Vec::new());

// ...to the `cfg` macro...

const X: Option<Vec<i32>> = if !cfg!(FALSE) { None } else { Some(Vec::new() };

// ...could break downstream crates, even though `X` is still `None`!

// Downstream

 // Only legal if static analysis can prove the qualifications in `X`
const _: () =  std::mem::drop(upstream::X); 

이것은 const fn 본문 내부의 변경 사항에는 적용되지 않습니다. 동일한 상자 내에서도 반환 값에 대해 항상 유형 기반 자격을 사용하기 때문입니다.

내 생각에 "원죄"는 외부 상자에 정의된 const 및 static 대한 유형 기반 자격으로 되돌아가지 않았습니다. 그러나 이것은 1.0부터 그랬다고 생각하고, 꽤 많은 코드가 그것에 의존하고 있다고 생각합니다. 정적 분석이 완벽하게 정확할 수 없는 const 이니셜라이저를 허용하자마자 정적 분석이 증명할 수 없는 동일한 값을 생성하는 방식으로 해당 이니셜라이저를 수정할 수 있게 됩니다.

편집하다:

이와 관련하여 if 및 match 에는 고유한 것이 없습니다. 예를 들어, 다운스트림 크레이트가 값 기반 자격에 의존하는 경우 const 이니셜라이저를 const fn 로 리팩터링하는 것은 현재 브레이킹 체인지입니다.

// Upstream
const fn none<T>() -> Option<T> { None }

const VALUE_BASED: Option<Vec<i32>> = None;
const TYPE_BASED: Option<Vec<i32>> = none();

// Downstream

const OK: () = { std::mem::drop(upstream::VALUE_BASED); };
const ERROR: () = { std::mem::drop(upstream::TYPE_BASED); };

@ecstatic-morse 안정화 보고서를 작성해 주셔서 감사합니다! 비동기식으로 합의를 측정해 보겠습니다.

@rfcbot 병합

회의에서 동시에 이를 논의하고 싶은 사람이 있으면 다시 지명하십시오.

팀 구성원 @joshtriplett 이 이를 병합할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀원이 검토하는 것입니다.

• [x] @cramertj
• [x] @joshtriplett
• [x] @nikomatsakis
• [x] @pnkfelix
• [ ] @scottmcm
• [ ] @보트 없이

현재 나열된 우려 사항이 없습니다.

과반수 이상의 검토자가 승인하면(최대 2개의 승인이 미결 상태임) 최종 의견 수렴 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

:bell: 위 의 이제 마지막 댓글 기간에 접어들었습니다 . :벨:

? 에서 const fn ? 를 사용할 수도 있습니까?

그렇지 않습니다 . 일반적으로 특성은 const fn 에서 허용되지 않습니다 .

? 사용한다는 것은 Try 특성을 사용한다는 의미입니다. const fn 에서 특성을 사용하는 것은 불안정 합니다. https://github.com/rust-lang/rust/issues/67794를 참조

@TimDiekmann 당분간 은 ? 수동으로. loop 및 for 되지만 최소한 특정 제한(기본 재귀 스타일)까지는 const eval에도 이러한 제한이 있습니다. 이 기능은 매우 훌륭하여 이전에는 불가능했던 많은 일을 가능하게 합니다. 원하는 경우 const fn에서 작은 wasm vm을 빌드할 수도 있습니다.

위 의 병합 처리가 포함된 최종 의견 수렴 기간이 이제 완료되었습니다 .

거버넌스 프로세스의 자동화된 대표자로서 나는 그들의 작업에 대해 저자와 기여한 다른 모든 사람들에게 감사하고 싶습니다.

RFC는 곧 병합됩니다.