Every place where a type/function name is used in a Humility API should allow fully-qualified names.
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 28/100
Hướng nghiên cứu
Bắt đầu bằng cách theo dõi phần hỗ trợ một phần của Humility đối với tên đầy đủ và các vị trí gọi API chấp nhận tên kiểu hoặc tên hàm; issue không nêu các tệp hoặc test cụ thể. Xác định nơi còn các tên không đầy đủ và quy định cách biến sự không rõ ràng thành lỗi, đồng thời vẫn giữ khả năng tra cứu thuận tiện trong TUI. Hoàn tất khi mọi vị trí trong API của Humility đều có thể chấp nhận tên đầy đủ.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Rust programs often use the same name in different modules, because we have modules/namespaces. e.g. a typical program will contain many types named Error in different places.
Humility originally stripped crate/module path information off types, and used unqualified names. This has been causing problems for a while in things like processing Idol interfaces -- see https://github.com/oxidecomputer/hubris/issues/1896 for the most recent case.
I added partial support for fully qualified names back in 2021, but we need to complete the switch-over. It's okay to allow unqualified names in some cases (particularly in the TUI!) but that should be a convenience, which turns into an error if the name is ambiguous. At that point the user should always be able to provide a fully qualified name.
- Ngôn ngữ chính
- Rust
- Star
- 589
- Fork
- 66
- Merge trung bình
- 2 ngày 52 phút
- Pull request đã merge (30 ngày)
- 10
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 oxidecomputer/humility
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
oxidecomputer/humility#737 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
oxidecomputer/humility#746 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 30/100
oxidecomputer/humility#742 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
rendmp phase check should be usable on Sidecars (the sequel)Có thể đã có người làm @jamesmunns đã nhận 12 ngày trước. Đang mở
oxidecomputer/humility#741 · 6 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 65/100
oxidecomputer/humility#730 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của oxidecomputer/humility
Issue tương tự
-
desktop documentation
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
vfarcic/dot-agent-deck#2008 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
pbakaus/impeccable#1210 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Deduplicate the `--yes`/non-interactive-terminal refusal guard (three near-identical copies)Đang mởenhancement ux-opportunities
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
area: ci priority: P4 ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
shep-pm/shep#1249 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
status:untriaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
midnightntwrk/midnight-zk#600 ·
Maintainer thường phản hồi trong vòng 2 ngày