Skip to content

INTERNAL: Build the crate as a cdylib with project lints - #1

Merged
jhpark816 merged 1 commit into
developfrom
crate-setup
Oct 24, 2026
Merged

jhpark816 merged 1 commit into
developfrom
crate-setup

Conversation

@ing-eoking

@ing-eoking ing-eoking commented Oct 22, 2026 •

Copy link
Copy Markdown
Collaborator

🔗 Related Issue

⌨️ What I did

arcus-vector를 memcached에 -X로 붙는 확장 모듈로 빌드하기 위한 크레이트 설정입니다.
기능 코드는 없고, 이후 PR들이 따를 빌드 형태와 린트 기준만 정합니다.

변경 사항

  • Cargo.toml
    • crate-type = ["cdylib"], [lib] name = "arcusv": memcached가 적재하는 libarcusv.so를 만듭니다.
    • rust-version = "1.88": let-chains(if let .. && let ..)를 씁니다.
    • [lints]: 데몬 안에서 도는 모듈이라 패닉과 abort로 이어지는 코드를 막는 쪽으로 잡았습니다.
      • clippy::pedantic 전체를 켜고, FFI·벡터 연산의 의도된 as 캐스트 4종을 끕니다.
      • unwrap_used, expect_used, print_stderr, print_stdout를 금지합니다(테스트는 허용).
      • unsafe 블록에는 // SAFETY: 근거를 필수로 적습니다(undocumented_unsafe_blocks).
      • 린트 예외는 #[expect(.., reason = "..")]로만 둡니다(allow_attributes).
  • clippy.toml: 테스트에서만 unwrap/expect/출력을 허용합니다.
  • rustfmt.toml: 2024 스타일입니다. (가장 최신)
  • src/lib.rs: cargo init 예제 코드를 지우고 크레이트 설명만 남겼습니다.

Summary by CodeRabbit

  • 변경 사항
    • Rust 1.88 이상이 필요하도록 최소 버전이 설정되었습니다.
    • 배포 게시가 비활성화되었습니다.
    • 기존 예제 계산 기능이 제거되었습니다.
  • 개발 환경
    • Rust 2024 에디션 기준과 코드 검사·서식 규칙이 설정되었습니다.

@ing-eoking
ing-eoking requested a review from zhy2on October 22, 2026 12:46
@coderabbitai

This comment was marked as resolved.

@ing-eoking
ing-eoking requested review from namsic and zhy2on and removed request for namsic and zhy2on October 22, 2026 12:46
coderabbitai[bot]

This comment was marked as resolved.

@namsic namsic left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lints 설정하지 않아도 각 옵션마다 기본값이 있고 그에 따라 동작할 것인데, 개별 옵션을 조정하는 이유는 무엇인가요?

논리적으로 발생할 수 없는 (또는 발생하면 안 되는) 상황에서도 unwrap(panic)하지 않고 정상 동작하는 방어 코드를 넣도록 강제한다는 의미인가요?

옵션은 하나하나 필요에 따라 조정한 것인가요? 다른 곳의 프리셋을 가져온 것인가요?

@ing-eoking

ing-eoking commented Oct 22, 2026 •

Copy link
Copy Markdown
Collaborator Author

@namsic

lints 설정하지 않아도 각 옵션마다 기본값이 있고 그에 따라 동작할 것인데, 개별 옵션을 조정하는 이유는 무엇인가요?

현재 작성 중인 코드가 독립적인 프로그램이 아닌 memcached의 확장 모듈로 동작하기 때문에, 잠재적인 위험을 원천 차단하고자 Clippy 기본 그룹 대신 특화된 린트(lint) 규칙을 엄격하게 개별 적용했습니다.

  • 에러 및 예외 처리 강제 (unwrap_used, expect_used)
    • 모듈 내 런타임 패닉을 방지하기 위해 unwrap이나 expect 사용을 제한하고, None이나 Err에 대한 명시적인 에러 핸들링을 강제했습니다.
  • 표준 입출력 제한 (print_stdout, print_stderr)
    • 디버깅 및 로그 메시지가 표준 입출력으로 출력되는 것을 막고, 반드시 memcached 로거를 거쳐 출력되도록 통제했습니다.
  • unsafe 블록 검증 및 문서화 (undocumented_unsafe_blocks)
    • C 포인터를 다루는 등 unsafe 코드가 잦은 모듈의 특성상, 모든 unsafe 블록에 대해 해당 코드가 안전한 이유를 주석으로 반드시 남기도록 강제했습니다.
  • 린트 예외 사유 명시 (allow_attributes)
    • 불가피하게 린트 예외가 필요할 때 단순 허용(#[allow(...)])을 금지하고, #[expect(..., reason = "...")] 형태로 무조건 예외 사유를 기록하도록 만듭니다.

논리적으로 발생할 수 없는 (또는 발생하면 안 되는) 상황에서도 unwrap(panic)하지 않고 정상 동작하는 방어 코드를 넣도록 강제한다는 의미인가요?

아니요, 방어 코드를 강제하려는 것은 아닙니다. 논리적으로 일어날 수 없는 경우라면 그대로 unwrap/expect를 쓰되, #[expect(clippy::expect_used, reason = "...")]로 그 불변식을 적으면 됩니다.

이 린트의 목적은 패닉할 수 있는 지점을 숨기지 않고 이유와 함께 드러내는 것입니다.

옵션은 하나하나 필요에 따라 조정한 것인가요? 다른 곳의 프리셋을 가져온 것인가요?

필요에 따라 조정했습니다.

Comment thread Cargo.toml Outdated
@ing-eoking
ing-eoking force-pushed the develop branch 2 times, most recently from 91d1b47 to 4222f8f Compare October 23, 2026 06:25
@ing-eoking
ing-eoking force-pushed the crate-setup branch 3 times, most recently from 112fae5 to 97afec4 Compare October 23, 2026 07:31
@jam2in jam2in deleted a comment from coderabbitai Bot Oct 23, 2026
Comment thread Cargo.toml

This branch was previously deployed

1 inactive deployment
ee — f7dee4b2 Deployed Oct 23, 2026 by ing-eoking via test #11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants