Rust 1.96.0 발표

• Rust 1.96.0은 rustup update stable로 설치할 수 있으며, 향후 릴리스 검증은 beta/nightly 채널에서 참여 가능함
• 새 core::range::Range* 타입은 Iterator 대신 IntoIterator를 구현해 Copy 구현이 가능하며, 향후 범위 문법의 기본 타입이 될 예정임
• assert_matches! 와 debug_assert_matches!는 패턴 불일치 시 값의 Debug 표현을 함께 출력해 테스트 실패 진단을 쉽게 만듦
• WebAssembly 대상은 더 이상 --allow-undefined를 기본 전달하지 않아 정의되지 않은 심볼이 import가 아니라 링커 오류가 됨
• Cargo에는 서드파티 레지스트리 사용자를 위한 CVE-2026-5223과 CVE-2026-5222 수정이 포함됐고, crates.io 사용자는 영향받지 않음

---

Rust 1.96.0 주요 변경점

• 업데이트와 테스트 채널

  • 기존 Rust를 rustup으로 설치한 사용자는 rustup update stable로 Rust 1.96.0을 받을 수 있음
  • rustup이 없으면 Rust 웹사이트의 rustup 설치 페이지에서 설치할 수 있으며, 1.96.0 상세 릴리스 노트도 공개됨
  • 향후 릴리스 검증에 참여하려면 rustup default beta 또는 rustup default nightly로 beta/nightly 채널을 사용할 수 있고, 버그는 Rust 이슈 트래커에 보고 가능함

• 새로운 Range* 타입

  • 기존 Range와 관련 core::ops 타입은 많은 사용자가 Copy를 기대하지만, 직접 Iterator를 구현하기 때문에 Copy를 함께 구현하지 않았음
  • 같은 타입에 Iterator와 Copy를 함께 구현하는 방식은 Clippy가 지적하는 footgun이어서 피하고 있었음
  • RFC3550은 Iterator 대신 IntoIterator를 구현하는 대체 범위 타입을 제안했고, 이 구조에서는 해당 타입들이 Copy도 구현할 수 있음
  • 표준 라이브러리에는 core::range::Range, core::range::RangeFrom, core::range::RangeInclusive와 관련 반복자들이 안정화됨
  • 가까운 향후 Rust 버전에는 core::ops에서 다시 내보내는 core::range::RangeFull과 core::range::RangeTo, 현재 범위 타입의 새 위치가 될 core::range::legacy::*도 추가될 예정임
  • 0..1 같은 범위 문법은 현재 레거시 타입을 만들지만, 향후 에디션에서 core::range 타입으로 바뀔 예정임
  • 새 안정화로 start와 end를 분리하지 않고도 슬라이스 접근자를 Copy 타입에 저장할 수 있음
  • 예시:

    use core::range::Range;
    
    #[derive(Clone, Copy)]
    pub struct Span(Range<usize>);
    
    impl Span {
        pub fn of(self, s: &str) -> &str {
            &s[self.0]
        }
    }
    

  • 새 RangeInclusive는 필드를 공개하며, 레거시 버전처럼 소진된 반복자 상태 노출을 피할 필요가 없음
  • 새 타입은 반복을 시작하려면 먼저 변환되어야 하므로 공개 필드가 문제가 되지 않음
  • 라이브러리 작성자는 공개 API에서 레거시와 새 범위 타입을 모두 받는 impl RangeBounds 사용을 고려해야 함
  • 구체 타입이 필요하면 향후 기본값이 될 새 범위 타입을 선호하는 것이 권장됨

• 패턴 매칭 단언 매크로

  • 새 매크로 assert_matches!와 debug_assert_matches!는 값이 주어진 패턴과 맞는지 검사하고, 맞지 않으면 해당 값의 Debug 표현과 함께 패닉함
  • 두 매크로는 본질적으로 assert!(matches!(..)), debug_assert!(matches!(..))와 같지만, 실패 시 출력되는 값 덕분에 진단 가능성이 좋아짐
  • 같은 이름의 매크로를 제공하는 인기 서드파티 크레이트와 충돌할 수 있어 표준 프렐류드에는 추가되지 않았음
  • 사용 전 core 또는 std에서 직접 가져와야 함
  • 예시:

    use core::assert_matches;
    
    /// [Random Number](https://xkcd.com/221/)
    fn get_random_number() -> u32 {
        // chosen by a fair dice roll.
        // guaranteed to be random.
        4
    }
    
    fn main() {
        assert_matches!(get_random_number(), 1..=6);
    }
    

• WebAssembly 대상 변경

  • WebAssembly 대상은 더 이상 링커에 --allow-undefined를 전달하지 않음
  • 링크 시 정의되지 않은 심볼은 "env" 모듈의 WebAssembly import로 변환되지 않고 링커 오류가 됨
  • 링크 관련 심볼이 모두 정의되지 않으면 모듈이 링크되지 않으므로, 버그를 더 일찍 잡고 심볼 이름 등에서 발생하는 우발적 문제를 막을 수 있음
  • 정의되지 않은 링크 관련 심볼은 보통 빌드 시간 버그나 설정 오류를 나타냄
  • 기존 동작이 의도된 경우 RUSTFLAGS=-Clink-arg=--allow-undefined로 되돌리거나, 소스 코드에서 심볼을 정의하는 블록에 #[link(wasm_import_module = "env")]를 사용할 수 있음
  • 이 변경은 이전 블로그 공지 이후 Rust 1.96에서 적용됨

안정화 API와 보안 수정

• 안정화된 API

  • assert_matches!
  • debug_assert_matches!
  • From<T> for AssertUnwindSafe<T>
  • From<T> for LazyCell<T, F>
  • From<T> for LazyLock<T, F>
  • core::range::RangeToInclusive
  • core::range::RangeToInclusiveIter
  • core::range::RangeFrom
  • core::range::RangeFromIter
  • core::range::Range
  • core::range::RangeIter

• Cargo 보안 권고 2건

  • Rust 1.96은 서드파티 레지스트리 사용자를 위한 Cargo 취약점 2건의 수정 사항을 포함함
  • CVE-2026-5223은 심볼릭 링크가 있는 크레이트 tarball 추출과 관련된 중간 심각도 취약점임
  • CVE-2026-5222는 정규화된 URL을 통한 인증과 관련된 낮은 심각도 취약점임
  • crates.io 사용자는 두 취약점 모두의 영향을 받지 않음

• 추가 변경 사항

  • Rust 1.96.0 변경 사항
  • Cargo 1.96 변경 사항
  • Clippy 변경 사항

[GN⁺]

Lobste.rs 의견들

• assert_matches는 계속 갖고 싶어지는데, 그때마다 새 크레이트를 추가할지 직접 다시 구현할지 고민하게 됨
  그래서 표준 라이브러리에 들어가는 건 반가움

  • 테스트에서 괄호 쌍 수백 개를 지울 수 있다는 게 기대되는 게 이상한가? 전혀 아니라고 봄

• 범위를 Copy 타입으로 만들려는 단계가 마음에 듦
  가끔 범위를 복제해야 해서 놀란 적이 있었고, 12..34는 작고 복사 가능한 데이터여야 한다는 직관에도 더 잘 맞음
  다만 같은 이름의 타입이 여러 개 생기면, VS Code가 다음에 use 선언을 자동 추가할 때 잘못된 타입을 가져올까 봐 조금 걱정됨

  A Rust version in the near future will also add [...] core::range::legacy::* as the new home for the current ranges. Range syntax like 0..1 still produces the legacy types for now, but will be updated to core::range types in a future edition.
  Rust의 에디션 시스템이 꽤 좋은 아이디어처럼 보임

  • 알기로는 가져오기에서 모호성이 생기면 VS Code의 코드 액션이 어떤 걸 쓸지 고르는 드롭다운을 열어줘야 함
  • 이런 타입을 평소에 자주 가져올 필요는 없지 않나 싶음
    대부분 사용자에게는 새 타입의 이점이 작아서 그냥 기존 타입을 계속 쓰면 되고, 다음 에디션 경계에서 새 타입이 자동으로 쓰이게 됨
    명시적으로 두 버전을 모두 지원하려는 라이브러리 작성자들이 주로 타입을 가져오게 될 것 같음

• These new macros have not been added to the standard prelude, because they would collide with popular third-party crates that provide macros with the same name. Instead, they should be manually imported from core or std before use.
  이건 좀 이상하게 느껴짐
  나중에 바꿀 계획이 있는 걸까? 생태계가 옮겨간 뒤, 예를 들어 3년쯤 지나 작은 정리로 바꾸고 싶은 종류의 일처럼 보임

  • 이런 부분에서 에디션이 도움이 됨
    기존 프로젝트를 깨지 않고도 프렐류드를 바꿀 수 있음