Repository navigation
Conversation
While we store the graph pointer, it won't be dangling as graph is owned by pinyin context anyway.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 34 minutes. View limit details
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Configurable LRUCache lookup src/libime/core/lrucache.h |
LRUCache uses standard unordered-map types with configurable hash and equality objects. Its find method accepts a compatible key. |
Pinyin path hashing and equality src/libime/pinyin/pinyinmatchstate_p.h |
PinyinStringHasher converts and hashes segment paths. PinyinStringEqual compares paths with strings, and both cache aliases use these types. |
Pinyin dictionary cache lookups src/libime/pinyin/pinyindictionary.cpp |
The dictionary code removes its separate path hasher and uses the Pinyin helper types to find cache entries by path and create string keys. |
Estimated code review effort: 3 (Moderate) | ~20 minutes
Change: Refactor
Merge Risk: 
Minimal · previous review 195c5
-
No actionable merge-blocking issue is established; the change is mergeable after normal checks.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passed-
Full details: Title check
-
Explanation
The title "Port lru cache to use std::unordered_map" matches the main change in src/libime/core/lrucache.h, where LRUCache moves from boost::unordered_map and boost::hash to std::unordered_map, std::hash, and std::equal_to. The pinyin changes support this port by adding a PinyinStringHasher and PinyinStringEqual for the caches. The title is specific and short, and it names the primary change. It does not mention the pinyin-side hasher and equality work, but that is a supporting detail.
-
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 9 functions across 3 files.
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches
-
Generate docstrings
-
- Commit to this branch
- Create a new PR
Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
There was a problem hiding this comment.
🟢 Approval recommended
The review found no unresolved actionable issues in the changed cache and lookup implementations, with the noted downstream compatibility considerations not treated as active blockers.
No open issues 🎉
What changed in this PR
Ports the LRU cache from Boost containers to std::unordered_map and adds graph-aware heterogeneous lookup for equivalent pinyin paths.
Changes:
- Replaces Boost unordered-map usage with configurable standard-library hash and equality functors.
- Adds transparent hashing and equality for pinyin strings and segment graph paths.
- Updates pinyin dictionary cache construction and lookup behavior.
| File | Summary | Review notes |
|---|---|---|
src/libime/pinyin/pinyinmatchstate_p.h |
Adds graph-aware transparent hashing and equality for pinyin paths and updates cache types. | No actionable issues identified. |
src/libime/pinyin/pinyindictionary.cpp |
Uses graph-specific cache functors and heterogeneous path lookups. | No actionable issues identified. |
src/libime/core/lrucache.h |
Migrates the LRU cache to std::unordered_map with configurable hash and equality types. |
Moderate, 1 vote: Removing the existing heterogeneous find API may cause source incompatibility for downstream users. Moderate, 1 vote: Changing the default hash from boost::hash<K> to std::hash<K> may break existing users whose key types lack a standard hash specialization. |
Review effort: Lite
While we store the graph pointer, it won't be dangling as graph is owned
by pinyin context anyway.
Summary by CodeRabbit