Stack::capacity takes &mut self in src/ctors.rs, forcing callers to hold a mutable borrow to read a const-generic constant
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 78/100
Hướng nghiên cứu
Bắt đầu với định nghĩa capacity tại src/ctors.rs:38-40, sau đó kiểm tra các nơi gọi nó trong src/stack.rs, đặc biệt là try_push và try_pop. Kiểm tra các phương thức reader xung quanh và chạy bộ kiểm thử Rust hoặc Clippy; hoàn tất khi capacity không còn yêu cầu quyền truy cập có thể thay đổi và các nơi gọi bị ảnh hưởng biên dịch sạch.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The capacity method declared at src/ctors.rs:38-40 is pub fn capacity(&mut self) -> usize and its body simply returns the const-generic N. It reads no field and mutates nothing, but its signature forces every external caller to hold a mutable borrow on the stack just to read the compile-time capacity, which blocks any concurrent shared borrow and breaks several otherwise-natural call sites.
The signature also contradicts the rest of the API: len, is_empty, and other state-readers on Stack in src/stack.rs are correctly declared &self (and several are even const fn). Stack::try_push and Stack::try_pop in src/stack.rs:80-84 and src/stack.rs:117-121 already paper over the bug internally by only calling self.capacity() from inside methods that already hold &mut self. There is no scenario in which the receiver needs to be mutable for this method. Clippy's wrong_self_convention family is set up to flag exactly this pattern.
The fix is to change the signature to pub const fn capacity() -> usize { N } (associated function returning N directly) and update the two callers in src/stack.rs accordingly, or, if a method-style call is preferred for source compatibility, to pub const fn capacity(&self) -> usize { N }. Either form is a one-line change in src/ctors.rs plus two trivial call-site updates in src/stack.rs.
- Ngôn ngữ chính
- Rust
- Star
- 13
- Fork
- 4
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của yegor256/microstack
-
Deserializing a sequence longer than N panics in src/serialization.rs instead of returning an errorĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
yegor256/microstack#86 ·
-
Dependency DashboardĐang mởwontfix
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 20/100
yegor256/microstack#24 · 1 người được giao ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
yegor256/microstack#19 · 3 bình luận · 1 người được giao ·
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 45/100
yegor256/microstack#15 ·
-
enhancement
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
yegor256/microstack#13 · 1 bình luận ·
Tất cả issue của yegor256/microstack
Issue tương tự
-
crate: spate-kafka documentation priority: medium
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
balovess/aria2_rust#88 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Shell `yoyo <verb> <sub>` missing its required argument prints usage and exits 0: `config get`Đang mởagent-self
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
yologdev/yoyo-evolve#1154 ·