RFC에 대한 토론에서 놓쳤을 수도 있지만 통합 변형의 소멸자가 실행되지 않는다고 생각하는 것이 맞습니까? 이 예제에서 Box::new(1) 대한 소멸자가 실행됩니까?

union Foo {
    f: i32,
    g: Box<i32>,
}

let mut f = Foo { g: Box::new(1) };
f.g = Box::new(2);

@sfackler 내 현재 이해는 f.g = Box::new(2) _will_ 소멸자를 실행하지만 f = Foo { g: Box::new(2) } 는 _not_합니다. 즉, Box<i32> lvalue에 할당하면 항상처럼 드롭이 발생하지만 Foo lvalue에 할당하면 그렇지 않습니다.

따라서 변형에 대한 할당은 필드가 이전에 "유효"했다는 주장과 같습니다.

@sfackler Drop 유형의 경우, 네, 그건 제 이해입니다. 이전에 유효하지 않은 경우 Foo 생성자 양식 또는 ptr::write 를 사용해야합니다. 빠른 grep에서 RFC가이 세부 사항에 대해 명시적인 것처럼 보이지는 않습니다. 나는 그것을 Drop lvalue에 쓰는 것이 소멸자 호출을 유발한다는 일반적인 규칙의 인스턴스화로 봅니다.

Drop 변형이있는 & mut 유니온은 린트 여야합니까?

2016 년 4 월 8 일 금요일, Scott Olson [email protected] 은 다음과 같이 썼습니다.

@sfackler https://github.com/sfackler Drop 유형의 경우
이해. 이전에 유효하지 않은 경우 Foo를 사용해야합니다.
생성자 양식 또는 ptr :: write. 빠른 grep에서 다음과 같이 보이지 않습니다.
그러나 RFC는이 세부 사항에 대해 명시 적입니다.

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32836#issuecomment -207634431

2016 년 4 월 8 일 오후 3:36:22 PDT에 Scott Olson [email protected] 은 다음과 같이 썼습니다.

@sfackler Drop 유형의 경우, 네, 그건 제 이해입니다. 만약 그들이
이전에 유효하지 않은 경우 Foo 생성자 양식을 사용해야합니다.
ptr::write 빠른 grep에서 RFC가
이 세부 사항에 대해 명시 적입니다.

나는 그 사건을 명시 적으로 다루었어야했다. 나는 두 가지 행동 모두 방어 할 수 있다고 생각하지만, 절대로 필드를 묵시적으로 삭제하지 않는 것이 훨씬 덜 놀라운 일이라고 생각합니다. RFC는 이미 Drop을 구현하는 유형이있는 공용체 필드에 Lint를 권장합니다. 필드에 할당하는 것이 해당 필드가 이전에 유효했음을 의미한다고 생각하지 않습니다.

그래, 그 접근법은 나에게도 조금 덜 위험 해 보인다.

유니온 필드에 할당 할 때 삭제하지 않으면 f.g = Box::new(2) 이 let p = &mut f.g; *p = Box::new(2) 과 다르게 작동합니다. 후자의 경우를 _not_ 삭제하지 못하기 때문입니다. 내 접근 방식은 덜 놀라운 것 같습니다.

그것은 새로운 문제도 아닙니다. unsafe 프로그래머는 foo 가 초기화되지 않은 경우 foo = bar 가 UB이고 Drop 다른 상황을 이미 처리해야합니다.

개인적으로 Drop 유형을 공용체와 함께 사용할 계획은 없습니다. 그래서 저는 그렇게하는 의미에 대해 유사한 안전하지 않은 코드로 작업 한 사람들에게 전적으로 연기 할 것입니다.

또한 공용체에서 Drop 유형을 사용하지 않으려 고하므로 일관성이있는 한 어느 쪽이든 상관 없습니다.

나는 공용체에 대한 가변 참조를 사용하지 않을 것이며 아마도
Into와 함께 "이상하게 태그 된"것들

2016 년 4 월 8 일 금요일에 Peter Atashian [email protected] 은 다음과 같이 썼습니다.

또한 공용체에서 Drop 유형을 사용하지 않으려 고하므로 어느 쪽이든
일관성이있는 한 나에게 중요합니다.

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32836#issuecomment -207653168

이것은 해결되지 않은 질문으로 제기하기에 좋은 문제인 것 같습니다. 내가 어떤 접근 방식을 선호하는지 아직 잘 모르겠습니다.

@nikomatsakis Drop을 사용하여 해당 필드의 이전 유효성을 요구하기 위해 유형의 공용체 필드에 할당하는 것이 어색 하다고 생각하는

그리고 저는 unsafe 프로그래머는 일반적으로 a = b 안전한 코드를 작성하기 위해 drop_in_place(&mut a); ptr::write(&mut a, b) 를 의미한다는 것을 이미 알고 있어야합니다. 유니온 필드를 삭제하지 않는 것은 _ 하나만 더 _ 배울 수있는 예외입니다.

(주의 : a 이 let a; a = b; 처럼 이미 초기화되지 않은 것으로 알려진 a _statically_ 인 경우 하락이 발생하지 않습니다.)

그러나 나는 사람들이 #[allow(..)] 해야하는 조합의 Drop 변형에 대한 기본 경고를 지원합니다.

@tsion 이것은 a = b 대해서는 사실이 아니며 때로는 a.x = b 대해서도 사실이지만 *a = b 에는 확실히 사실입니다. 이 불확실성 때문에 주저하게되었습니다. 예를 들어 다음과 같이 컴파일됩니다.

fn main() {
  let mut x: (i32, i32);
  x.0 = 2;
  x.1 = 3;
}

(나중에 x 를 인쇄하려는 시도는 실패하지만 버그라고 생각합니다)

@nikomatsakis 그 예는 나에게 새로운 것입니다. 이전 경험을 고려할 때 해당 예제가 컴파일되는 버그로 간주했을 것입니다.

하지만 그 예의 관련성이 있는지 잘 모르겠습니다. 왜 내가 a = b 대해 사실이 아니고 가끔 a.x = b 대해서만 사실입니까?

x.0 에 소멸자가있는 유형이있는 경우 해당 소멸자가 호출됩니다.

fn main() {
    let mut x: (Box<i32>, i32);
    x.0 = Box::new(2); // x.0 statically know to be uninit, destructor not called
    x.0 = Box::new(3); // x.0 destructor is called before writing new value
}

그런 종류의 쓰기에 대해 보풀이 생기지 않을까요?

내 요점은 = 가 소멸자를 _ 항상 _ 실행하지 않는다는 것입니다. 그것
타겟이 알려 진지 여부에 대한 지식을 사용합니다.
초기화되었습니다.

2016 년 4 월 12 일 화요일 오후 04:10:39 -0700 Scott Olson은 다음과 같이 썼습니다.

@nikomatsakis 저에게 새로운 예입니다. 이전 경험을 고려할 때 해당 예제가 컴파일되는 버그로 간주했을 것입니다.

하지만 그 예의 관련성이 있는지 잘 모르겠습니다. 왜 내가 a = b 대해 사실이 아니고 가끔 'ax = b'에 대해서만 사실이 아닌가?

x.0 에 소멸자가있는 유형이있는 경우 해당 소멸자가 호출됩니다.

fn main() {
    let mut x: (Box<i32>, i32);
    x.0 = Box::new(2); // x.0 statically know to be uninit, destructor not called
    x.0 = Box::new(3); // x.0 destructor is called
}

뿡 빵뀨

드롭 플래그가 설정된 경우 소멸자를 실행합니다.

하지만 그런 종류의 쓰기는 어차피 혼란 스럽다고 생각하는데, 그냥 금하는 게 어때요? 언제든지 *(&mut u.var) = val 할 수 있습니다.

내 요점은 = 가 소멸자를 _ 항상 _ 실행하지 않는다는 것입니다. 대상이 초기화 된 것으로 알려져 있는지 여부에 대한 정보를 사용합니다.

@nikomatsakis 이미 언급했습니다.

(주의 : let a; a = b;와 같이 a가 이미 초기화되지 않은 것으로 정적으로 알려진 경우 드롭이 발생하지 않습니다.)

그러나 나는 드롭 플래그의 동적 검사를 고려하지 않았으므로 이것은 내가 생각한 것보다 확실히 더 복잡합니다.

@tsion

드롭 플래그는 반동적 일뿐입니다. 제로화 드롭이 사라진 후에는 codegen의 일부가됩니다. 나는 좋은 것보다 더 많은 혼란을주기 때문에 그런 종류의 쓰기를 금지한다고 말한다.

Drop 유형도 공용체에서 허용되어야합니까? 내가 올바르게 이해하고 있다면, Rust에서 공용체를 사용하는 주된 이유는 공용체가있는 C 코드와 인터페이스하기 위해서이며 C에는 소멸자조차 없습니다. 다른 모든 목적으로는 Rust 코드에서 enum 를 사용하는 것이 더 나은 것 같습니다.

드롭을 금지하는 NoDrop 유형을 구현하기 위해 공용체를 사용하는 유효한 사용 사례가 있습니다.

drop_in_place 또는 이와 유사한 방법을 통해 이러한 코드를 수동으로 호출 할 수 있습니다.

이전 옵션 유형이 정의되지 않았기 때문에 쓰기 중에 필드 값을 삭제하는 것은 확실히 잘못되었습니다.

필드 세터를 금지 할 수 있지만 완전한 유니온 교체가 필요합니까? 이 경우 통합이 Drop을 구현하면 예상대로 대체 된 값에 대해 전체 통합 삭제가 호출됩니다.

필드 세터를 금지하는 것은 말이되지 않는다고 생각합니다. 대부분의 공용체 사용은이를 사용하는 데 문제가 없으며 Drop 구현이없는 필드는 일반적인 경우로 남아있을 것입니다. Drop을 구현하는 필드가있는 공용체는 기본적으로 경고를 생성하므로이 경우 우연히 발생할 가능성이 훨씬 적습니다.

논의를 위해, 나는 조합의 필드에 대한 가변 참조를 노출시키고 _ 그리고 _ 임의 ( Drop ) 유형을 그 안에 넣을 예정입니다. 기본적으로 공용체를 사용하여 사용자 지정 공간 효율적인 열거 형을 작성하고 싶습니다. 예를 들면

union SlotInner<V> {
    next_empty: usize, /* index of next empty slot */
    value: V,
}

struct Slot<V> {
    inner: SlotInner<V>,
    version: u64 /* even version -> is_empty */
}

@nikomatsakis 현재 여기에 해결되지 않은 것으로 나열된 질문에 대한 구체적인 답변을 제안하고 싶습니다.

불필요하게 복잡한 의미 체계를 피하기 위해 공용체 필드에 할당하는 것은 구조체 필드에 할당하는 것처럼 작동해야합니다. 즉, 이전 내용을 삭제하는 것을 의미합니다. 당신이 그것에 대해 알고 있다면 이것을 피하는 것은 전체 노조에 대신 할당함으로써 쉽게 피할 수 있습니다. 이것은 여전히 ​​약간 놀라운 동작이지만 Drop 를 구현하는 공용체 필드가 ​​있으면 경고가 생성되며 해당 경고의 텍스트는이를 경고로 명시 적으로 언급 할 수 있습니다.

이 동작을 문서화하기 위해 RFC1444를 수정하는 RFC 풀 요청을 제공하는 것이 합리적입니까?

@joshtriplett @nikomatsakis 가 휴가

@aturon 감사합니다. 이 문제를 해결하기 위해 새로운 RFC PR https://github.com/rust-lang/rfcs/issues/1663 을 이러한 설명과 함께 RFC1444에 제출했습니다.

_{( @aturon 지금 해결되지 않은 질문을 확인할 수 있습니다.)}

https://github.com/petrochenkov/rust/tree/union에 예비 구현이

상태 : 구현 됨 (모듈로 버그), PR 제출 됨 (https://github.com/rust-lang/rust/pull/36016).

@petrochenkov 대단해! 지금까지 멋져 보입니다.

이동 검사기에서 Copy 필드가 아닌 유니온을 처리하는 방법을 잘 모르겠습니다.
u 가 union U { a: A, b: B } 의 초기화 된 값이라고 가정하고 이제 필드 중 하나에서 이동합니다.

1) A: !Copy, B: !Copy, move_out_of(u.a)
이것은 간단합니다. u.b 도 초기화되지 않은 상태가됩니다.
온 전성 검사 : union U { a: T, b: T } 는 struct S { a: T } + 필드 별칭과 똑같이 작동해야합니다.

2) A: Copy, B: !Copy, move_out_of(u.a)
u.b 는 여전히 초기화되어야합니다. move_out_of(u.a) 는 단순히 memcpy 이고 u.b 를 변경하지 않기 때문입니다.

2) A: !Copy, B: Copy, move_out_of(u.a)
이것은 가장 이상한 경우입니다. u.b 는 Copy 임에도 불구하고 초기화되지 않은 상태로 전환되어야합니다. Copy 값은 초기화되지 않을 수 있지만 (예 : let a: u8; ) 초기화 됨에서 초기화되지 않음으로 상태를 변경하는 것은 새로운 AFAIK입니다.

뿡뿡
나는 이것이 FFI 요구와 완전히 관련이 없다는 것을 알고 있습니다 :)
좋은 소식은 이것이 차단기가 아니라는 것입니다. 이번 주말에 더 간단한 행동을 구현하고 PR을 제출할 것입니다.

@petrochenkov 내 본능은 노동 조합이 본질적으로 "비트 버킷"이라는 것입니다. 데이터가 초기화되었는지 여부와 실제 유형이 무엇인지 추적해야합니다. 이것은 원시 포인터의 지시 대상과 매우 유사합니다.

이것이 우리가 데이터를 삭제할 수없는 이유와 필드에 대한 액세스가 안전하지 않은 이유이기도

이 규칙에 따라 복사가 구현되면 공용체가 Copy 를 구현할 것으로 예상합니다. 그러나 structs / enums와 달리 내부 온 전성 검사는 없습니다. 원하는 경우 언제든지 공용체 유형에 대한 사본을 구현할 수 있습니다.

명확히하기 위해 몇 가지 예를 들어 보겠습니다.

union Foo { ... } // contents don't matter

Copy 가 구현되지 않았기 때문에이 공용체는 유사합니다.

union Bar { x: Rc<String> }
impl Copy for Bar { }
impl Clone for Bar { fn clone(&self) -> Self { *self } }

Copy 가 구현되었으므로이 공용체 유형 Bar 는 복사입니다.

Bar 가 구조체 인 경우 x 필드의 유형으로 인해 Copy 를 구현하는 것은 오류가됩니다.

허, 나는 당신의 질문에 실제로 대답하지 않는 것 같습니다. 이제 다시 읽었습니다. =)

좋아요, 저는 당신의 질문에 전혀 대답하지 않았다는 것을 알고 있습니다. 다시 해보겠습니다. "비트 버킷"원칙에 따라, 나는 우리가 마음대로 노조에서 나갈 수있을 것으로 기대합니다. 그러나 물론 또 다른 옵션은 *mut T 를 처리하는 것처럼 처리하고 ptr::read 를 사용하여 이사해야하는 것입니다.

편집 : 나는 실제로 왜 우리가 그러한 움직임을 금지하는지 확실하지 않습니다. 이동 드롭을 사용하여 수행해야했을 수도 있습니다. 아니면 실수하기 쉽기 때문에 "움직임"을 더 명확하게 만드는 것이 더 나은 것 같습니다. 여기서 역사를 기억하는 데 어려움이 있습니다.

뿡 빵뀨

내 본능은 노조가 본질적으로 "비트 버킷"이라는 것입니다.

하, 나는 반대로 그러한 위험한 구조에 대해 우리가 할 수있는 한 조합의 내용에 대해 많은 보증을하고 싶습니다.

해석은 union은 우리가 판별자를 알지 못하는 열거 형이라는 것입니다. 즉, 우리는 언제든지 적어도 하나의 union의 변형이 유효한 값을 가지고 있음을 보장 할 수 있습니다 (안전하지 않은 코드가 관련되지 않는 한).

현재 구현의 모든 차용 / 이동 규칙은이 보장을 지원합니다. 동시에 이것은 가장 보수적 인 해석으로 "안전한"방식으로 진행할 수 있습니다 (예 : 동일한 유형의 필드가있는 공용체에 안전하게 액세스 할 수 있도록 허용). 유용함 ) 또는 Rust 유니온에 대한 더 많은 경험이 모이는 미래의 "비트 버킷"방식입니다.

실제로 https://github.com/rust-lang/rust/pull/36016#issuecomment -242810887에 설명 된대로 더 보수적으로 만들고 싶습니다.

안녕하세요.

해석은 union은 우리가 판별자를 알지 못하는 열거 형이라는 것입니다. 즉, 우리는 언제든지 적어도 하나의 union의 변형이 유효한 값을 가지고 있음을 보장 할 수 있습니다 (안전하지 않은 코드가 관련되지 않는 한).

통합으로 작업 할 때 필드에 대한 모든 액세스가 안전하지 않기 때문에 안전하지 않은 코드가 항상 관련됩니다.

제가 생각하는 방식은 비슷하다고 생각합니다. 기본적으로 공용체는 열거 형과 같지만 동시에 둘 이상의 변형에있을 수 있습니다. 유효한 변형의 집합은 어느 시점에서든 컴파일러에 알려지지 않았지만 때때로 집합이 비어 있음을 알 수 있습니다 (즉, 열거 형이 초기화되지 않음).

따라서 some_union.field 은 기본적으로 유효한 변형 세트에 현재 field 포함되어 있다는 암시 적 (그리고 안전하지 않은) 주장으로 간주됩니다. 이것은 차입 검사기 통합이 작동하는 방식과 호환되는 것 같습니다. x 필드를 빌린 다음 y 를 사용하려고하면 기본적으로 데이터가 x 및 y 라고 말하고 있기 때문에 오류가 발생합니다. (그리고 그것은 빌 렸습니다). (반대로 일반 열거 형에서는 한 번에 둘 이상의 변형에 서식 할 수 없으며,이 규칙이 어떻게 실행되는지 볼 수 있습니다 .)

어쨌든, 요점은 우리가 유니온의 한 필드에서 "이동"할 때 당면한 질문은 이것이 다른 변형으로 값을 해석하는 것이 더 이상 유효하지 않다는 것을 의미한다고 추론 할 수 있는지 여부입니다. 하지만 어느 쪽이든 논쟁하는 것이 그렇게 어렵지 않을 것이라고 생각합니다. 나는 이것을 회색 영역이라고 생각합니다.

보수적 일 위험은 그렇지 않으면 의미가 있고 유효 할 수있는 안전하지 않은 코드를 배제 할 수 있다는 것입니다. 그러나 나는 더 빡빡하게 시작하고 나중에 느슨하게 할 것인지 결정하는 것은 괜찮습니다.

우리는 노조에서 Copy 를 구현하는 데 필요한 조건에 대해 논의해야합니다. 또한 안정화 전에 처리하고 문서화 할 수 있도록 위에 나열된 이러한 회색 영역의 전체 목록을 가지고 있는지 확인해야합니다!

기본적으로 공용체는 열거 형과 같지만 동시에 둘 이상의 변형에있을 수 있습니다.

"둘 이상의 변형"해석에 대한 한 가지 주장은 결합이 상수 표현식에서 어떻게 작동하는지입니다. 이러한 결합의 경우 항상 단일 활성 변형을 알고 있으며 컴파일 타임에 변환하는 것이 일반적으로 좋지 않기 때문에 비활성 변형에 액세스 할 수 없습니다 (우리가 시도하지 않는 한 컴파일러를 일종의 부분 대상 에뮬레이터로 바꾸려면).
내 해석은 런타임에 비활성 변형이 여전히 비활성이지만 조합의 활성 변형 (보다 제한적인 정의)과 레이아웃 호환이 가능하거나 조합의 단편 할당 기록 (더 모호하지만 더 유용함)과 호환되는 경우 액세스 할 수 있다는 것입니다.

이러한 회색 영역의 전체 목록이 있는지 확인해야합니다.

나는 멀지 않은 미래에 노조 RFC를 수정할 것입니다! "열거 형"해석은 꽤 재미있는 결과를 가져옵니다.

컴파일 타임에 변환하는 것은 일반적으로 좋지 않습니다 (컴파일러를 일종의 부분 대상 에뮬레이터로 바꾸려고하지 않는 한).

@petrochenkov 이것은 Miri 프로젝트의 목표 중 하나입니다. Miri는 이미 변환 및 다양한 원시 포인터 헛소리를 할 수 있습니다. Miri가 유니온을 처리하도록 만드는 것은 약간의 작업이 될 것입니다 (원시 메모리 처리 측면에서 새로운 것은 없습니다).

그리고 @eddyb 은 rustc 상수 평가를 Miri 버전으로 대체하기 위해 노력하고 있습니다.

안녕하세요.

"둘 이상의 변형"해석에 대한 한 가지 주장은 결합이 상수 표현식에서 작동하는 방식입니다.

상수에서 공용체 사용을 가장 잘 지원하는 방법은 흥미로운 질문이지만 상수 표현식을 런타임 동작의 하위 집합으로 제한하는 데 문제가 없다고 생각합니다 (이것이 우리가 항상하는 일입니다). 즉, 컴파일 시간에 특정 변환을 완전히 지원할 수 없다고해서 런타임에 불법임을 의미하지는 않습니다.

내 해석은 런타임에 비활성 변형이 여전히 비활성 상태이지만 조합의 활성 변형과 레이아웃이 호환되는 경우 액세스 할 수 있다는 것입니다.

흠, 노조가 모든 변형에 동시에 속한다고 말하는 것과 이것이 어떻게 다른지 생각하려고합니다. 나는 아직 차이가 보이지 않는다. :)

이 해석은 일반적으로 동작과 이상한 상호 작용을하는 것 같습니다. 예를 들어 데이터가 "진짜"X이고이를 Y로 해석하지만 Y가 유사하다면 여전히 X입니까?

그럼에도 불구하고 어떤 분야의 움직임이 전체 조합을 소비하는 것은 이러한 해석 중 어느 것과도 일치한다고 볼 수 있다고 생각합니다. 예를 들어, "변형 집합"접근 방식에서는 값을 이동하면 모든 기존 변형이 초기화되지 않습니다 (물론 사용한 변형이 유효한 집합 중 하나 여야 함). 귀하의 버전에서는 해당 변형으로 "변환"되고 원본을 소비하는 것처럼 보입니다.

나는 멀지 않은 미래에 노조 RFC를 수정할 것입니다! "열거 형"해석은 꽤 재미있는 결과를 가져옵니다.

그런 자신감! 당신은 시도 할 것입니다;)

염두에두고있는 구체적인 변경 사항에 대해 몇 가지 더 자세히 설명 해주시겠습니까?

염두에두고있는 구체적인 변경 사항에 대해 몇 가지 더 자세히 설명 해주시겠습니까?

구현에 대한 자세한 설명 (예 : 더 나은 문서), 일부 작은 확장 (예 : 빈 공용체 및 공용체 패턴의 .. ), 공용체 진화의 두 가지 주요 (모순되는) 대안-더 안전하지 않고 덜 제한적인 "스크래치 공간" 해석 및 더 안전하고 더 제한적인 "알 수없는 판별이있는 열거"해석-이동 / 초기화 검사기, Copy impls, unsafe ty 필드 액세스 등에 대한 결과

비활성 통합 필드에 액세스 할 때 UB를 정의하는 것도 유용합니다. 예 :

union U { a: u8, b: () }
let u = U { b: () };
let a = u.a; // most probably an UB, equivalent to reading from `mem::uninitialized()`

그러나 이것은 무한히 까다로운 영역입니다.

아마도 교차 필드 의미론은 기본적으로 포인터 캐스트 맞습니까?
_ (_ () as * u8)

2016 년 9 월 1 일 목요일, Vadim Petrochenkov [email protected]
썼다 :

비활성 통합 필드에 액세스 할 때 정의하는 것도 유용합니다.
예 : UB

union U {a : u8, b : ()}
let u = U {b : ()};
let a = ua; // mem::uninitialized() 에서 읽는 것과 동일한 UB 일 가능성이 높습니다.

그러나 이것은 무한히 까다로운 영역입니다.

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32836#issuecomment -244154751,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABxXhi68qRITTFW5iJn6omZQQBQgzweNks5qlw4qgaJpZM4IDXsj
.

현장 접근이 항상 안전하지 않습니까?

2016 년 9 월 1 일 목요일, Vadim Petrochenkov [email protected]
썼다 :

염두에두고있는 구체적인 변경 사항에 대해 몇 가지 더 자세히 설명 해주시겠습니까?

구현에 대한 자세한 설명 (예 :
문서), 일부 작은 확장 (예 : 빈 공용체 및 .. 공용체
패턴), 결합 진화의 두 가지 주요 (모순되는) 대안-더
안전하지 않고 덜 제한적인 "스크래치 공간"해석 및 더 안전함
더 제한적인 "알 수없는 판별이있는 열거 형"해석-및
이동 / 초기화 검사기, Copy impls, unsafety에 대한 결과
현장 접근 등

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32836#issuecomment -244151164,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABxXhuHStN8AFhR3KYDU27U29MiMpN5Bks5qlws9gaJpZM4IDXsj
.

현장 접근이 항상 안전하지 않습니까?

때로는 안전하게 만들 수 있습니다.

• 사소하게 파괴 할 수있는 공용체 필드에 대한 할당은 안전합니다.
• union U { f1: T, f2: T, ..., fN: T } 필드에 대한 모든 액세스 (즉, 모든 필드의 유형이 동일 함)는 "알 수없는 판별이있는 열거 형"해석에서 안전합니다.

사용자 관점에서 특별한 조건을 적용하지 않는 것이 좋습니다. 항상 안전하지 않다고 부르세요.

현재 git의 최신 rustc에서 공용체에 대한 지원을 테스트하고 있습니다. 내가 시도한 모든 것이 완벽하게 작동합니다.

나는 데드 필드 검사기에서 흥미로운 사건을 만났습니다. 다음 코드를 시도하십시오.

#![feature(untagged_unions)]

union U {
    i: i32,
    f: f32,
}

fn main() {
    println!("{}", std::mem::size_of::<U>());
    let u = U { f: 1.0 };
    println!("{:#x}", unsafe { u.i });
}

이 오류가 발생합니다.

warning: struct field is never used: `f`, #[warn(dead_code)] on by default

dead_code 검사기가 초기화를 인식하지 못한 것 같습니다.

(이미 "struct field"사용에 대해 PR # 36252를 제출하여 "field"로 변경했습니다.)

유니온은 현재 동적으로 크기가 조정 된 필드를 포함 할 수 없지만 RFC는 다음과 같은 방식으로이 동작을 지정하지 않습니다.

#![feature(untagged_unions)]

union Foo<T: ?Sized> {
  value: T,
}

산출:

error[E0277]: the trait bound `T: std::marker::Sized` is not satisfied
 --> <anon>:4:5
  |
4 |     value: T,
  |     ^^^^^^^^ trait `T: std::marker::Sized` not satisfied
  |
  = help: consider adding a `where T: std::marker::Sized` bound
  = note: only the last field of a struct or enum variant may have a dynamically sized type

컨텍스트 키워드는 모듈 / 크레이트 루트 컨텍스트 외부에서 작동하지 않습니다.

fn main() {
    // all work
    struct Peach {}
    enum Pineapple {}
    trait Mango {}
    impl Mango for () {}
    type Strawberry = ();
    fn woah() {}
    mod even_modules {
        union WithUnions {}
    }
    use std;

    // does not work
    union Banana {}
}

꽤 불쾌한 일관성 사마귀처럼 보입니다.

나기사
실수로 이전 버전의 rustc를 사용하고 있습니까?
방금 playpen에서 예제를 확인했고 작동합니다 (모듈로 "빈 유니온"오류).
이 특정 상황에 대한 실행 통과 테스트 검사도 있습니다-https: //github.com/rust-lang/rust/blob/master/src/test/run-pass/union/union-backcomp.rs.

@petrochenkov 아, stable 되 돌린 것 같습니다. 그럼 신경 쓰지 마

결국 노조는 이 제안 에서 안전하지 않은 분야의 사악한 쌍둥이 인 _ 안전한 분야 _를 지원해야한다고 생각합니다.
cc https://github.com/rust-lang/rfcs/issues/381#issuecomment -246703410

다양한 기준에 따라 "안전한 조합"을 선언하는 방법을 갖는 것이 합리적이라고 생각합니다.

예를 들어, 모두 같은 크기의 Copy non-Drop 필드를 독점적으로 포함하는 공용체는 안전 해 보입니다. 필드에 액세스하는 방법에 관계없이 예상치 못한 데이터를 얻을 수 있지만 메모리 안전 문제 나 정의되지 않은 동작은 발생할 수 없습니다.

@joshtriplett 또한 초기화되지 않은 데이터를 읽을 수있는 유형에 "구멍"이 없는지 확인해야합니다. 제가 말하고 싶은대로 : "초기화되지 않은 데이터는 예측할 수없는 임의의 데이터이거나 SSH 개인 키 중 더 나쁜 것입니다."

&T Copy 및 Non-Drop이 아닌가요? usize 와 함께 "안전한"공용체에 넣으면 불량 참조 생성기가 있습니다. 따라서 규칙은 그것보다 조금 더 엄격해야합니다.

예를 들어, 모두 같은 크기의 Copy non-Drop 필드를 독점적으로 포함하는 공용체는 안전 해 보입니다. 필드에 액세스하는 방법에 관계없이 예상치 못한 데이터를 얻을 수 있지만 메모리 안전 문제 나 정의되지 않은 동작은 발생할 수 없습니다.

나는 이것이 진지한 제안이 아니라 단순한 예일 뿐이라는 것을 알고 있지만 이것이 얼마나 까다로운 지 보여주는 몇 가지 예입니다.

• u8 및 bool 의 크기는 동일하지만 대부분의 u8 값은 bool 대해 유효하지 않으며이 트리거를 무시하면 UB
• &T 및 &U 동일한 크기를 갖고있다 Copy + !Drop 모든 T 및 U 만큼 모두 또는 어느만큼 ( Sized )
• uN / iN 와 fN 은 현재 안전하지 않은 코드에서만 가능합니다. 나는 그러한 변환이 항상 안전하다고 생각하지만 이것은 안전한 언어를 확대하므로 논란의 여지가 있습니다.
• 사생활 침해 (예 : struct Foo(Bar); ~ Bar )는 안전과 관련된 불변성을 유지하기 위해 사생활 보호가 사용될 수 있기 때문에 절대 안됩니다.

@Amanieu 내가 글을 쓸 때 내부 패딩이 없다는 메모를 포함하려고했는데 어떻게 든 그렇게하는 것을 잊었습니다. 잡아 주셔서 감사합니다.

@cuviper 제로 포인터를 포함하는 것과 같이 "일반적인 오래된 데이터"를 정의하려고했습니다. 당신 말이 맞습니다. 정의는 참조를 제외해야합니다. 허용되는 유형 집합과 이러한 유형의 조합을 허용 목록에 추가하는 것이 더 쉬울 것입니다.

뿡뿡

u8과 bool의 크기는 동일하지만 대부분의 u8 값은 bool에 유효하지 않으며이 트리거를 무시하면 UB가 트리거됩니다.

좋은 지적; 열거 형에도 동일한 문제가 적용됩니다.

& T 및 & U는 크기가 같고 모든 T 및 U에 대해 Copy +! Drop입니다 (둘 다 크기가 지정되거나 둘 다 크기가 지정되지 않은 경우).

나는 그것을 잊었다.

uN / iN과 fN 간의 변환은 현재 안전하지 않은 코드에서만 가능합니다. 나는 그러한 변환이 항상 안전하다고 생각하지만 이것은 안전한 언어를 확대하므로 논란의 여지가 있습니다.

두 점 모두에 동의했습니다. 이것은 허용되는 것으로 보입니다.

프라이버시 위반 (예 : struct Foo (Bar)과 Bar 사이의 punning)은 안전과 관련된 불변성을 유지하기 위해 프라이버시가 사용될 수 있기 때문에 절대 안됩니다.

유형의 내부를 모르는 경우 내부가 요구 사항을 충족하는지 (예 : 내부 패딩 없음) 알 수 없습니다. 따라서 모든 구성 요소가 재귀 적으로 평범한 데이터 여야하며이를 확인할 수있는 충분한 가시성을 갖도록 요구하여이를 제외 할 수 있습니다.

uN / iN과 fN 간의 변환은 현재 안전하지 않은 코드에서만 가능합니다. 나는 그러한 변환이 항상 안전하다고 생각하지만 이것은 안전한 언어를 확대하므로 논란의 여지가 있습니다.

부동 소수점 숫자에는 UB를 생성하는 트랩 표현 인 신호 NaN이 있습니다.

@ retep998 Rust는 부동 소수점 트랩 비활성화를 지원하지 않는 플랫폼에서 실행됩니까? (이것은 UB 문제를 변경하지 않지만 이론적으로는 문제를 해결할 수 있습니다.)

안녕하세요.

해석은 union은 판별자를 알지 못하는 열거 형이라는 것입니다. 즉, 언제든지 조합의 변형 중 적어도 하나가 유효한 값을 가지고 있음을 보장 할 수 있습니다.

나는이 해석에 다가 왔다고 생각합니다. 글쎄요. 나는 항상 그랬듯이 저장하는 지점에서 결정되는 몇 가지 법적 변형이 있다고 생각합니다. 나는 값을 "양자 상태"에 넣는 것과 비슷하게 결합에 저장한다고 생각합니다. 이제 잠재적으로 많은 법적 해석 중 하나로 변환 될 수 있습니다. 그러나 나는 당신이 이러한 변종들 중 하나에서 벗어나면 그것들 중 하나에 "강제"하고 그 가치를 소비한다는 것에 동의합니다. 따라서 열거 형을 다시 사용할 수 없어야합니다 (해당 유형이 Copy 이 아닌 경우). 그래서 👍, 기본적으로.

#[repr(C)] 에 대한 질문 : @pnkfelix가 최근 나에게 지적했듯이 현재 사양에 따르면 union이 #[repr(C)] 이 아닌 경우 x 필드와 함께 저장하고 읽는 것은 불법입니다. y 필드 포함. 아마도 이것은 동일한 오프셋에서 모든 필드를 시작할 필요가 없기 때문일 것입니다.

예를 들어 새니 타이 저는 공용체를 일반 열거 형 (또는 구조체 ...?)처럼 저장하고 입력 한 것과 동일한 변형을 사용하는지 확인하여 공용체를 구현할 수 있습니다.

_ 그러나 _ 그것은 일종의 풋건처럼 보이며, 또한 그러한 재현 중 하나는 실제로 너무 많은 사람들이 야생에서 그것에 의존 할 것이기 때문에 우리가 _ 실제로 _ 변화 할 수 없다는 것을 보장합니다.

생각?

뿡 빵뀨

해석은 union은 판별자를 알지 못하는 열거 형이라는 것입니다. 즉, 언제든지 조합의 변형 중 적어도 하나가 유효한 값을 가지고 있음을 보장 할 수 있습니다.

최악의 부분은 결합에 직접 액세스 할 수있는 변형 / 필드 조각입니다.
이 코드를 고려하십시오.

union U {
    a: (u8, bool),
    b: (bool, u8),
}
fn main() {
    unsafe {
        let mut u = U { a: (2, false) };
        u.b.1 = 2; // turns union's memory into (2, 2)
    }
}

모든 필드는 Copy 이고 관련된 소유권이 없으며 이동 검사기는 만족 스럽지만 비활성 필드 b 대한 부분 할당은 0 유효한 변형이있는 상태로 Union을 전환합니다. 나는 그것을 다루는 방법을 아직 생각하지 못했습니다. 그런 과제를 UB로 만드시겠습니까? 해석을 변경 하시겠습니까? 다른 것?

안녕하세요.

그런 과제를 UB로 만드시겠습니까?

이것은 나의 가정입니다. a 할당하면 b 변형이 유효한 변형 집합에 없으므로 나중에 u.b.1 (읽기 또는 할당 여부)를 사용하는 것은 유효하지 않습니다.

# [repr (C)]에 대한 질문 : @pnkfelix가 최근 저에게 지적했듯이 현재 사양에서는 공용체가 # [repr (C)]가 아닌 경우 필드 x와 함께 저장하고 필드 y로 읽는 것은 불법이라고 말합니다. . 아마도 이것은 동일한 오프셋에서 모든 필드를 시작할 필요가 없기 때문일 것입니다.

여기서 적절한 표현은 1) 이전에 작성된 필드 / 필드 조각과 "레이아웃 호환"(모호함)이 아닌 필드에서 읽는 것이 UB입니다. 2) #[repr(C)] 공용체의 경우 사용자는 레이아웃이 무엇인지 알고 있습니다. (ABI 문서에서) UB와 비 UB를 구분할 수 있도록 3) #[repr(Rust)] 공용체 레이아웃이 지정되어 있지 않으므로 사용자는 UB가 무엇인지 아닌지 말할 수 없지만 WE (rustc / libstd + their 테스트)이 신성한 지식을 가지고 있기 때문에 밀과 왕겨를 분리하고 비 UB 방식으로 #[repr(Rust)] 를 사용할 수 있습니다.

4) 크기 / 스트라이드 및 필드 재정렬 질문이 결정된 후 구조체 및 공용체 레이아웃이 돌로 설정되고 지정 될 것으로 예상되므로 사용자는 레이아웃도 알고 #[repr(Rust)] 공용체를 사용할 수 있습니다. #[repr(C)] 만큼 자유롭게 문제가 해결됩니다.

@nikomatsakis 유니온 RFC에 대한 논의에서 사람들은 유니온을 사용하여 컴팩트 한 데이터 구조를 구축하는 네이티브 Rust 코드를 원한다고 언급했습니다.

#[repr(C)] 사용하는 사람들로부터 멈추는 것이 있습니까? 그렇지 않다면 #[repr(Rust)] 대해 어떤 종류의 보증도 제공 할 필요가 없다고 생각합니다. "here be dragons"로 두십시오. 아마도 #[repr(C)] 가 아닌 공용체에 대해 기본적으로 경고되는 lint를 사용하는 것이 가장 좋습니다.

@ retep998 repr(Rust) 가 특정 레이아웃이나 겹침을 보장하지 않는다는 것이 합리적으로 보입니다. 나는 단지 repr(Rust) 이 실제로 노동 조합의 메모리 사용에 대한 사람들의 가정을 깨서는 안된다고 제안합니다 ( "가장 큰 구성원보다 크지 않음").

Rust는 부동 소수점 트랩 비활성화를 지원하지 않는 플랫폼에서 실행됩니까?

그것은 정말로 유효한 질문이 아닙니다. 우선, 옵티 마이저 자체는 트랩 표현의 UB-ness에 의존하고 예기치 않은 방식으로 프로그램을 다시 작성할 수 있습니다. 게다가 Rust는 실제로 FP 환경 변경을 지원하지 않습니다.

그러나 그것은 일종의 풋건처럼 보이며, 또한 그러한 재현 중 하나는 너무 많은 사람들이 야생에서 그것에 의존 할 것이기 때문에 우리가 실제로 실제로 변경할 수 없다는 것을 보장합니다.

생각?

프로그램 흐름을 검사하고 열거 형이 다른 필드에서 입증 가능하게 작성되었을 때 필드에서 읽은 경우 사용자에게 불만을 제기하는 린트 또는 일부를 추가하면이 기능에 도움이됩니다 ¹. MIR 기반 린트는 짧은 작업을 수행합니다. CFG가 통합 필드로드의 합법성에 대한 결론을 내리는 것을 허용하지 않고 사용자가 실수를하는 경우, 정의되지 않은 동작은 Rust repr 자체 IMO를 지정하지 않고도 지정할 수있는 최선의 방법입니다.

¹ : 사람들이 어떤 이유로 노조를 가난한 사람의 변환으로 사용하기 시작할 때 특히 효과적입니다.

실제로 노조의 메모리 사용에 대한 사람들의 가정을 깨서는 안됩니다 ( "가장 큰 구성원보다 크지 않음").

동의하지 않습니다. 예를 들어, repr(Rust) 을 일부 아키텍처의 기계어 크기로 확장하는 것이 합리적 일 수 있습니다.

안정화 전에 고려해야 할 한 가지 문제는 https://github.com/rust-lang/rust/issues/37479입니다. 최신 버전의 LLDB 디버깅 공용체가 작동하지 않을 수 있습니다.

@alexcrichton GDB에서 작동합니까?

내가 말할 수있는 것에서 그렇습니다. Linux 봇이 테스트를 잘 실행하는 것 같습니다.

그렇다면 Rust는 모든 올바른 디버깅 정보를 제공하고 LLDB에는 여기에 버그가 있습니다. 나는 여러 디버거 중 하나의 버그가 다른 디버거에 존재하지 않는 버그가 이것을 안정화시키는 것을 차단해야한다고 생각하지 않습니다. LLDB는 수정이 필요합니다.

1.17주기 (3 월 16 일 베타) 동안이 기능을 FCP에 적용 할 수 있는지 확인하는 것이 좋습니다. 누구든지 우리가 합의에 도달하고 모든 것을 해결할 수 있는지 확인할 수 있도록 미해결 질문과 기능의 현재 상황에 대한 요약을 제공 할 수 있습니까?

안녕하세요.
내 계획은

• 다가오는 릴리스 (2 월 3 일)를 기다리십시오.
• Copy 필드가있는 공용체의 안정화를 제안하십시오. 이것은 모든 FFI 요구를 다룰 것입니다-FFI 라이브러리는 stable에서 공용체를 사용할 수 있습니다. "POD"공용체는 C / C ++에서 수십 년 동안 사용되었으며 잘 이해되고 있습니다 (모듈로 유형 기반 앨리어싱이지만 Rust에는 없습니다). 알려진 차단기도 없습니다.
• 2 월 3 일까지 "Unions 1.2"RFC를 작성하십시오. 현재 통합 구현에 대해 설명하고 향후 방향을 설명합니다. 비 Copy 필드가있는 유니온의 미래는이 RFC를 논의하는 과정에서 결정됩니다.

표준 라이브러리에서 ManuallyDrop 또는 NoDrop 와 같은 것을 노출하는 데는 통합 안정화가 필요하지 않습니다.

상태 업데이트 (2 월 4 일) : RFC를 작성하고 있지만, 평소와 같이 각 문장 뒤에 작가 블록이 있으므로 이번 주말이 아닌 다음 주말 (2 월 11-12 일)에 완료 할 기회가 있습니다. (2 월 4 일 ~ 5 일).
상태 업데이트 (2 월 11 일) : 텍스트가 95 % 준비되었습니다. 내일 제출하겠습니다.

@petrochenkov 는 매우 합리적인 행동 과정처럼 보입니다.

@petrochenkov 저에게 합리적으로 들립니다. 또한 귀하의 노조 1.2 제안을 검토하고 몇 가지 의견을 제공했습니다. 전반적으로 나에게 좋아 보인다.

@joshtriplett 저는 @ rust-lang / lang 회의에서 체크리스트를 최신 상태로 유지하는 것에 대해 이야기하는 동안 실제로 확인하고 싶습니다. 각 요점에 대해 긍정적 인 결정을 내립니다. (즉, 이상적으로 @rfcbot 사용). 이것은 아마도 뚜렷한 문제 (또는 RFC 수정)를 암시 할 것입니다. 시간이 지남에 따라이 작업을 수행 할 수 있지만 그때까지는 공개 질문에 대한 답을 확실히 "정착"한 것 같지 않습니다. 이러한 맥락에서 관련 대화를 추출하여 수정 RFC 또는 여기에서 링크 할 수있는 문제로 요약하는 것은 모든 사람이 동일한 페이지에 있고 관심있는 사람은 누구나 할 수있는 일을 할 수 있도록 돕는 훌륭한 단계 인 것 같습니다. , 물론 @ rust-lang / lang 회원이나 목자들만이 아닙니다.

그래서 "Unions 1.2"RFC- https ://github.com/rust-lang/rfcs/pull/1897을 제출했습니다

이제 나는 조합의 보수적 인 부분 집합의 안정화를 제안하고 싶습니다-조합의 모든 필드는 Copy 이어야하고, 필드의 수는 0이 아니어야하며, 조합은 Drop 구현하지 않아야합니다. .
(그러나 마지막 요구 사항이 실행 가능한지 확실하지 않습니다. 왜냐하면 공용체를 구조체로 래핑하고 해당 구조체에 대해 Drop 를 구현하면 쉽게 우회 할 수 있기 때문입니다.)
이러한 공용체는이 언어 기능의 주요 소비자로 간주되는 FFI 라이브러리의 모든 요구를 충족합니다.

"Unions 1.2"RFC의 텍스트는 유형 punning이 허용된다는 것을 명시 적으로 확인한다는 점을 제외하고는 FFI 스타일 공용체에 대한 새로운 정보를 제공하지 않습니다.
편집 : "Unions 1.2"RFC는 또한 사소하게 파괴 가능한 Copy 필드에 안전하게 할당 할 것입니다 (https://github.com/rust-lang/rust/issues/32836#issuecomment-281296416, https 참조). : //github.com/rust-lang/rust/issues/32836#issuecomment-281748451), 이는 FFI 스타일 공용체에도 영향을줍니다.

이 텍스트는 안정화에 필요한 문서도 제공합니다.
"개요"섹션은 책에 복사하여 붙여넣고 참조에 "상세 디자인"을 붙여 넣을 수 있습니다.

ping @nikomatsakis

이와 같은 것이 정말로 언어의 일부로 추가되어야합니까? 약간의 unsafe 및 ptr::write() 사용하여 노동 조합 구현을 시작하는 데 약 20 분이 걸렸습니다.

use std::mem;
use std::ptr;


/// A union of `f64`, `bool`, and `i32`.
#[derive(Default, Clone, PartialEq, Debug)]
struct Union {
    data: [u8; 8],
}

impl Union {
    pub unsafe fn get<T>(&self) -> &T {
        &*(&self.data as *const _ as *const T)
    }

    pub unsafe fn set<T>(&mut self, value: T) {
        // "transmute" our pointer to self.data into a &mut T so we can 
        // use ptr::write()
        let data_ptr: &mut T = &mut *(&mut self.data as *mut _ as *mut T);
        ptr::write(data_ptr, value);
    }
}


fn main() {
    let mut u = Union::default();
    println!("data: {0:?} ({0:#p})", &u.data);
    {
        let as_i32: &i32 = unsafe { u.get() };
        println!("as i32: {0:?} ({0:#p})", as_i32);
    }

    unsafe {
        u.set::<f64>(3.14);
    }

    println!("As an f64: {:?}", unsafe { u.get::<f64>() });
}

내부 배열이 가장 큰 유형의 크기인지 확인하는 것 외에는 누군가가 그런 것을 생성 할 수있는 매크로를 작성하는 것이 어렵지 않을 것 같습니다. 그런 다음 완전히 일반적인 (그리고 끔찍하게 안전하지 않은) get::<T>() 대신 트레이 트 바인딩을 추가하여 얻을 수있는 유형을 제한 할 수 있습니다. 명명 된 필드를 원하는 경우 특정 getter 및 setter 메서드를 추가 할 수도 있습니다.

나는 그들이 다음과 같이 쓸 것이라고 생각하고 있습니다.

union! { Foo(u64, Vec<u8>, String) };

내 요점은 이미 상당히 복잡한 언어에 추가 구문과 복잡성을 추가하는 대신 라이브러리의 일부로 실행할 수있는 작업입니다. 게다가 proc 매크로를 사용하면 아직 완전히 안정되지 않았더라도 이미 가능합니다.

@ Michael-F-Bryan 아직 size_of 상수가 없습니다.

@ Michael-F-Bryan [u8] 배열을 갖는 것만으로는 충분하지 않으며 올바른 정렬 도 필요합니다. 실제로는 이미 매크로를 사용하여 공용체를 처리하지만 상수 size_of 및 align_of 부족으로 인해 올바른 공간을 수동으로 할당해야하며 선언적 매크로에 사용 가능한 ident 연결이 없기 때문에 I 게터와 세터 모두에 대한 이름을 수동으로 지정해야합니다. 합집합을 초기화하는 것조차도 지금은 몇 가지 기본값으로 초기화 한 다음 값을 내가 원하는 변형으로 설정해야하기 때문에 현재로서는 어렵습니다 (또는 정의에서 훨씬 더 자세한 조합을 구성하기 위해 다른 메서드 집합을 추가해야하기 때문). 노조의). 전체적으로 노동 조합에 대한 기본 지원보다 훨씬 더 많은 작업과 오류 및 추악한 경향이 있습니다. 이 기능이 왜 그렇게 중요한지 이해할 수 있도록 RFC와 관련 토론을 읽어야 할 것입니다.

정렬도 마찬가지입니다.

이제 syn 가 존재하므로 ident 연결이 너무 어렵지 않아야한다고 생각합니다. 전달 된 AST에서 작업을 수행 할 수 있으므로 두 개의 Ident를 가져 Ident 구현 AsRef<str> )을 추출한 다음 새 Ident 를 만들 수 있습니다. Ident::From<String>() 사용하여 둘을 연결 한 것입니다.

RFC는 기존 매크로 구현이 사용하기 얼마나 번거로운 지에 대해 많이 언급하지만, 최근 syn 및 quote 와 같은 상자가 생성되면서 이제는 proc 매크로를 훨씬 쉽게 수행 할 수 있습니다. 인체 공학을 개선하고 오류를 덜 발생시키는 데 큰 도움이 될 것 같습니다.

예를 들어, 유니온의 내부 버퍼가 0 인 MyUnion::default() 와 fn MyUnion::new<T>(value:T) -> MyUnion 를 가질 수 있습니다. T 에는 올바른 유형으로 만 초기화 할 수 있도록하는 특성 경계가 있습니다. .

정렬 및 크기 측면에서 표준 라이브러리 (예 : std :: mem :: align_of () 및 친구)의 mem 모듈을 사용할 수 있습니까? 내가 제안하는 모든 것은 매크로 확장 시간에 필요한 크기와 정렬을 파악할 수 있는지 여부에 달려 있다고 생각합니다. 99.9 %의 조합이 사용되는 경우 어쨌거나 기본 유형으로 수행되므로 유형의 이름을 가져 와서 정렬 또는 크기를 반환하는 도우미 함수를 작성할 수있을 것 같습니다 (아마도 컴파일러에게 물어볼 수 있습니다. 구현 세부 사항).

나는 인정한다. 내장 된 패턴 매칭은 매우 좋을 것이다. 그러나 대부분의 경우 FFI에서 사용하는 모든 유니온은 어쨌든 얇은 추상화 레이어로 래핑 될 것이다. 따라서 몇 개의 if / else 문을 사용하거나 도우미 함수를 사용할 수 있습니다.

정렬 및 크기 측면에서 표준 라이브러리 (예 : std :: mem :: align_of () 및 친구)의 mem 모듈을 사용할 수 있습니까?

크로스 컴파일 컨텍스트에서는 작동하지 않습니다.

@ Michael-F-Bryan이 모든 토론과 더 많은 내용이 https://github.com/rust-lang/rfcs/pull/1444 의 역사에서 이루어졌습니다. 특정 관심사에 대한 응답을 요약하려면 이미 언급 한 것 외에도 모든 대상 플랫폼 / 컴파일러의 패딩 및 정렬 규칙을 다시 구현하고 FFI 코드 전체에서 어색한 구문을 사용해야합니다 ( @ retep998 이 실제로 수행 한 작업). Windows 바인딩에 광범위하게 적용되며 어색함을 보증 할 수 있습니다.) 또한 proc 매크로는 현재 파생 용으로 만 작동합니다. 다른 곳에서는 구문을 확장 할 수 없습니다.

또한:

조합이 사용되는 경우의 99.9 %는 어쨌든 원시 유형으로 수행됩니다.

전혀 사실이 아닙니다. C 코드는 대부분의 공용체 필드가 ​​서로 다른 구조 유형으로 구성된 "구조체의 공용체 구조"패턴을 광범위하게 사용합니다.

주석의 '@petrochenkov 당 @rfcbot의 FCP 병합 https://github.com/rust-lang/rust/issues/32836#issuecomment -279256434

추가 할 항목이 없습니다. 봇만 트리거합니다.

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

• [x] @aturon
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @withoutboats

현재 나열된 문제가 없습니다.

이러한 검토자가 합의에 도달하면 최종 의견 기간이 시작됩니다. 이 과정에서 아직 제기되지 않은 주요 문제를 발견하면 알려주세요!

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

PSA : FFI 스타일 공용체에 영향을 미치는 하나 이상의 변경 사항으로 "Unions 1.2"RFC를 업데이트 할 것입니다. 안전 할당을 "미래 방향"에서 적절한 RFC로 간단하게 파괴 할 수있는 공용체 필드로 이동하겠습니다.

union.trivially_destructible_field = 10; // safe

왜:

• 사소하게 파괴 가능한 공용체 필드에 대한 할당은 공용체의 해석에 관계없이 무조건 안전합니다.
• 노동 조합 관련 unsafe 블록의 대략 절반을 제거합니다.
• 안정적인 코드에서 unused_unsafe 경고 / 오류가 많이 발생할 수 있으므로 나중에 수행하기가 더 어려워집니다.

@petrochenkov "사소하게 파괴 가능한 유니온 필드"또는 "완전히 사소하게 파괴 가능한 필드가있는 유니온"을 의미합니까?

모든 안전하지 않은 행동이 해석을 선택하는 읽을 때 발생하도록 제안하고 있습니까? 예를 들어, enum 및 기타 필드를 포함하는 공용체가있는 경우 공용체 값에 유효하지 않은 판별자가 포함되어 있습니까?

그럴듯 해 보이는 높은 수준에서. 그것은 내가 안전하지 않다고 생각하는 것들을 허용하지만, 일반적으로 Rust는 소멸자를 우회하거나 메모리 누수와 같은 것을 허용하지 않습니다. 낮은 수준에서 나는 그 소리를 고려하는 것을 주저합니다.

나는 그 부분 집합을 안정화시키는 것에 대해 괜찮다고 느낍니다. 이 Unions 1.2 RFC에 대한 내 의견을 아직 읽을 시간이 없었기 때문에 모르겠습니다! 어떤 경우에는 필드에 대한 안전한 액세스를 허용하는 것에 대해 어떻게 생각하는지 잘 모르겠습니다. 나는 안전하지 않은 것에 대한 "최소한"개념 (포인터 참조를 역 참조)을 만들기위한 우리의 노력이 실수라고 생각합니다. 돌이켜 보면 우리는 안전하지 않은 것 (예 : 많은 캐스트)을 더 많이 선언해야했습니다. LLVM과 복잡한 방식으로 상호 작용합니다. 나는 이것이 여기에서도 마찬가지라고 생각한다. 다시 말해, 안전하지 않은 코드 지침에 대한 더 많은 진전과 함께 unsafe 에 대한 규칙을 철회 할 수 있습니다.

안녕하세요.
"사소하게 파괴 할 수있는 필드"라는 문구를 수정했습니다.

모든 안전하지 않은 행동이 해석을 선택하는 읽을 때 발생하도록 제안하고 있습니까?

예. 쓰기만으로는 후속 읽기 없이는 위험 할 수 없습니다.

편집하다:

나는 돌이켜 보면 안전하지 않은 것에 대한 "최소한"개념을 만들려는 우리의 노력이 실수라고 생각합니다.

오.
안전한 쓰기는 안전하지 않은 현재 접근 방식과 완전히 일치하지만 변경하려는 경우 기다려야 할 것입니다.

나는이 부분 집합을 안정화시키는 것에 대해 기분이 좋지 않습니다. 일반적으로 부분 집합을 안정화 할 때 그것은 구문 부분 집합이거나 적어도 상당히 명백한 부분 집합입니다. 이 하위 집합은 나에게 약간 복잡하다고 느낍니다. 기능에 대한 결정이 너무 많아서 현재 구현을 안정화 할 준비가되지 않은 경우에는 모든 것을 잠시 동안 불안정하게 두는 것이 좋습니다.

@nrc
글쎄, 하위 집합은 "FFI 공용체", "C 공용체"또는 "C ++ 11 이전 공용체"와 같은 다소 분명합니다. 구문이 아니더라도 말입니다. 저의 초기 목표는이 하위 집합을 최대한 빨리 안정화하여 winapi 와 같은 라이브러리에서 사용할 수 있도록하는 것이 었습니다.
나머지 하위 집합과 그 구현에 대해 특별히 모호한 것은 없습니다. 이는 긴급하지 않으며 "Unions 1.2"RFC 프로세스가 완료 될 때까지 불분명 한 시간을 기다려야합니다. 나의 기대는 초기 부분 집합을 안정화 한 후 1, 2 또는 3 주기로 나머지 부품을 안정화시키는 것입니다.

안전한 현장 할당에 대한 궁극적 인 주장이 있다고 생각합니다.
안전하지 않은 필드 할당

unsafe {
    u.trivially_destructible_field = value;
}

안전한 완전 조합 할당과 동일합니다.

u = U { trivially_destructible_field: value };

안전 버전은 역설적으로 덜 안전합니다. trivially_destructible_field 외부에있는 u 의 바이트를 undefs로 덮어 쓰는 반면 필드 할당은 그대로 두는 것에 대한 보장이 있기 때문입니다.

@petrochenkov 그 극단은 size_of_val(&value) == 0 .

두 스 니펫 간의 동등성은 해당 필드가
"사소한 파괴 가능", 아니?

그런 의미에서 안전하지만 일부 경우에만 이러한 과제를
나에게는 매우 일관성이 없어 보입니다.

2017 년 2 월 22 일 14:50, "Vadim Petrochenkov" [email protected]
썼다 :

안전한 현장 할당에 대한 궁극적 인 주장이 있다고 생각합니다.
안전하지 않은 필드 할당

안전하지 않은 {
u.trivially_destructible_field = 값;
}

안전한 완전 조합 할당과 동일합니다.

u = U {trivially_destructible_field : 값};

안전 버전은 역설적으로 덜 안전합니다.
undefs로 trivially_destructible_field 외부의 u의 바이트를 덮어 씁니다.
필드 할당은 그대로 두는 것에 대한 보증을 제공합니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32836#issuecomment-281660298 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AApc0lUOXLU5xNTfM5PEfEz9nutMZhXUks5rfC8UgaJpZM4IDXsj
.

@eddyb

그 극단은 size_of_val (& value) == 0, 맞죠?

네.

나기사
오탐의 많은 부분을 제거하는 간단한 추가 규칙 하나가 왜 극도로 일관성이 없는지 이해하지 못합니다. "일부 사례 만"은 특히 모든 FFI 조합을 포함합니다.
저는 "매우 일관성이없는"것은 큰 과대 평가라고 생각합니다. " mut 변수 만 할당 할 수 있습니까? 끔찍한 불일치!"만큼 크지는 않지만 여전히이 방향으로 가고 있습니다.

@petrochenkov 이러한 경우를 고려하십시오.

// Somebody Somewhere in some crate (v 1.0.0)
struct Peach; // trivially destructible
union Banana { pub actually: Peach }

// Somebody Else in their dependent crate
extern some crate;
fn somefn(banana: &mut Banana) {
    banana.actually = Peach;
}

이제 특성 구현을 추가하는 것은 일반적으로 주요 변경 사항이 아니므로 Somebody Somewhere 씨는 다음 구현을 추가하는 것이 좋습니다.

impl Drop for Peach { fn drop(&mut self) { println!("Moi Peach!") }

1.1.0 (1.0.0 AFAIK와 호환되는 semver) 버전의 상자를 출시합니다.

갑자기 Mr. Somebody Else의 상자가 더 이상 컴파일되지 않습니다.

fn somefn(banana: &mut Banana) {
    banana.actually = Peach; // ERROR: Something something… unsafe assingment… somewhat somewhat trivially indestructible… 
}

따라서 때로는 통합 필드에 대한 안전한 할당을 허용하는 것이 mut 지역 주민 만 변형 가능하게되는 것만 큼 사소하지 않습니다.

이 예제를 작성하면서 솔직히 어떤 입장을 취해야할지 확신 이

나기사
이것은 좋은 주장이며 호환성에 대해서는 생각하지 않았습니다.

그래도 문제는 해결할 수있는 것 같습니다. 호환성 문제를 방지하려면 일관성과 동일한 작업을 수행하십시오. 부정적인 추론을 피하십시오. 즉, "trivially-destructible"== "구성 요소가 Drop 를 가장 가까운 양의 근사값으로 구현하지 않음-" Copy 구현 ".
Copy 유형은 Copy 이전 버전과 호환 가능하게 구현을 취소 할 수 없으며, Copy 유형은 특히 FFI 공용체의 컨텍스트에서 여전히 대부분의 "사소한 파괴 가능"유형을 나타냅니다.

Drop 구현은 이미 이전 버전과 호환되지 않으며 통합 기능과 관련이 없습니다.

// Somebody Somewhere in some crate (v 1.0.0)
struct Apple; // trivially destructible
struct Pineapple { pub actually: Apple }

// Somebody Else in their dependent crate
extern some crate;
fn pineapple_to_apple(pineapple: Pineapple) -> Apple {
    pineapple.actually
}

// some crate v 1.1.0
impl Drop for Pineapple { fn drop(&mut self) { println!("Moi Pineapple!") }

fn pineapple_to_apple(pineapple: Pineapple) -> Apple {
    pineapple.actually // ERROR: can't move out of Pineapple
}

차례로 Drop을 구현하면 암시 적 복사가 삭제되는 것처럼 들립니다. 그리고 복사
의지 할 수 있습니다.

2017 년 2 월 22 일 수요일 오전 10시 11 분에 jethrogb [email protected] 은 다음과 같이 썼습니다.

Drop 구현은 이미 이전 버전과 호환되지 않으며
유니온 기능과 관련이 없습니다.

// Somebody Somewhere in some Crate (v 1.0.0)
struct Apple; // 사소하게 파괴 가능
struct Pineapple {실제로 pub : Apple}

// 종속 상자에있는 다른 사람
상자를 꺼내십시오.
fn pineapple_to_apple (파인애플 : 파인애플)-> Apple {
파인애플. 실제로
}

// 일부 상자 v 1.1.0
impl Drop for Pineapple {fn drop (& mut self) {println! ( "Moi Pineapple!")}

fn pineapple_to_apple (파인애플 : 파인애플)-> Apple {
banana.actually // 오류 : 파인애플 밖으로 이동할 수 없습니다.
}

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/32836#issuecomment-281752949 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABxXhgbFgRNzYOsU4c6Gu1KFfwdjDHn3ks5rfHpYgaJpZM4IDXsj
.

뿡뿡
이 문제를 언급하고 싶었지만 특별한 전제 조건이 거의 없기 때문에 언급하지 않았습니다. Drop 구현하는 구조체에는 공용 필드가 있어야하고 해당 필드는 Copy 이어서는 안됩니다. 유니온 케이스는 모든 구조체에 무조건 영향을 미칩니다.

@petrochenkov 나는 아마도 노동 조합을 만드는 것이 안전하지 않아야한다는 주장이라고 생각합니다 :)

@petrochenkov 하위 집합을 안정화하기위한 개발 및 야간 사용자 경험 경로는 무엇입니까? 사람들이 부분 집합이 안정화 되기 전에 구체적인 경험을 얻을 수 있도록 부분 집합에 대해 먼저 새로운 기능 게이트를 추가합니까?

뿡 빵뀨
내가 가정 한 것은이 하위 집합에 대해 #[feature(untagged_unions)] 요구를 중지하고 새로운 기능이나 다른 관료주의가 필요하지 않다는 것입니다.
FFI 스타일의 조합은 가장 자주 사용되는 조합으로 간주되므로 새로운 기능은 안정화 직전에 보장 된 파손을 의미합니다.

정렬 및 패킹 속성이 아직 구현되지 않았기 때문에 (안정화되지 않았으므로) 아직 안정화 할 필요가 없습니다.

뿡뿡
포장? #[repr(packed)] 을 의미하는 경우 align(>1) 속성과 달리 현재 유니온에서 지원됩니다.

@petrochenkov #[repr(packed(N))] . winapi에서는 1 이외의 패킹이 필요합니다. 특별히 유니온에서 이러한 것들을 지원해야하는 것은 아닙니다. 동시에 모든 것을 얻을 수 없다면, 최소 Rust 요구 사항을 늘리기 위해 새로운 메이저 버전으로 점프하고 싶지 않습니다.

여기에서 플레이 상태를 약간 명확히하기 위해 :

현재 FCP 제안은 순수한 Copy 공용체만을위한 것입니다. 내가 아는 한, 기본적으로 "우리가 안정되어야 하는가?"라는 질문 외에는 별다른 질문이없는 경우입니다. FCP에 대한 동의 이후 논의는 모두 @petrochenkov 의 새로운 RFC에 관한 것이

@nrc 및 @nikomatsakis , IRC에 대한 토론에서, 나는 당신이 당신의 상자를 체크 할 준비가되었다고 생각하지만, 나는 당신에게 맡길 것입니다 ;-)

: bell : 지금은 위 의 에 따라 최종 댓글 기간을 입력합니다 . :벨:

안녕하세요.
최근에 떠오른 아이디어가 도움이 될 것 같습니다. (https://internals.rust-lang.org/t/automatic-marker-trait-for-unconditionally-valid-repr-c-types/5054)

노조를 염두에두고 제안되지는 않았지만 설명 된 Plain 특성 (자전거 흘림에 따라 다름)은 Plain 유형으로 만 구성된 모든 노조를 안전하지 않게 사용할 수 있도록합니다. 메모리의 _any_ 비트 패턴이 똑같이 유효하다는 속성을 코드화하여 메모리를 제로화하여 초기화 문제를 해결할 수 있으며 읽기가 UB를 호출 할 수 없도록합니다.

FFI의 맥락에서 정의 된대로 Plain 가되는 것은 이러한 코드가 대부분의 경우 사운드에 대한 사실상의 요구 사항이며, 비 Plain 유형이 유용한 경우는 드물고 설정하기 어렵습니다. 안전하게.

명명 된 특성의 실제 존재는 제쳐두고이 기능을 두 개로 나누는 것이 현명 할 수 있습니다. 자격이없는 union 는 요구 사항을 적용하고 안전하지 않은 사용을 허용하고 unsafe union 는 콘텐츠 요구 사항이 완화되고 사용자에게는 더 많은 골칫거리가됩니다. 그것은 미래에 다른 것을 추가하는 길을 막지 않고 안정화를 허용 할 것입니다.

@ le-jzr
이것은 노조와 충분히 직교하는 것처럼 보입니다.
나는 가까운 장래에 Rust로 Plain 를 받아들이는 것을 추정 할 것입니다. 그것에.

@petrochenkov 나는 내 제안에 대한 폐쇄를 기다리는 동안 노조를 연기

따라서 나중에 새로운 키워드를 추가하지 않고도 무조건 안전한 버전을 도입 할 수 있도록 선언 unsafe union 제안합니다. 완전히 안전한 버전이면 대부분의 사용 사례에 충분합니다.

편집 : 내가 말하는 것을 명확히하려고했습니다.

이 가능성이 현재와 미래의 설계를 알릴 수있는 또 다른 곳은 초기화입니다. 무조건 안전한 유니온을 위해 예약 된 전체 메모리 스팬이 0이되어야합니다. 현재 버전을 사용하더라도 잠재적 인 UB 시나리오를 줄이고 공용체 사용을 더 쉽게 할 수 있습니다.

이제 최종 댓글 기간이 완료되었습니다.

이제 병합 할 FCP가 완료되었으므로 다음 단계는 무엇입니까? 1.19에서 이것을 안정화하는 것이 좋을 것입니다.

@bstrie 그래서 당신은 기능을 안정화하고 싶습니다

누군가 @rfcbot 메시지에 더 자세한 내용을 추가 할 수 있다면 여기 소스 코드 ). 프로세스에 익숙하지 않은 사람이 더 쉽게 작업을 진행할 수 있습니다.

이것을 1.19로 가져 오기위한 경로는 분명합니다. 누구에게 관심이 있습니까? cc @joshtriplett

NonZero 열거 형 레이아웃 최적화가 union 통해 적용되도록 보장됩니까? 예를 들어, Option<ManuallyDrop<&u32>> 표현 안 None 널 포인터로합니다. Some(ManuallyDrop::new(uninitialized::<[Vec<Foo>; 10]>())).is_some() 는 초기화되지 않은 메모리를 읽어서는 안됩니다.

https://crates.io/crates/nodrop(https://crates.io/crates/arrayvec 에서 사용)에는이를 처리 할 수있는 해킹이 있습니다.

안녕하세요.
이것은 현재 RFC 에서 해결되지 않은 질문으로 표시되어 있습니다.
현재 구현에서이 프로그램

#![feature(untagged_unions)]

struct S {
    _a: &'static u8
}
union U {
    _a: &'static u8
}

fn main() {
    use std::mem::size_of;
    println!("struct {}", size_of::<S>());
    println!("optional struct {}", size_of::<Option<S>>());
    println!("union {}", size_of::<U>());
    println!("optional union {}", size_of::<Option<U>>());
}

인쇄물

struct 8
optional struct 8
union 8
optional union 16

즉, 최적화가 수행되지 않습니다.
cc https://github.com/rust-lang/rust/issues/36394

이것은 1.19를 만들 가능성이 낮습니다.

@brson

이것은 1.19를 만들 가능성이 낮습니다.

안정화 PR 이 병합됩니다.

태그가 지정되지 않은 유니온이 현재 1.19로 출시됨 (일부 https://github.com/rust-lang/rust/pull/42068)-이 문제에 남아있는 것이 있습니까 아니면 종료해야합니까?

안녕하세요.
Copy 필드가 아닌 전체 조합의 세계가 여전히 존재합니다!
진행 상황은 대부분 설명 / 문서 RFC (https://github.com/rust-lang/rfcs/pull/1897)에서 차단됩니다.

8 월 이후 Copy 필드가 아닌 조합에 대한 진전이 있었습니까? Unions 1.2 RFC가 멈춘 것 같습니다 (impl 기간으로 인해 추측하고 있습니까?)

단일 유형의 공용체에 대해서만 ?Sized 유형을 공용체에 허용하면 https://github.com/rust-lang/rust/issues/47034를 쉽게 구현할 수

```녹
수동으로 결합{
값 : T
}

@mikeyhew 실제로 최대 한 가지 유형 만 크기를 조정할 수 있도록 요구하면됩니다.

union 사용하여 Rust 코드를보고 있는데 정의되지 않은 동작을 호출하는지 여부를 알지 못합니다.

참조 [items :: unions] 는 다음 만 언급합니다.

비활성 필드도 공용체가 유지하는 현재 값과 레이아웃이 충분히 호환되는 경우 (동일한 구문 사용) 액세스 할 수 있습니다. 호환되지 않는 필드를 읽으면 정의되지 않은 동작이 발생합니다.

하지만 [items :: unions] 나 [type_system :: type_layout] 에서 "레이아웃 호환"의 정의를 찾을 수 없습니다.

RFC를 살펴보면 "레이아웃 호환"에 대한 정의를 찾을 수 없었습니다. RFC 1897 : Unions 1.2 (병합되지 않음)에서 작동해야하는 것과 작동하지 않아야하는 예제 만 손으로 ​​흔들 었습니다.

RFC1444 : 유니온 은 정의되지 않은 동작을 호출하지 않는 한 유니온을 변형으로 변환하는 것만 허용하는 것처럼 보이지만 그럴 때 RFC에서 아무 곳도 찾을 수 없습니다.

공용체를 사용하는 코드 조각이 어딘가에 기록 된 동작을 정의했는지 여부 (그리고 정의 된 동작이 무엇인지)를 알려주는 _precise_ 규칙입니까?

@gnzlbg 첫 번째 근사치 : 패딩에 액세스 할 수없고, 유효하지 않은 판별을 포함하는 열거 형에 액세스 할 수 없으며, true 또는 false가 아닌 값을 포함하는 부울에 액세스 할 수 없으며, 유효하지 않거나 신호를 보내는 부동 소수점 값에 액세스 할 수 없습니다. , 그리고 그와 같은 몇 가지 다른 것들.

공용체와 관련된 특정 코드를 가리키면 우리는 그것을보고 정의되지 않은 작업을하고 있는지 알려줄 수 있습니다.

첫 번째 근사값으로 : 패딩에 액세스 할 수없고, 유효하지 않은 판별자를 포함하는 열거 형에 액세스 할 수 없으며, true 또는 false가 아닌 값을 포함하는 부울에 액세스 할 수 없으며, 유효하지 않거나 신호를 보내는 부동 소수점 값에 액세스 할 수 없습니다. 이와 같은 몇 가지 다른 것.

실제로 최근의 합의는 임의의 부동 소수점을 읽는 것이 좋다는 것입니다 (# 46012).

한 가지 더 요구 사항을 추가 할 것입니다. 소스 및 대상 공용체 변형 모두 #[repr(C)] 이므로 구조체 인 경우 모든 필드 (재귀 적으로)도 마찬가지입니다.

@Amanieu 내가 정정 서, 감사합니다.

그래서 나는 규칙이 어디에도 쓰여 있지 않다고 생각합니까?

새 인터페이스에서 stdsimd 를 사용하는 방법을 찾고 있습니다. 일부 추가 기능을 안정화하지 않는 한 다음과 같이 일부 simd 유형으로 유형 punning을 수행하기 위해 공용체를 사용해야합니다.

https://github.com/rust-lang-nursery/stdsimd/blob/03cb92ddce074a5170ed5e5c5c20e5fa4e4846c3/coresimd/src/x86/test.rs#L17

AFAIK는 하나의 유니온 필드를 쓰고 다른 필드를 읽는 것은 transmute_copy 를 사용하는 것과 매우 유사하지만 동일한 제한이 있습니다. 이러한 제한이 여전히 약간 모호하다는 것은 노조에 국한되지 않습니다.

이를 위해 링크 한 함수는 transmute::<__m128d, [f64; 2]> 사용할 수 있습니다. 유니온 버전이 더 좋긴하지만 적어도 현재 존재하는 변환이 제거 된 경우 : A { a }.b[idx] 일 수 있습니다.

@rkruppe 나는 그 lint를 추가하기 위해 clippy 문제를 채웠다 : https://github.com/rust-lang-nursery/rust-clippy/issues/2361

링크 한 함수는 transmute를 사용할 수 있습니다 :: <__ m128d i = "8">

나는 내가 찾고있는 규칙이 언제 transmute가 정의되지 않은 동작을 호출하는지라고 생각합니다 (그래서 나는 그것들을 찾아 보겠습니다).

조합에 대한 언어 참조가 "레이아웃 호환성"을 언급하고 그대로 두는 대신 transmute (변환 규칙이 아직 100 % 명확하지 않은 경우에도) 측면에서 공용체에 대한 규칙을 지정했다면 도움이되었을 것입니다. 그것에. "레이아웃 호환성"에서 "변환이 정의되지 않은 동작을 호출하지 않는 경우 유형이 레이아웃 호환 가능하며 유형 punning을 통해 액세스 할 수 있음"으로의 도약은 분명하지 않았습니다.

명확하게 말하면 transmute [_copy]는 공용체보다 "더 원시적"이 아닙니다. 사실 transmute_copy는 말 그대로 포인터 as 캐스트와 ptr::read 입니다. transmute 추가로 mem::uninitialized (더 이상 사용되지 않음) 또는 MaybeUninitialized (유니온) 또는 이와 유사한 것이 필요하며, 효율성을 위해 내재적으로 구현되지만 유형은 다음과 같습니다. punning memcpy. 내가 transmute와 연결을 그린 주된 이유는 그것이 오래되고 역사적으로 지나치게 강조 되었기 때문에 현재 우리는 특히 transmute에 초점을 맞춘 더 많은 글과 민속 지식을 가지고 있기 때문입니다. 무엇이 유효하고 무엇이 유효하지 않은지 (그리고 사양이 설명 할 것)을 지시하는 실제 기본 개념은 값이 메모리에 바이트로 저장되는 방법과 어떤 바이트 시퀀스가 ​​어떤 유형으로 읽을 UB인지입니다.

수정 : transmute는 실제로 초기화되지 않은 저장소가 필요하지 않습니다 (내재 함수, 공용체 또는 기타를 통해). 효율성은 제쳐두고, 다음과 같이 할 수 있습니다 (예상하지 않은, 당황스러운 오타가 포함될 수 있음).

fn transmute<T, U>(x: T) -> U {
    assert!(size_of::<T>() == size_of::<U>());
    let mut bytes = [0u8; size_of::<U>()];
    ptr::write(bytes.as_mut_ptr() as *mut T, x);
    mem::forget(x);
    ptr::read(bytes.as_ptr() as *const U)
}

transmute의 유일한 "마법적인"부분은 컴파일 타임에 유형 매개 변수를 동일한 크기

참조 및 Unions 1.2 RFC는 일반적으로 변환 규칙이 정해지지 않았기 때문에이 문제에 대해 의도적으로 모호합니다.
의도는 " repr(C) 공용체의 경우 타사 ABI 사양을 참조하십시오. repr(Rust) 공용체의 경우 레이아웃 호환성은 대부분 지정되지 않습니다 (그렇지 않은 경우)."

드롭 필드가있는 공용체의 드롭 검사 의미를 다시 살펴보기에는 너무 늦었습니까?

원래 문제는 ManuallyDrop 를 추가하면 조세핀이 불건전 해졌다는 것입니다. 왜냐하면 소멸자를 먼저 실행하지 않고 백업 저장소를 회수하지 않고 영구 차용 된 값에 의존했기 때문입니다.

요약 된 예제는 https://play.rust-lang.org/?gist=607e2dfbd51f4062b9dc93d149815695&version=nightly에 있습니다. 아이디어는 Pin<'a, T> 유형이 있고, pin(&'a self) -> &'a T 메소드는 안전에 의존하는 " pin.pin() 호출 한 후 핀을 지원하는 메모리가 회수 된 경우 핀의 소멸자가 실행되었을 것입니다. "

이 불변성은 #[allow(unions_with_drop_fields)] 가 추가 될 때까지 Rust에 의해 유지되었고 ManuallyDrop https://doc.rust-lang.org/src/core/mem.rs.html#949에서 사용되었습니다.

드롭 검사기가 드롭 필드가있는 공용체가 Drop impl을 갖는 것으로 간주하면 불변이 복원됩니다. 이것은 획기적인 변경 사항이지만 야생의 코드가 현재 의미 체계에 의존하는 것 같지 않습니다.

IRC 대화 : https://botbot.me/mozilla/rust-lang/2018-02-01/?msg=96386869&page=3

Josephine 문제 : https://github.com/asajeffrey/josephine/issues/52

cc : @nox @eddyb @pnkfelix

원래의 문제는 ManualDrop을 추가하면 Josephine이 불건전 해졌습니다.

소멸자는 실행이 보장되지 않습니다. Rust는 그것을 보장하지 않습니다. 시도하지만 예를 들어 std::mem::forget 는 안전한 함수로 만들어졌습니다.

드롭 검사기가 드롭 필드가있는 공용체가 Drop impl을 갖는 것으로 간주하면 불변이 복원됩니다. 이것은 획기적인 변경 사항이지만 야생의 코드가 현재 의미 체계에 의존하는 것 같지 않습니다.

유니온의 어떤 필드가 유효한지 알 수 없기 때문에 유니온은 대체로 안전하지 않습니다. 노조는 자동 Drop impl을 가질 수 없습니다 . 그러한 impl을 원한다면, Drop impl이있는 union 필드가 유효한지 여부를 알아야하는 수단을 고려하여 수동으로 작성해야합니다.

한 설명은 여기에 : 나는 우리가 이제까지와 노조 허용해야한다 생각하지 않는다 Drop 하지 않을 경우 오류 별 기본 보풀, 적어도 경고-에 의해 기본 보풀없이 기본적으로 필드를. unions_with_drop_fields 는 안정화 프로세스의 일부로 사라지지 않아야합니다.

편집 : 죄송합니다, "닫기 및 의견"을 누르라는 뜻이 아닙니다.

@joshtriplett 예, Rust는 소멸자가 실행될 것이라고 보장하지 않지만 mem::forget 이있는 경우에도 마찬가지입니다.

이것은 Joephine이 다소 장난스럽게 의존 한 것이지만 드롭 체커가 unions_with_drop_fields 처리하는 방식 때문에 더 이상 사실이 아닙니다.

allow(unions_with_drop_fields) 이 안전하지 않은 주석으로 간주되면 괜찮을 것입니다. 이것은 급격한 변경이 아닙니다. AFAICT, allow(unions_with_drop_fields) 확인하는 데 deny(unsafe_code) 있으면됩니다.

@asajeffrey 나는 여전히 Pin 일을 이해하려고 노력하고 있습니다. 예를 올바르게 따르면 이것이 "작동"하는 이유는 fn pin(&'a Pin<'a, T>) -> &'a T 가 차입이 다음과 같이 지속되도록하기 때문입니다. 유형에 주석이 달린 수명 'a 수명과 그 수명은 더욱 불변합니다.

흥미로운 관찰입니다! 나는이 속임수를 몰랐다. 내 직감은 이것이 "우연히"작동한다는 것입니다. 즉, 안전한 Rust가 소멸자가 실행되는 것을 방지하는 방법을 제공하지는 않지만 "계약"의이 부분을 만들지는 않습니다. 특히 https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html 은 누출을 나열하지 않습니다.

IMO는 우연히 또는 의도적으로 작동하는지는 중요하지 않습니다. ManuallyDrop 기존 (안전하지 않은 코드를 구현해야 함) 이전에이 트릭으로 실행되는 Drop 를 피할 수있는 방법이 없었으며 이제는 더 이상이를 신뢰할 수 없습니다.

ManuallyDrop 의 추가는 기본적으로 Rust의 깔끔한 행동을 죽였고, 처음부터 의존해서는 안된다는 말은 순환 추론처럼 들립니다. ManuallyDrop Pin::pin 전화를 허용하지 않았다면 Pin::pin 건전하게 만들 수있는 다른 방법이 있습니까? 나는 그렇게 생각하지 않는다.

나는 우리가 rustc이 우연히 우연히 지금 제공하는 모든 보증을 보존 할 수 있다고 생각하지 않습니다. 우리는 이러한 보장이 무엇인지 알지 못하기 때문에 돼지를 찌르고 안정화시킬 것입니다. 가방 속의 고양이 ";)-내가 말하고 싶은 것은 우리가 무엇을 안정화 시킬지 전혀 모른다는 것입니다.)

또한 이것은 양날의 검입니다. 우리가 제공하기로 결정한 모든 추가 보증은 안전하지 않은 코드가 처리해야하는 것입니다. 단지뿐만 아니라 새로운 안전하지 않은 코드를 사용, 기존 안전하지 않은 코드 (의식하지 않고 자동으로 어딘가 crates.io에 앉아)를 깰 수있는 새로운 보증을 발견 그래서 (후자는 여기에 사건이었다).

예를 들어, 어휘 수명이 비 어휘 수명에 의해 깨지는 안전하지 않은 코드를 가능하게한다는 것은 매우 상상할 수 있습니다. 현재 모든 수명이 잘 중첩되어 있습니다. 안전하지 않은 코드가이를 악용 할 수있는 방법이 있습니까? 비 어휘 수명에만 겹치는 수명이있을 수 있지만 다른 수명에는 포함되지 않습니다. 이로 인해 NLL이 주요 변경 사항이됩니까? 내가하지 희망!

ManualDrop이 Pin :: pin 호출을 허용하지 않았다면 Pin :: pin 호출이 소리가 나지 않게 만드는 다른 방법이 있습니까? 나는 그렇게 생각하지 않는다.

unsafe 코드를 사용하면있을 것입니다. 따라서이 Pin 트릭 사운드를 선언하면 ManuallyDrop 가 괜찮다고 판단되면 소리가 나는 안전하지 않은 코드 unsound 를 선언 하게됩니다.

우리가 설명한 것은 Rust를 GC와 통합하는 매우 인체 공학적인 방법입니다. 내가 말하려는 것은이이 일을하는 것이 바로 사고라고 우리에게 얘기를 나에게 잘못 소리이다 내가 가진 노동 조합 제약하지 않는 모든 사용 사례로 찾을 수 없을 때 우리는 그것에 대해 잊지해야 Drop 필드는 @asajeffrey가 여기에 설명했고 이것이 실제로 조세핀을 파괴하는 유일한 사마귀 일 때입니다.

누군가가 ManuallyDrop 없이도 불건전하다는 것을 보여줄 수 있다면 잊어 버릴 것입니다.

내가 말하려는 것은 이것이 효과가 있었던 사고라고 말하는 것이 잘못된 것 같다는 것입니다.

나는이 트릭이 "설계"되었다는 징후가 보이지 않기 때문에 그것을 사고라고 부르는 것이 상당히 공정하다고 생각합니다.

그리고 우리는 그것을 잊어야한다고

나는이 부분이 내 개인적인 직감이라는 것을 더 분명히해야했다. 나는 이것을 "행복한 사고"라고 선언하고 실제로 보증하는 것이 합리적 행동 지점이 될 수 있다고 생각합니다. 실제로 다른 모든 unsafe 코드가이 보증을 존중한다고 합리적으로 확신한다면 이 보증을 제공하는 것이 ManuallyDrop 사용 사례보다 더 중요합니다. 이것은 leakpocalypse와 비슷한 절충안입니다. 우리는 케이크를 먹을 수없고 먹을 수도 없습니다 (현재 API와 drop 모두 Rc 를 가질 수 없습니다- 기반 범위 스레드; ManuallyDrop 및 Pin ) 둘 다 가질 수 없으므로 어느 쪽이든 결정을 내려야합니다.

즉, 여기에 제공된 실제 보증을 정확한 방식으로 표현하기가 어렵 기 때문에 개인적으로 " ManuallyDrop 는 괜찮습니다"라는 측면에 더 의지하게됩니다.

실제로 다른 모든 unsafe 코드가이 보증을 존중하고이 보증을 제공하는 것이 ManuallyDrop 사용 사례보다 더 중요하다고 합리적으로 확신하는 경우. 이것은 leakpocalypse와 비슷한 절충안입니다. 우리는 케이크를 먹을 수없고 먹을 수도 없습니다 (현재 API와 drop 모두 Rc 를 가질 수 없습니다- 기반 범위 스레드; ManuallyDrop 및 Pin ) 둘 다 가질 수 없으므로 어느 쪽이든 결정을 내려야합니다.

충분히 공평합니다. 나는 그것에 진심으로 동의합니다. @asajeffrey 가 결국 정의되지 않은 동작으로 설명한 것을 고려하면 drop 기반 범위 스레드 API를 다시 가져올 수 있습니다.

내가 이해하는 한 Alan의 제안은 ManuallyDrop 을 제거하지 않는 것입니다. dropck이 (및 Drop 필드가있는 다른 유니온) 소멸자가 있다고 가정합니다. (그 소멸자는 아무 일도하지 않지만, 그 단순한 존재는 dropck이 받아들이거나 거부하는 프로그램에 영향을 미칩니다.)

누군가가 ManualDrop 없이도 소리가 나지 않았다는 것을 보여줄 수 있다면 잊어 버릴 것입니다.

이것이 자격이되는지 확실하지 않지만 여기에 첫 번째 시도가 있습니다. ManuallyDrop 이전에 union Rust에서 작동하는 ManuallyDrop 와 같은 어리석은 구현입니다.

pub mod manually_drop {
    use std::mem;
    use std::ptr;
    use std::marker::PhantomData;

    pub struct ManuallyDrop<T> {
        data: [u8; 32],
        phantom: PhantomData<T>,
    }

    impl<T> ManuallyDrop<T> {
        pub fn new(x: T) -> ManuallyDrop<T> {
            assert!(mem::size_of::<T>() <= 32);
            let mut data = [0u8; 32];
            unsafe {
                ptr::copy(&x as *const _ as *const u8, &mut data[0] as *mut _, mem::size_of::<T>());
            }
            mem::forget(x);
            ManuallyDrop { data, phantom: PhantomData }
        }

        pub fn deref(&self) -> &T {
            unsafe {
                &*(&self.data as *const _ as *const T)
            }
        }
    }
}

(예, 정렬을 올바르게하기 위해 더 많은 작업을해야 할 수도 있지만 일부 바이트를 희생하여 수행 할 수도 있습니다.)
휴식 시간을 보여주는 놀이터 Pin : https://play.rust-lang.org/?gist=fe1d841cedb13d45add032b4aae6321e&version=nightly

이것이 제가 위의 양날 검이 의미하는 바입니다. 제가 볼 수있는 한 제 ManuallyDrop 는 우리가 내놓은 모든 규칙을 존중합니다. 따라서 ManuallyDrop 및 Pin 두 가지 호환되지 않는 안전하지 않은 코드가 있습니다. 누가 "맞아"? Pin 는 우리가 한 번도하지 않은 보증에 의존하고 있으므로 여기서는 "잘못되었습니다"라고 말하고 싶습니다. 그러나 이것은 증거가 아니라 판단 요청입니다.

이제 흥미 롭습니다. 고정 항목의 일부 버전에서 Pin::pin 는 &'this mut Pin<'this, T> 를 사용하지만 ManuallyDrop 에 DerefMut impl이있는 것은 부당하지 않습니다. ?

다음은 @RalfJung 의 (당연히) &mut -taking pin 메서드로 Pin 을 (를) 여전히 깨는 것을 보여주는 놀이터입니다.

https://play.rust-lang.org/?gist=5057570b54952e245fa463f8d7719663&version=nightly

ManualDrop이 DerefMut impl을 갖는 것은 부당하지 않을 것입니다.

예,이 예제에 필요한 API를 방금 추가했습니다. 명백한 deref_mut 는 잘 작동합니다.

내가 이해하는 한 Alan의 제안은 ManualDrop을 제거하는 것이 아니라 dropck이 (및 Drop 필드가있는 다른 공용체) 소멸자가 있다고 가정하게 만드는 것입니다. (그 소멸자는 아무 일도하지 않지만, 그 단순한 존재는 dropck이 받아들이거나 거부하는 프로그램에 영향을 미칩니다.)

아, 나는 그것을 놓쳤다. 미안합니다. 내 예제에 다음을 추가하면 계속 작동합니다.

    unsafe impl<#[may_dangle] T> Drop for ManuallyDrop<T> {
        fn drop(&mut self) {}
    }

#[may_dangle] 제거하는 경우에만 Rust가 거부합니다. 그래서, 적어도, 우리는 위의 코드 위반 몇 가지 규칙을 마련 할 것 - 그것을 만들기 때문에 그냥 "우리는이와 호환되지 않는 사운드가되고 싶어요 몇 가지 코드가 존재한다"라는 잘못된 호출입니다 일부 코드를보고 소리인지 확인하는 것은 거의 불가능합니다.

이 "우연한 보증"에 대해 나를 가장 불안하게 만드는 것은 이것이 작동하는 하나의 좋은 이유 를 보지 못하기 Pin 이 아니라 기반으로 - 작업에이 기반으로하지 않습니다는 "여기에 꽤 명확하게 PERMA-빌려 데이터가 유출 될 수 없다 말한다, 녹 컴파일러의 일부 메커니즘, 또는 어떤 종류의 시스템 보장" "우리는 열심히 노력했지만 영구 차용 된 데이터를 유출 할 수 없었으므로 괜찮다고 생각합니다." 건전성을 위해 이것에 의존하는 것은 나를 매우 긴장하게 만듭니다. 편집 : dropck이 관련되어 있다는 사실은 컴파일러 의이 부분에 불쾌한 건전성 버그의 역사가 있기 때문에 나를 더욱 긴장하게 만듭니다. 이것이 작동하는 이유는 영구 대출이 안전한 drop 과 상충되기 때문인 것 같습니다. 이것은 실제로 "영구적으로 빌린 데이터로 무엇을 할 수 있는지에 대한 철저한 사례 분석을 기반으로 한 이유"인 것 같습니다.

이제 공정하게 말하면 내부 변경성에 대해 비슷한 말을 할 수 있습니다. 공유 참조를 통한 수정을 허용하는 것은 실제로 올바른 API를 선택하면 어떤 경우에는 안전하게 작동하는 경우입니다. 그러나이 작업을 수행하려면 실제로 컴파일러 ( UnsafeCell )에서 명시적인 지원이 필요했습니다. 왜냐하면 최적화와 충돌하기 때문이며, 내부 가변성없이 소리가 나지만 내부 가변성으로는 소리가 나지 않는 안전하지 않은 코드 가 있기 때문입니다. 또 다른 차이점은 내부 변경이 처음부터 디자인 목표 였다는 것입니다 (또는 매우 초기부터 – 이것은 Rust 커뮤니티에서 제 시간 이전의 방법입니다). "영구적으로 빌린 것은 유출되지 않습니다"의 경우가 아닙니다. 그리고 마지막으로 내부 변경 가능성에 대해 "공유는 돌연변이를 위험 하게 만들지 만 불가능 하지는 않습니다. 공유 참조 'API 는 일반적으로 변경 가능성 많은 시간을 보냈기 때문에 내가 알지 못하는 문제에 대해 똑같이 일관된 그림이있을 수 있습니다.

시간대는 재미 있습니다. 방금 일어 났어요! 여기에는 두 가지 문제 (일반적으로 불변, 특히 dropck)가있는 것 같으므로 별도의 주석에 넣겠습니다.

@RalfJung : 예, 이것은 안전하지 않은 Rust에 의해 유지되는 불변성에 관한 문제입니다. Rust + std의 모든 버전에 대해 신뢰 보장 추론을 사용하여 유지되는 불변 I 중 하나 이상을 선택할 수 있습니다. 그리고 실제로 L1 및 L2 두 개의 라이브러리가있을 수 있습니다.이 라이브러리는 호환되지 않는 I1 및 I2 하여 Rust + L1 가 안전하고 Rust + L2 는 안전하지만 Rust + L1 + L2 은 안전하지 않습니다.

이 경우 L1 는 ManuallyDrop 이고 L2 는 Josephine 이며 ManuallyDrop 는 지금부터 이길 것임이 분명합니다. std 에서는 Josephine보다 이전 버전과의 호환성 제약이 훨씬 더 강합니다.

흥미롭게도 https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html 의 지침은 "안전하지 않은 코드를 작성할 때 안전한 코드를 허용 할 수없는 것은 프로그래머의 책임입니다. ... "즉, 컨텍스트 속성 (모든 안전한 컨텍스트 C에 대해 C [P]는 잘못 될 수 없음)이므로 버전에 따라 다릅니다 (Rust + std의 v1.20이 더 안전하므로 v1.18보다 컨텍스트). 특히, 안전한 컨텍스트가 없었기 때문에 1.20 이전에는 고정이 Rust에 대한이 제약 조건을 실제로 만족했다고 주장합니다. C st C [Pinning]이 잘못되었습니다.

그러나 이것은 막 사실 변호사 일뿐입니다. 모든 사람들 이이 상황 별 정의에 문제가 있다는 데 동의한다고 생각하므로 안전하지 않은 코드 지침에 대한 모든 논의가 있습니다.

다른 것이 없다면, 고정은 우연한 불변성이 잘못되는 흥미로운 예를 보여 주었다고 생각합니다.

태그가 지정되지 않은 유니온 (및 따라서 ManuallyDrop )이 수행 한 특정 작업은 드롭 검사기와의 상호 작용이었습니다. 특히 ManualDrop 는 defn처럼 작동합니다.

unsafe impl<#[may_dangle] T> Drop for ManuallyDrop<T> { ... }

그런 다음 이것이 허용되는지 여부에 대해 대화 할 수 있습니다. :) 실제로이 대화는 https://github.com/rust-lang/rust/issues/ 에서 시작하는 may_dangle 스레드에서 진행 됩니다. 34761 # issuecomment -362375924

@RalfJung 코드는 data 의 런타임 유형이 T 이지만 컴파일 타임 유형은 [u8; N] 인 흥미로운 코너 케이스를 보여줍니다. may_dangle 에 관한 한 어떤 유형이 중요합니까?

흥미롭게도 https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html 의 지침은 "안전하지 않은 코드를 작성할 때 안전한 코드를 허용 할 수없는 것은 프로그래머의 책임입니다. 다음과 같은 행동을 나타냅니다. ... "즉, 컨텍스트 속성입니다.

아, 흥미 롭군요. 나는 이것이 분명히 충분하지 않다는 데 동의합니다-이것은 원래 범위가 지정된 스레드를 소리로 만들 것입니다. 의미를 갖기 위해서는 (적어도) 안전 코드가 호출 할 수있는 안전하지 않은 코드 집합을 지정해야합니다.

개인적으로 이것을 지정하는 더 좋은 방법은 유지 될 불변성을 제공하는 것입니다. 그러나 나는 Rust에 대해 증명하기 위해 사용하는 방법론이 그러한 불변성을 요구하기 때문에 여기에서 분명히 편향되어 있습니다. ;)

페이지에 예비적인 면책 조항이 포함되어 있지 않다는 사실에 조금 놀랐습니다. 우리는이 논의가 보여 주듯이, 한계가 정확히 무엇인지 아직 확실하지 않습니다. 적어도 그 문서가 말하는 것을하기 위해서는 안전하지 않은 코드가 필요하지만 아마도 더 많은 것이 필요할 것입니다.

예를 들어 정의되지 않은 동작의 한계와 안전하지 않은 코드가 수행 할 수있는 작업은 동일 하지 않습니다 . 해당 주제에 대한 최근 토론은 https://github.com/nikomatsakis/rust-memory-model/issues/44 를 참조 &mut T 대해 mem::size_of::<T>() == 0 &mut T 를 복제해도 정의되지 않은 동작이 발생하지 않습니다. 직접적이지만 안전하지 않은 코드가 수행하는 것은 분명히 불법으로 간주됩니다. 그 이유는 다른 안전하지 않은 코드가 소유권 규율에 의존 할 수 있으며 복제하는 것은 해당 규율을 위반하기 때문입니다.

다른 것이 없다면, 고정은 우연한 불변성이 잘못되는 흥미로운 예를 보여 주었다고 생각합니다.

아, 확실히. 그리고 앞으로 이것을 피하기 위해 무엇을 할 수 있을지 궁금합니다. https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html에 "불변이 rustc + libstd에 고정되어 있다고해서 안전하지 않은 코드가 가능하다는 것을 의미하지는 않습니다. 여기에 의지 할 수있는 몇 가지 불변성이 있습니다. "?

@RalfJung 그렇습니다. 저는 누구도 "정확성"이라는 맥락 적 정의를 좋아하지 않는다고 생각합니다. 주로 맥락의 관찰력이 약하기 때문입니다. 나는 불변성 측면에서 의미 론적 defn으로 훨씬 더 행복 할 것입니다.

내가 요구하는 유일한 것은 우리 자신에게 약간의 흔들림을 줄 수 있고 신뢰 보장 추론을 위해 두 개의 불변성을 정의 할 수 있다는 것입니다 (코드는 R에 의존 할 수 있고 G를 보장해야하며, 여기서 G는 R을 의미합니다). 그렇게하면 R을 강화하고 G를 약화시킬 여지가 있습니다. 하나의 불변 (즉, R = G) 만 있으면 변경할 수 없습니다!

상수 검사는 현재 특수한 경우 통합 필드가 아닙니다. (cc @solson @ oli-obk)

union Transmute<T, U> { from: T, to: U }

const SILLY: () = unsafe {
    (Transmute::<usize, Box<String>> { from: 1 }.to, ()).1
};

fn main() {
    SILLY
}

위 코드는 miri 평가 오류 "calling non-const fn std::ptr::drop_in_place::<(std::boxed::Box<std::string::String>, ())> - shim(Some((std::boxed::Box<std::string::String>, ()))) "를 생성합니다.

.to 유형을 const 검사기가 관찰하도록 강제로 변경합니다.

const fn id<T>(x: T) -> T { x }

const SILLY: () = unsafe {
    (id(Transmute::<usize, Box<String>> { from: 1 }.to), ()).1
};

결과는 "컴파일 타임에 소멸자를 평가할 수 없음"입니다.

관련 구현 코드는 다음과 같습니다 (특히 restrict 호출).
https://github.com/rust-lang/rust/blob/5e4603f99066eaf2c1cf19ac3afbac9057b1e177/src/librustc_mir/transform/qualify_consts.rs#L557

# 41073에 대한 더 나은 분석을 통해 공용체의 하위 필드에 할당 할 때 소멸자가 실행될 때의 의미 체계가 안정화를위한 준비가 불충분하다는 사실이 밝혀졌습니다. 자세한 내용은 해당 문제를 참조하십시오.

공용체에서 Drop 유형을 완전히 배제하고 ManuallyDrop (lang-item으로) 별도로 구현하는 것이 현실적입니까? 내가 알 수 있듯이, ManuallyDrop 는 노동 조합에서 Drop 에 대한 가장 큰 동기 인 것 같지만, 매우 특별한 경우입니다.

긍정적 인 "no drop"특성이 없으면 모든 필드가 Copy 이거나 ManuallyDrop<T> 형식이면 공용체가 잘 구성되었다고 말할 수 있습니다. 이는 유니온 필드를 할당 할 때 (가능한 모든 솔루션이 놀라운 풋 건으로 가득 찬 것처럼 보이는) 드롭과 관련된 모든 합병증을 완전히 회피 할 것이며, ManuallyDrop 는 프로그래머가 Drop 를 처리해야하는 명확한 마커입니다. Drop 구현하지 않습니다"라고 긍정적 인 방식으로 말하는 것이 좋습니다. 더 좋아.)

첫 번째 게시물의 체크리스트에는 크기가 지정되지 않은 공용체 나 RFC가 언급되어 있지 않지만 여전히 단일 변형 공용체로 제한 되는 구현이 있습니다. 이것은 레이아웃 최적화와의 상호 작용과 밀접한 관련이 있습니다. 왜냐하면 단일 변형 결합이 어떤 의미에서 "유효"해야한다는 것을 전제하기 때문입니다 (얇은 포인터 DST가 그림에 들어가면) (삭제 될 수는 있지만 그럴 수는 없습니다). 모든 홀수 비트 패턴).

이것은 "확장 점"인 C에서 유니온이 때때로 사용되는 방식과 충돌합니다 (IIRC @joshtriplett 이이 모든 것을 언급 한 것입니다). 헤더 파일은 유니온에 대해 3 개의 변형을 선언 할 수 있지만 이것은 나중에 더 많은 변형을 추가하는 것과 호환되는 것으로 간주됩니다 (유합의 크기를 늘리지 않는 한). 라이브러리 사용자는 태그 (다른 곳에 위치)가 현재 변형을 알지 못한다고 표시하는 경우 통합 데이터를 건드리지 않겠다고 약속합니다. 당신은 단지 하나의 변형을 알고있는 경우에 결정적으로, 그 단 하나의 변종이 있다는 것을 의미하지 않는다!

수표는 더 스마트 할 수 있습니다. 예를 들어 제품 유형과 동일한 상자에 선언 된 명목 유형을 통해 이동할 수 있습니다.

이 술어는 이미 존재하지만 바인딩 할 특성이 없기 때문에 제네릭에서 보수적입니다.
std::mem::needs_drop ( rustc 구현하는 내장 함수를 사용함)을 통해 액세스 할 수 있습니다.

@eddyb합니다 needs_drop 자신의 유형을 구현하는 경우 계정으로 상위 호환성을하거나 즐겁게 기타로 모양을 결정하기 위해 만들어 Drop ? 여기서의 목표는 semver 호환 변경에서 절대 깨지지 않는 검사를하는 것입니다. 예를 들어 유형 또는 수명 매개 변수가없는 구조체에 impl Drop 를 추가하고 전용 필드 만 semver 호환 가능합니다.

뿡뿡

이것은 "확장 점"인 C에서 유니온이 때때로 사용되는 방식과 충돌합니다 (IIRC @joshtriplett 이이 모든 것을 언급 한 것입니다). 헤더 파일은 유니온에 대해 3 개의 변형을 선언 할 수 있지만 이것은 나중에 더 많은 변형을 추가하는 것과 호환되는 것으로 간주됩니다 (유합의 크기를 늘리지 않는 한). 라이브러리 사용자는 태그 (다른 곳에 위치)가 현재 변형을 알지 못한다고 표시하는 경우 통합 데이터를 건드리지 않겠다고 약속합니다. 결정적으로, 하나의 변형 만 알고 있다고해서 변형이 하나만 있다는 의미는 아닙니다!

그것은 매우 특정한 경우입니다.
C 헤더에서 생성 된 C 스타일 공용체에만 영향을 미칩니다 (소멸자가없고 모든 것이 Copy , 정확히 안정에서 사용할 수있는 하위 집합).
_dummy: () 또는 _future: () 필드를 이러한 공용체에 쉽게 추가 할 수 있으며 기본적으로 더 안전한 "enum"모델의 이점을 계속 누릴 수 있습니다. "확장 지점"인 FFI 유니온은 어쨌든 잘 문서화되어야하는 것입니다.

2018 년 4 월 17 일 오전 10:08:54 PDT에 Vadim Petrochenkov [email protected] 은 다음과 같이 썼습니다.

_dummy: () 또는 _future: () 필드를 이러한 공용체에 쉽게 추가 할 수 있습니다.
기본적으로 더 안전한 "열거 형"모델의 혜택을 계속 누리십시오.

나는 사람들이 우리가 판별자를 알지 못하는 열거 형처럼 조합을 취급하는 것에 대해 이야기하는 것을 보았지만, 내가 아는 한 실제 모델이나 그러한 취급에 대해 알지 못합니다. 원래 논의에서 비 FFI 통합조차도 비 FFI 통합을 원하는 동기 부여 사용 사례를 포함하여 "한 번에 유효한 여러 변형"모델을 원했습니다.

추가 () 조합으로 변형하는 것은 아무 것도 변경하지 않아야하고, 노동 조합은 그들이 기대하는 의미를 얻기 위해 그렇게하도록 요구해서는 안된다. 유니온은 안전하지 않은 코드가 접근 할 때까지 러스트가 어떤 것을 포함 할 수 있는지 전혀 알지 못하는 상태에서 계속해서 비트 가방이어야합니다.

FFI 연합
"확장 점"이되는 것은 잘 문서화되어야하는 것입니다.
어쨌든.

의미론을 가능한 한 정확하게 문서화해야합니다.

@RalfJung 아니요, auto trait 처럼 작동하여 모든 내부 세부 정보를 노출합니다.

현재 https://github.com/rust-lang/rust/issues/41073#issuecomment -380291471에서 "활성 필드"와 공용체에 대한 논의가 있습니다.

유니온은 안전하지 않은 코드가 접근 할 때까지 러스트가 어떤 것을 포함 할 수 있는지 전혀 알지 못하는 상태에서 계속해서 비트 가방이어야합니다.

이것이 바로 제가 노조가 작동하기를 기대하는 방식입니다. 추가 성능을 짜내고 소멸자와 같은 것이없는 C 코드와 상호 작용하는 고급 기능입니다.

나를 위해, 만약 당신이 유니온의 내용을 삭제하고 싶다면, ~해야합니다. drop ~은 드롭이 필요한 필드에 포인터를 가져 와서 std::ptr::drop_in_place 를 사용하거나 필드 구문을 사용하여 값을 추출하고 싶습니다.

노조에 대해 아무것도 몰랐다면 노조가 일하기를 기대할 수 있습니다.

예- mem::uninitialized 를 공용체로 표시

pub union MaybeValid<T> {
    valid: T,
    invalid: ()
}

impl<T> MaybeValid<T> {
    #[inline] // this should optimize to a no-op
    pub fn from_valid(valid: T) -> MaybeValid<T> {
        MaybeValid { valid }
    }

    pub fn invalid() -> MaybeValid<T> {
        MaybeValid { invalid: () }
    }

   pub fn zeroed() -> MaybeValid<T> {
        // do whatever is necessary here...
        unimplemented!()
    }
}

fn example() {
    let valid_data = MaybeValid::from_valid(1_u8);
    // Destructor of a union always does nothing, but that's OK since our 
    // data type owns nothing.
    drop(valid_data);
    let invalid_data = MaybeValid::invalid();
    // Destructor of a union again does nothing, which means it needs to know 
    // nothing about its surroundings, and can't accidentally try to free unused memory.
    drop(invalid_data);
    let valid_data = MaybeValid::from_valid(String::from("test string"));
    // Now if we dropped `valid_data` we would leak memory, since the string 
    // would never get freed. This is already possible in safe rust using e.g. `Rc`. 
    // `union` is a similarly advanced feature to `Rc` and so new users are 
    // protected by the order in which concepts are introduced to them. This is 
    // still "safe" even though it leaks because it cannot trigger UB.
    //drop(valid_data)
    // Since we know that our union is of a particular form, we can safely 
    // move the value out, in order to run the destructor. I would expect this 
    // to fail if the drop method had run, even though the drop method does 
    // nothing, because that's the way stuff works in rust - once it's dropped
    // you can't use it.
    let _string_to_drop = unsafe { valid_data.valid };
    // No memory leak and all unsafety is encapsulated.
}

나는 이것을 게시하고 편집하여 내 작업을 잃지 않도록 할 것입니다.
필드를 삭제하는 @SimonSapin 방법을 편집

공용체의 내용을 삭제하려면, 삭제하려는 유형으로 캐스팅 / 변환해야합니다 (다른 변형의 끝에 사용되지 않은 비트가 더 클 수 있기 때문에 변환 할 수 없을 수도 있음). 또는 필드 구문을 사용하여 값을 추출하십시오.

(만약 놓아두기 만하면 값을 이동하는 의미에서 추출 할 필요가없는 경우 필드 중 하나에 포인터를 가져 가서 std::ptr::drop_in_place 있습니다.)

관련 : 상수의 경우 현재 상수 내부의 적어도 하나의 유니온 필드가 정확해야한다고 주장하고 있습니다 : https://github.com/rust-lang/rust/pull/51361 (ZST 필드가있는 경우 항상 사실)

나는 이것을 게시하고 편집하여 내 작업을 잃지 않도록 할 것입니다.

편집 내용은 이메일 알림에 반영되지 않습니다. 댓글을 크게 변경하려면 대신 또는 추가로 새 댓글을 작성하는 것이 좋습니다.

@derekdreery (및 다른 모든 사람) https://internals.rust-lang.org/t/pre-rfc-unions-drop-types-and-manuallydrop/8025에 대한 귀하의 의견에 관심이 있습니다.

관련 : 상수의 경우 현재 상수 내부의 적어도 하나의 유니온 필드가 정확해야한다고 주장하고 있습니다. # 51361

나는 구현을 보았지만 논쟁을 보지 못했습니다. ;)

글쎄요 .. "전혀 확인하지 않는 게 이상해 보 였어요."

나는 const 검사기에서 우리가 생각 해낸 어떤 계획이든 기꺼이 구현할 것이지만, 내 직감은 항상 하나의 조합의 변형이 완전히 정확해야한다는 것이었다.

그렇지 않으면 공용체는 특정 크기와 정렬을 사용하여 유형을 지정하는 예쁜 방법 일 뿐이며 컴파일러는 고정 된 유형 세트 간 변환을위한 편의를 생성합니다.

나는 노조가 그들에 접근하는 편리한 방법을 가진 "해석되지 않은 비트의 가방"이라고 생각한다. 나는 그들을 확인하지 않는 것에 대해 전혀 이상한 것을 보지 못합니다.

AFAIK 실제로 베를린 전체에서 언급 한 @joshtriplett 사용 사례가 있습니다. 여기서 노조의 전반부는 한 필드와 일치하고 후반부는 다른 필드와 일치합니다.

나는 노조가 그들에 접근하는 편리한 방법을 가진 "해석되지 않은 비트의 가방"이라고 생각한다. 나는 그들을 확인하지 않는 것에 대해 전혀 이상한 것을 보지 못합니다.

나는 항상이 해석이 언어의 정신에 다소 위배되지만.
다른 곳에서는 정적 분석을 사용하여 풋건을 방지하고 초기화되지 않았거나 빌린 값에 액세스하지 않는지 확인하지만 갑자기 분석이 비활성화 된 조합의 경우 촬영하십시오.

나는 정확히 union 의 목적을 봅니다. 모든 분석이 비활성화 된 원시 포인터도 있습니다. 유니온은 원시 포인터가 메모리 액세스에 대한 완전한 제어를 제공하는 것처럼 데이터 레이아웃에 대한 완전한 제어를 제공합니다. 둘 다 안전을 희생합니다.

또한 이것은 union 간단하게 만듭니다. 단순함이 중요하고 안전하지 않은 코드가 관련 될 때 더욱 중요하다고 생각합니다 (항상 공용체의 경우). 여기에서 가시적 인 이점을 제공하는 경우에만 추가 복잡성을 받아 들여야합니다.

bag-of-bits 모델은 unknown-variant가있는 열거 형 모델에 비해 새로운 기회를 제공하지 않기 때문에 유니온에 대한 비용을 지불 할 필요가 없다고 생각합니다.

여기서 문제가되는 재산은 최소한 안전 장치 인만큼 안전하지 않은 코드가 유지 해야하는 부담 이됩니다. 안전하지 않은 유형 punning <sup>1에</sup> 공용체를 사용하기를 원하기 때문에이 속성을 깨뜨릴 수있는 모든 실수를 방지 할 수있는 정적 분석이 없습니다. 따라서 "enum with unknown variant"는 실제로 코드 처리 공용체가 코드를 작성하는 방법에 매우주의해야 함을 의미합니다. 노동 조합 또는 위험 인스턴트 UB는 정말 이미 읽기 때문에, 노조에서 읽기에 관련된 unsafety 감소없이 비트가 변형 당신에게있는 거 읽기에 유효한지 (컴파일러가 이해하지 못하는 채널을 통해) 알고 필요합니다. 우리는 실제로 런타임에 발생하는 대부분의 경우가 아니라 miri에서 실행될 때 변형에 유효하지 않은 공용체에 대해 사용자

<sup>1</sup> 예를 들어, 튜플이 단순성을 위해 repr (C)라고 가정하면 union Foo { a: (bool, u8), b: (u8, bool) } 사용하면 필드 할당만으로 잘못된 것을 생성 할 수 있습니다.

뿡뿡

union Foo {a : (bool, u8), b : (u8, bool)}

이봐, 그게 내 예입니다 :)
그리고 이것은 RFC 1897의 모델에서 유효합니다 ( "리프"조각 bool -1, u8 -1, u8 -2, bool -2는 부분 할당 후에 유효합니다).

코드 핸들링 유니온은 유니온에 쓰는 방법에 매우 조심해야합니다.

즉 RFC 1897의 모델의 요점 (할당 또는 부분 할당 등) 안전한 작업이 모든 시간 슈퍼주의 할 필요가 없습니다, 유효하지 않은 상태로 조합을 켤 수 및 인스턴트 UB을하지 않는 정적 검사 보장하지만 .
와일드 포인터를 통한 쓰기와 같이 통합과 관련이없는 안전하지 않은 작업 만 통합을 무효화 할 수 있습니다.

반면에 이동 확인 없이 유니온은 매우 쉽게 무효 상태가 될 수 있습니다.

let u: Union;
let x = u.field; // UB

이것이 RFC 1897 모델의 요점입니다. 정적 검사는 안전한 작업 (예 : 할당 또는 부분 할당)이 공용체를 유효하지 않은 상태로 만들 수 없도록 보장하므로 항상 매우 조심할 필요가 없으며 즉각적인 UB를 얻지 못합니다. .
와일드 포인터를 통한 쓰기와 같이 통합과 관련이없는 안전하지 않은 작업 만 통합을 무효화 할 수 있습니다.

어떤 종류의 쓰기는 공용체에 부과 된 추가 불변을 위반하지 않는 것으로 자동으로 인식 할 수 있지만 여전히 작성자가 유지해야하는 추가 불변입니다. 읽기는 여전히 안전하지 않으며 읽은 변형에 대해 비트가 유효한지 수동으로 확인해야하기 때문에 실제로 읽는 사람에게는 도움이되지 않고 작성자의 삶을 더 어렵게 만듭니다. "Bag of bits"나 "enum with unknown variant"는 공용체의 어려운 문제를 해결하는 데 도움이되지 않습니다. 실제로 읽고 자하는 종류의 데이터를 저장하는 방법입니다.

더 멋진 유형 검사가 Dropping에 어떤 영향을 미칠까요? 만약 당신이 합집합을 만들면 그것을 C에게 넘겨 주면 소유권을 가지게됩니다. 녹이 슬어 데이터를 풀어 주려고 할 것입니다. 아니면 항상 Drop 직접 구현 하시겠습니까?

조합이 "컴파일 시간에 정적으로 변형이 확인되는 열거 형"과 같으면 편집 하는 것이 좋습니다. 제안을 이해했다면

편집 2 는 유니온이 비트 가방으로 시작한 다음 나중에 이전 버전과 호환되는 동안 안전한 액세스를 허용 할 수 있습니까?

그리고 이것은 RFC 1897의 모델 하에서 유효합니다 (부분 할당 후에 "리프"조각 bool-1, u8-1, u8-2, bool-2 중 하나 이상이 유효합니다).

와 - 우리가이 유효 할 결정하는 경우에, 나는 @가 OLI-OBK 미리 수표를 업데이트해야이 반영 생각 https://github.com/rust-lang/rust/pull/51361이 합병이 거부 될 것이다 miri.

@petrochenkov 내가 이해하지 못하는 부분은 이것이 우리를 사는 것입니다. 구현 (정적 분석) 및 사용 측면에서 추가 복잡성이 발생합니다 (사용자는 여전히 정확한 규칙을 알고 있어야합니다). 이러한 추가 복잡성은 공용체를 사용할 때 이미 안전하지 않은 컨텍스트에 있으므로 자연스럽게 더 복잡하다는 사실을 더합니다. 이 추가 복잡성이 그만한 가치가있는 이유에 대한 명확한 동기가 있어야한다고 생각합니다. 나는 "어느 정도 언어 정신에 어긋난다"는 것이 분명한 동기라고 생각하지 않습니다.

제가 생각할 수있는 한 가지는 레이아웃 최적화입니다. "비트 가방"모델에서 노조에는 틈새가 없습니다. 그러나 프로그래머에게 틈새 시장에 대한 더 많은 수동 제어를 제공함으로써 더 나은 주소라고 생각합니다. 이는 다른 경우에도 유용 할 것입니다.

나는 여기서 근본적인 것을 놓치고 있다고 생각합니다. @rkruppe에 동의합니다.
노조의 어려운 문제는 노조가 현재
프로그램이 읽고 자하는 데이터.

그러나 AFAIK이 문제는 정적 분석으로 "로컬"로 해결할 수 없습니다. 우리
적어도 전체 프로그램 분석을 마칠 것입니다. 그래도 여전히
해결하기 어려운 문제입니다.

그래서 ...이 문제에 대한 해결책이 테이블에 있습니까? 또는 무엇을
제안 된 정확한 솔루션이 실제로 우리를 사나요? C에서 노조를받는다고 가정 해 보겠습니다.
Rust 및 C 프로그램 전체를 분석하지 않고
정적 분석은 실제로 독자를 보장합니까?

@gnzlbg 우리가 얻을 수있는 유일한 보장은 @petrochenkov 가 위에 쓴 것입니다.

정적 검사는 안전한 작업 (예 : 할당 또는 부분 할당)이 공용체를 유효하지 않은 상태로 만들 수 없도록합니다.

반면에 이동 확인없이 유니온은 매우 쉽게 무효 상태가 될 수 있습니다.

당신의 제안은 나쁜 읽기로부터도 보호하지 않습니다. 나는 그것이 가능하다고 생각하지 않습니다.

또한 "모든 필드에 쓰기는 유니온을 초기화한다"라는 줄을 따라 아주 기본적인 "초기화"추적을 상상했습니다. impl Drop for MyUnion 가 허용되면 어쨌든 뭔가가 필요합니다. 좋든 나쁘 든, 우리는 언제 어디서 자동으로 분리 호출을 삽입할지 결정해야합니다. 이 규칙은 기존의 미묘한 안전하지 않은 코드에 삽입하는 추가 코드이기 때문에 가능한 한 간단해야합니다. Drop 구현하는 공용체의 경우 데이터 구조가 이미 초기화되지 않은 경우 필드에 쓰기를 허용하지 않는 struct 과 유사한 제한을 상상했습니다.

뿡 빵뀨

유니온이 비트 가방으로 시작한 다음 나중에 이전 버전과 호환되는 동안 안전한 액세스를 허용 할 수 있습니까?
아니요. 일단 우리가 비트 가방이라고 말하면 허용된다고 가정하는 안전하지 않은 코드가있을 수 있습니다.

유니온이 초기화되었는지 확인하기 위해 최소 이동 확인에 가치가 있다고 생각합니다. 원래 RFC는 초기화하거나 공용체 필드에 할당하면 전체 공용체가 초기화되도록 명시 적으로 지정했습니다. 그 외에도 rustc는 사용자가 명시 적으로 지정하지 않은 공용체의 값에 대해 어떤 것도 추론해서는 안됩니다. 노조는 모든 필드에 유효하지 않은 값을 포함한 모든에서 모든 값을 포함 할 수 있습니다.

예를 들어 한 가지 사용 사례는 향후 더 많은 태그로 명시 적으로 확장 할 수있는 C 스타일 태그 결합을 고려하는 것입니다. 해당 유니온을 읽는 C 및 Rust 코드는 가능한 모든 필드 유형을 알고 있다고 가정해서는 안됩니다.

뿡뿡

다른 방향에서 시작해야 할 것 같습니다.

이 코드는 1) 노조 2) 비 노조에 대해 작동합니까?

let x: T;
let y = x.field;

저에게 대답은 두 경우 모두 명백한 "아니오"입니다. 왜냐하면 이것은 T 의 "union"-ness에 관계없이 Rust가 방지 할 수 있고 방지하고자하는 오류의 전체 클래스이기 때문입니다.

이것은 이동 검사기가 지원을 구현하는 방식에 따라 어떤 종류의 체계를 가져야 함을 의미합니다. 이동 검사기 (및 차용 검사기)가 일반적으로 필드 별 방식으로 작동한다는 점을 감안할 때 공용체에 대한 가장 간단한 계획은 "구조체 + (de) 초기화 / 빌려온 필드와 동일한 규칙도 (de) 초기화 / 빌려주는 필드 ".
이 간단한 규칙은 모든 정적 검사를 다룹니다.

그런 다음 열거 형 모델은 위에서 설명한 정적 검사 + 하나 이상의 조건의 결과입니다.
1) 초기화 검사가 활성화되고 2) 안전하지 않은 코드가 공용체에 속한 영역에 임의의 잘못된 바이트를 쓰지 않으면 공용체 "리프"필드 중 하나가 자동으로 유효합니다. 이것은 동적 체크 불가능 (최소한 1 개 이상의 필드가 있고 const-evaluator 외부의 공용체의 경우) 보장이지만 우선 코드를 읽는 사람들을 대상으로합니다.

이 사례는 @joshtriplett의 예입니다.

예를 들어 한 가지 사용 사례는 향후 더 많은 태그로 명시 적으로 확장 할 수있는 C 스타일 태그 결합을 고려하는 것입니다. 해당 유니온을 읽는 C 및 Rust 코드는 가능한 모든 필드 유형을 알고 있다고 가정해서는 안됩니다.

만약 노동 조합이 "가능한 미래 확장"에 대한 추가 필드를 명시 적으로 가지고 있다면 코드를 읽는 사람들에게 훨씬 더 명확 할 것입니다.

물론 기본 정적 초기화 검사를 유지할 수 있지만 두 번째 조건을 거부하고 임의의 유효하지 않은 데이터를 즉시 UB가 아닌 안전하지 않은 "제 3 자"수단을 통해 공용체에 쓸 수 있습니다. 그렇다면 우리는 더 이상 사람들을 대상으로 한 동적 보장을받지 못할 것입니다. 저는 그것이 순손실이라고 생각합니다.

안녕하세요.

이 코드는 1) 노조 2) 비 노조에 대해 작동합니까?

let x: T;
let y = x.field;

저에게 대답은 두 경우 모두 명백한 "아니오"입니다. 왜냐하면 이것은 T 의 "union"-ness에 관계없이 Rust가 방지 할 수 있고 방지하고자하는 오류의 전체 클래스이기 때문입니다.

동의합니다. 초기화되지 않은 값을 확인하는이 수준은 합리적이고 실행 가능합니다.

이것은 이동 검사기가 지원을 구현하는 방식에 따라 어떤 종류의 체계를 가져야 함을 의미합니다. 이동 검사기 (및 차용 검사기)가 일반적으로 필드 별 방식으로 작동한다는 점을 감안할 때 공용체에 대한 가장 간단한 계획은 "구조체 + (de) 초기화 / 빌려온 필드와 동일한 규칙도 (de) 초기화 / 빌려주는 필드 ".
이 간단한 규칙은 모든 정적 검사를 다룹니다.

구조체에 대한 규칙을 이해한다고 가정하고 지금까지 동의했습니다.

그런 다음 열거 형 모델은 위에서 설명한 정적 검사 + 하나 이상의 조건의 결과입니다.
1) 초기화 검사가 활성화되고 2) 안전하지 않은 코드가 공용체에 속한 영역에 임의의 잘못된 바이트를 쓰지 않으면 공용체 "리프"필드 중 하나가 자동으로 유효합니다. 이것은 동적 체크 불가능 (최소한 1 개 이상의 필드가 있고 const-evaluator 외부의 공용체의 경우) 보장이지만 우선 코드를 읽는 사람들을 대상으로합니다.

이 추가 조건은 공용체에 유효하지 않습니다.

이 사례는 @joshtriplett의 예입니다.

예를 들어 한 가지 사용 사례는 향후 더 많은 태그로 명시 적으로 확장 할 수있는 C 스타일 태그 결합을 고려하는 것입니다. 해당 유니온을 읽는 C 및 Rust 코드는 가능한 모든 필드 유형을 알고 있다고 가정해서는 안됩니다.

만약 노동 조합이 "가능한 미래 확장"에 대한 추가 필드를 명시 적으로 가지고 있다면 코드를 읽는 사람들에게 훨씬 더 명확 할 것입니다.

그것은 C 공용체가 작동하는 방식도 아니고 Rust 공용체가 작동하도록 지정된 방식도 아닙니다. (그리고 나는 그것이 더 명확 할 것인지 아니면 단순히 다른 기대치와 일치하는지에 대해 의문을 갖고 있습니다.) 이것을 변경하면 Rust 유니온이 더 이상 설계되고 제안 된 목적에 적합하지 않게됩니다.

물론 기본 정적 초기화 검사를 유지할 수 있지만 두 번째 조건을 거부하고 임의의 유효하지 않은 데이터를 즉시 UB가 아닌 안전하지 않은 "제 3 자"수단을 통해 공용체에 쓸 수 있습니다. 그렇다면 우리는 더 이상 사람들을 대상으로 한 동적 보장을받지 못할 것입니다. 저는 그것이 순손실이라고 생각합니다.

이러한 '안전하지 않은 "제 3 자"의미에는 "FFI에서 통합 얻기"가 포함되며 이는 완전히 유효한 사용 사례입니다.

다음은 구체적인 예입니다.

union Event {
    event_id: u32,
    event1: Event1,
    event2: Event2,
    event3: Event3,
}

struct Event1 {
    event_id: u32, // always EVENT1
    // ... more fields ...
}
// ... more event structs ...

match u.event_id {
    EVENT1 => { /* ... */ }
    EVENT2 => { /* ... */ }
    EVENT3 => { /* ... */ }
    _ => { /* unknown event */ }
}

이것은 사람들이 공용체를 사용하여 작성할 수있는 완전히 유효한 코드입니다.

안녕하세요.

이 코드는 1) 노조 2) 비 노조에 대해 작동합니까?
저에게 대답은 두 경우 모두 명백한 "아니오"입니다. 왜냐하면 이것은 T의 "결합"여부에 관계없이 Rust가 방지 할 수 있고 방지하고자하는 오류의 전체 클래스이기 때문입니다.

괜찮아요.

유니온에 대한 가장 간단한 계획은 "구조체 + (de) initialization / borrow of a field also (de) initializes / borrows its sibling fields"와 동일한 규칙입니다.)

와. 구조체 규칙 은 서로 다른 필드가 분리 되어 있다는 사실을 기반으로하기 때문에 의미

1) 초기화 검사가 활성화되고 2) 안전하지 않은 코드가 공용체에 속한 영역에 임의의 잘못된 바이트를 쓰지 않으면 공용체 "리프"필드 중 하나가 자동으로 유효합니다. 이것은 동적 체크 불가능 (최소한 1 개 이상의 필드가 있고 const-evaluator 외부의 공용체의 경우) 보장이지만 우선 코드를 읽는 사람들을 대상으로합니다.

기본 타당성 가정이 동적으로 확인 가능한 (주어진 유형 정보) 매우 바람직하다고 생각합니다. 그런 다음 miri에서 CTFE를 수행하는 동안이를 확인할 수 있으며, "전체"miri 실행 (예 : 테스트 스위트) 중에도 확인할 수 있습니다. 결국 일종의 새니 타이 저 또는 Rust가 debug_assert! 방출하는 모드를 가질 수 있습니다. 중요한 장소에서 유효성 불변을 확인합니다.
C의 체크 할 수없는 규칙에 대한 경험은 이것이 문제가 있다는 충분한 증거를 제공한다고 생각합니다. 일반적으로 규칙이 무엇인지 실제로 이해하고 명확히하는 첫 번째 단계는 동적으로 확인할 수있는 방법을 찾는 것입니다. 동시성 메모리 모델의 경우에도 "동적으로 확인할 수있는"변형 (가상 머신의 단계별 실행 측면에서 모든 것을 설명하는 운영 의미론)이 나타나고 있으며 공리적 문제를 해결하는 유일한 방법 인 것 같습니다. 이전에 사용 된 모델 ( "ouf of thin air problem"이 여기서 키워드 임).

동적으로 확인 가능한 규칙을 갖는 것이 얼마나 중요하다고 생각하는지 과장 할 수 없습니다. 체크 할 수없는 UB 사례 0 개를 목표로해야한다고 생각합니다. (우리는 아직 거기에 있지 않지만, 우리가 가져야 할 목표입니다.) 그것이 당신의 언어로 UB를 가질 수있는 유일한 책임감있는 방법입니다. 다른 모든 것은 컴파일러 / 언어 작성자가 다음과 같은 모든 사람을 희생하여 삶을 편하게 만드는 경우입니다. 결과와 함께 살아야합니다. (현재 앨리어싱 및 원시 포인터 액세스에 대해 동적으로 확인 가능한 규칙을 작업 중입니다.)
이것이 유일한 문제 일지라도, "동적으로 검사 할 수없는"것은이 접근법을 사용하지 않을 충분한 근거입니다.

즉, 이것이 체크 할 수 없어야하는 근본적인 이유는 없습니다. 통합의 모든 바이트에 대해 모든 변형을 검토하여이 변형의 해당 바이트에 허용되는 값을 확인하고 모두의 결합 (heh;))을 가져옵니다. 그 세트의. 이 정의에 따라 모든 바이트가 유효한 경우 바이트 시퀀스가 ​​유니온에 유효합니다.
그러나 이것은 실제로 우리가 Rust에서 가질 수있는 가장 복잡한 기본 유형 유효성 불변성 검사를 구현하기는 매우 어렵습니다. 이것은이 타당성 규칙이 설명하기 다소 까다 롭다는 사실의 직접적인 결과이며, 이것이 제가 그것을 좋아하지 않는 이유입니다.

물론 기본 정적 초기화 검사를 유지할 수 있지만 두 번째 조건을 거부하고 임의의 유효하지 않은 데이터를 즉시 UB가 아닌 안전하지 않은 "제 3 자"수단을 통해 공용체에 쓸 수 있습니다. 그렇다면 우리는 더 이상 사람들을 대상으로 한 동적 보장을받지 못할 것입니다. 저는 그것이 순손실이라고 생각합니다.

그 보증 은 우리에게 무엇을 사나요? 실제로 어디에서 도움이됩니까? 지금 내가 보는 것은 모두가 열심히 일하고 그것을 지키기 위해 조심해야한다는 것입니다. 저는 우리 국민이 그로부터 얻는 혜택을 보지 못합니다.

안녕하세요.

앞으로 더 많은 태그로 명시 적으로 확장 할 수있는 C 스타일 태그 결합을 고려하십시오. 해당 유니온을 읽는 C 및 Rust 코드는 가능한 모든 필드 유형을 알고 있다고 가정해서는 안됩니다.

@petrochenkov가 제안한 모델은 __non_exhaustive: () 필드를 유니온에 추가하여 이러한 사용 사례를 허용합니다. 그러나 나는 그것이 필요하다고 생각하지 않습니다. 아마도 바인딩 생성기는 이러한 필드를 추가 할 수 있습니다.

뿡뿡

이것은 동적으로 확인할 수 없습니다 (최소한> 1 필드가 있고 const-evaluator 외부에있는 공용체의 경우) 보장

기본 타당성 가정을 동적으로 확인할 수있는 것이 매우 바람직하다고 생각합니다.

설명 : "기본적으로"/ "릴리스 모드에서"체크 할 수 없음을 의미했습니다. 물론 "저속 모드"에서 몇 가지 추가 도구를 사용하여 체크 할 수 있지만 이미이 문제에 대해 제가 할 수있는 것보다 더 잘 작성했습니다.

뿡뿡

@petrochenkov가 제안한 모델은 __non_exhaustive : () 필드를 유니온에 추가하여 이러한 사용

예, 그것이 제안이라는 것을 이해했습니다.

그러나 나는 그것이 필요하다고 생각하지 않습니다. 아마도 바인딩 생성기는 이러한 필드를 추가 할 수 있습니다.

그들은 할 수 있지만 모든 단일 조합에 체계적으로 추가해야합니다.

아직까지 포함 할 수있는 비트 패턴을 제한하는 데 의존하는 일부 지정되지 않은 사용 사례를 선호하여 통합의 기본 사용 사례를 깨는 것이 합당한 이유에 대한 논의를 아직 보지 못했습니다.

안녕하세요.

공용체의 주요 사용 사례

이것이 주요 사용 사례 인 이유가 전혀 분명하지 않습니다.
FFI에서 태그가 지정된 공용체 / "Rust enum emulation"에 대한 공용체의 모든 사용이 확장 성을 가정한다고 가정하면 repr(C) 공용체에 대해 참일 수 있지만, 제가 본 것에서 repr(Rust) 공용체 (드롭 제어, 초기화 제어, 변환)는 갑자기 "예기치 않은 변형"이 나타날 것으로 예상하지 않습니다.

@petrochenkov 나는, 나는 "차 사용 사례를 휴식"며 "기본 유스 케이스 휴식"말을하지 않았다. FFI는 공용체의 주요 사용 사례 중 하나 입니다.

그리고 그 모든 세트의 합집합 (heh;))을 취하십시오.

"유니온의 가능한 값은 가능한 모든 변형의 가능한 값의 합집합입니다"라는 진술에는 확실히 매력적인 명백 함이 있습니다.

진실. 그러나 그것은 제안이 아닙니다. 우리 모두는 다음이 합법적이어야한다는 데 동의합니다.

union F {
  x: (u8, bool),
  y: (bool, u8),
}
fn foo() -> F {
  let mut f = F { x: (5, false) };
  unsafe { f.y.1 = 17; }
  f
}

사실 이것은 unsafe 조차 필요로하는 버그라고 생각합니다.

따라서 합집합은 적어도 바이트 단위로 취해야합니다.
또한 "매력적인 뻔함"자체가 충분한 이유라고 생각하지 않습니다. 우리가 결정하는 모든 불변성은 안전하지 않은 코드 작성자에게 큰 부담이며, 우리는 차례로 얻을 수있는 구체적인 이점을 가져야합니다.

뿡뿡

사실 이것이 안전하지도 않은 버그라고 생각합니다.

새로운 MIR 기반의 안전하지 않은 검사기 구현에 대해서는 모르겠지만 이전 HIR 기반에서는 확실히 검사기 제한 / 단순화였습니다. expr1.field = expr2 형식의 식만 가능한 "필드"로 분석되었습니다. 할당 "안전하지 않은 옵트 아웃, 다른 모든 것은 노조에 안전하지 않은 일반적인"현장 접근 "으로 보수적으로 취급되었습니다.

https://github.com/rust-lang/rust/issues/52786#issuecomment -408645420의 댓글에 답변 :

따라서 컴파일러는 여전히 Wrap<T> 의 계약에 대해 아무것도 알지 못하며 예를 들어 레이아웃 최적화를 수행 할 수 없습니다. 좋아,이 입장은 이해된다.
내부적으로, 내부에이 방법 Wrap 의의 모듈 구현 Wrap<T> 이 사용자에게 누설하지 않을 경우 모듈은, 예를 들어, 일시적으로, 그것으로 "예기치 않은 값"을 쓸 수 있습니다, 컴파일러도 괜찮을 것입니다.

예상치 못한 값의 부재에 대한 Wrap 계약의 일부가 필드 프라이버시와 얼마나 관련이 있는지 잘 모르겠습니다.

우선, 필드가 비공개인지 공개인지에 관계없이 예기치 않은 값을 해당 필드를 통해 직접 쓸 수 없습니다. 이를 수행하려면 원시 포인터 또는 FFI의 다른 쪽 코드와 같은 것이 필요하며 전체 공용체에 대한 포인터 만 있으면 필드 액세스없이 수행 할 수 있습니다. 따라서 제한되는 필드에 대한 접근이 아닌 다른 방향에서 접근해야합니다.

내가 해석 한대로 접근 방식은 private 필드 (union 또는 struct에서 중요하지 않음)가 사용자에게 알려지지 않은 임의의 불변을 암시하므로 해당 필드를 변경하는 모든 작업 (직접 또는 와일드 포인터를 통해 중요하지 않은 불변을 잠재적으로 깨뜨릴 수 있기 때문에 UB가됩니다.

즉, 공용체에 단일 개인 필드가있는 경우 해당 구현 자 (컴파일러가 아님)는 타사가 해당 공용체에 예기치 않은 값을 쓰지 않을 것이라고 가정 할 수 있습니다.
이는 어떤 의미에서 사용자를위한 "기본 통합 문서 절"입니다.
-(기본값) 공용체에 private 필드가 있으면 쓰레기를 쓸 수 없습니다 .
-그렇지 않으면, 문서가 명시 적으로 금지 하지 않는 한 쓰레기를 공용체에 쓸 수 있습니다 .

일부 유니온이 예상 필드에 대한 pub 액세스를 제공하면서 예상치 못한 값을 금지하려는 경우 (예 : 해당 필드에 자체 불변성이없는 경우) 여전히 문서를 통해이를 수행 할 수 있습니다. 두 번째 절이 필요합니다.

뿡뿡
이것이 당신의 위치를 ​​정확하게 설명합니까?

이와 같은 시나리오는 어떻게 처리됩니까?

mod m {
    union MyPrivateUnion { /* private fields */ }
    extern {
        fn my_private_ffi_function() -> MyPrivateUnion; // Can return garbage (?)
    }
}

내가 해석 한대로 접근 방식은 private 필드 (union 또는 struct에서 중요하지 않음)가 사용자에게 알려지지 않은 임의의 불변을 암시하므로 해당 필드를 변경하는 모든 작업 (직접 또는 와일드 포인터를 통해 중요하지 않은 불변을 잠재적으로 깨뜨릴 수 있기 때문에 UB가됩니다.

아니, 그건 내가 의미 한게 아니야.

불변이 여러 개 있습니다. 얼마나 많은 것이 필요할지 모르겠지만 적어도 두 개는있을 것입니다 (그리고 그들에 대한 훌륭한 이름이 없습니다).

• 유형의 "레이아웃 수준 불변"(또는 "구문 불변")은 유형의 구문 모양에 의해 완전히 정의됩니다. " &mut T is non-NULL and alignment", " bool is 0 또는 1 ", " ! 는 사용할 수 없습니다. 있다". 이 수준에서 *mut T 는 usize 와 동일합니다. 둘 다 모든 값을 허용합니다 (또는 초기화 된 값이지만 다른 논의를위한 차이 임). 결국 우리는 구조적 재귀에 의해 모든 유형에 대해 이러한 불변을 철자하는 문서를 갖게 될 것입니다. 구조체의 레이아웃 수준 불변은 모든 필드가 불변을 유지한다는 것입니다. 가시성은 여기서 역할을하지 않습니다.

Violating the layout-level invariant is instantaneous UB. This is a statement we can make because we have defined this invariant in very simple terms, and we make it part of the definition of the language itself. We can then exploit this UB (and we already do), e.g. to perform enum layout optimizations.

• 유형의 "사용자 정의 유형 수준 불변"(또는 "의미 적 불변")은 유형을 구현하는 사람이 선택합니다. 컴파일러는이를 표현할 언어가 없기 때문에이 불변성을 알 수 없으며 언어 정의도 마찬가지입니다. 우리는 그 불변이 무엇인지조차 말할 수 없기 때문에이 불변 UB를 위반할 수 없습니다! 이 사용자 정의 불변을 가지고도 가능하다는 사실은 유용한 타입 시스템의 기능입니다 : 추상화입니다. 나는 지난 블로그 포스트 에서 이것에 대해 더 많이 썼다.

  커스텀, 시맨틱 불변과 UB 사이의 연결은 안전하지 않은 코드가 외래 코드에 의해 보존되는 시맨틱 불변에 의존 할 수 있음을 선언한다는 것입니다. Vec 의 크기 필드에 임의의 항목을 넣는 것은 잘못된 것입니다. 내가 틀렸다고 말했지만 (때로는 unsound 라는 용어를 사용합니다)-정의 되지 않은 동작은 &mut ZST 대한 별칭 규칙에 대한 설명 입니다. 매달려있는 잘 정렬 된 null이 아닌 &mut ZST 만드는 것은 즉각적인 UB가 아니지만 이것이 발생하지 않는 안전하지 않은 코드를 작성할 수 있기 때문에 여전히 올바르지 않거나 불건전합니다.

이 두 개념을 맞추는 것이 좋지만 실용적이지 않다고 생각합니다. 우선, 일부 유형 (함수 포인터, dyn 특성)의 경우 사용자 정의 의미 불변의 정의는 실제로 언어에서 UB의 정의를 사용 합니다. 이 정의는 관습, 의미 론적 불변을 위반하는 것이 UB라고 말하고 싶다면 순환적일 것입니다. 둘째, 우리 언어의 정의와 특정 실행 추적이 UB를 나타내는 지 여부가 결정 가능한 속성인지 선호합니다. 의미 론적, 사용자 정의 불변성은 종종 결정할 수 없습니다.

예상치 못한 값이 없다는 랩스 계약의 일부가 필드 프라이버시와 얼마나 관련이 있는지 잘 모르겠습니다.

기본적으로 유형이 사용자 정의 불변을 선택할 때 안전한 코드가 수행 할 수있는 모든 작업이 불변을 보존 하는지 확인해야합니다. 결국, 약속은이 유형의 안전한 API를 사용하는 것만으로는 UB로 이어질 수 없다는 것입니다. 이것은 구조체와 공용체 모두에 적용됩니다. 안전한 코드가 할 수있는 일 중 하나는이 연결이 시작되는 공용 필드에 액세스하는 것입니다.

예를 들어 구조체의 공용 필드 는 필드 유형 의

공공 장소가있는 조합 ... 글쎄, 그건 다소 흥미 롭다. 어쨌든 통합 필드를 읽는 것은 안전하지 않으므로 아무것도 변경되지 않습니다. 공용 필드를 작성하는 것은 안전하므로 공용 필드가있는 공용체는 필드에 입력되는 해당 필드의 유형의 사용자 정의 불변을 충족하는 임의의 데이터를 처리 할 수 ​​있어야합니다. 이것이 매우 유용 할 것 같지 않습니다 ...

요약하자면, 사용자 지정 불변을 선택할 때 외부 안전 코드가이 불변을 깨지 않도록하는 것은 귀하의 책임입니다 (그리고이를 달성하는 데 도움이되는 개인 필드와 같은 도구가 있음). 그것은 그 코드가 어떤 안전 코드를 할 수 없었 않는 당신의 불변을 위반하지 외국 unafe 코드의 책임이다.

이것은 내부적으로, Wrap의 모듈 내부에서 Wrap의 구현을 의미합니다.예를 들어, 모듈은 "예기치 않은 값"을 사용자에게 누설하지 않으면 임시로 쓸 수 있으며 컴파일러는 괜찮습니다.

옳은. (공황 안전은 여기서 문제이지만 아마 알고있을 것입니다). 이것은 Vec 에서 안전하게 할 수있는 것과 같습니다.

let sz = self.size;
self.size = 1337;
self.size = sz;

그리고 UB가 없습니다.

mod m {
    union MyPrivateUnion { /* private fields */ }
    extern {
        fn my_private_ffi_function() -> MyPrivateUnion; // Can return garbage (?)
    }
}

구문 레이아웃 불변성 측면에서 my_private_ffi_function 는 모든 작업을 수행 할 수 있습니다 (함수 호출 ABI와 서명이 일치한다고 가정). 의미 론적 사용자 정의 불변의 관점에서, 이는 코드에서 볼 수 없습니다.이 모듈을 작성한 사람은 불변을 염두에두고 있었으므로이를 공용체 정의 옆에 문서화 한 다음 FFI 함수가 불변을 만족하는 값을 반환하는지 확인해야합니다. .

마지막으로 &mut T 초기화 여부와시기와 위에서 언급 한 두 종류의 불변성에 대한 블로그 게시물을 작성했습니다 .

아직 https://github.com/rust-lang/rust/issues/55149에 포함되지 않은 추적 할 항목이 있습니까? 아니면 닫아야합니까?

E0658은 여전히 ​​여기를 가리 킵니다.

error [E0658] : Copy 필드가 아닌 공용체가 불안정합니다 (문제 # 32836 참조).

이것은 Copy 구현하지 않기 때문에 현재 atomics에서 끔찍하게 작동합니다. 누구든지 해결 방법을 알고 있습니까?

https://github.com/rust-lang/rust/issues/55149 가 구현되면 유니온에서 ManuallyDrop<AtomicFoo> 를 사용할 수 있습니다. 그때까지 유일한 해결 방법은 Nightly를 사용하는 것입니다 (또는 union 사용하지 않고 대안을 찾음).

이를 구현하면 ManuallyDrop 도 필요하지 않습니다. 모든 rustc는 Atomic* 이 Drop 구현하지 않는다는 것을 알고 있습니다.

추적 문제를 새 문제로 전환하도록 지정합니다.