The first empty line in the changeset indicates the end of headers and
beginning of description. Callers can't know figure out where that
position is if empty lines are skipped.
Details
- Reviewers
Alphare - Group Reviewers
hg-reviewers - Commits
- rHGfb82b5cb8301: rust-changelog: don't skip empty lines when iterating over changeset lines
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
rust/hg-core/src/revlog/changelog.rs | ||
---|---|---|
48 | By the way, how do you want to extend this type in the future? For example, we could do a coarse splitting into header lines, files list, and description in the constructor, and then we can do more detailed parsing of each header line lazily. |
rust/hg-core/src/revlog/changelog.rs | ||
---|---|---|
48 | We could lazily fill an offsets fixed-sized array and have functions that return the slice to header lines, files list, and description. This would be the lower overhead (I think) while still giving a nice API. | |
60–65 | Please return Err(HgError::corrupted("changelog does not contain manifest node")) instead of unwrapping |
rust/hg-core/src/revlog/changelog.rs | ||
---|---|---|
60–65 | That can't happen AFAIK, since I removed the filtering-out of empty lines in lines() above. If the input is empty, the iterator will yield a single empty line. |
rust/hg-core/src/revlog/changelog.rs | ||
---|---|---|
60–65 | Think of it as a defensive solution to the code evolving. I dislike unwraps outside of tests since they don't convey the intent of why they're valid at the moment they're written. All unwraps should be excepts IMO (maybe that could become a lint for this codebase). My suggestion of using Result is simply because we already have the signature for it, it would turn the corruption into a nicer experience for the user, and would allow us to maybe build rhg verify more easily than with a panicking parser. What do you think? |
rust/hg-core/src/revlog/changelog.rs | ||
---|---|---|
60–65 | I like with expect() as a way of documenting why we think unwrap() would have been safe. I'll change to that. I don't like returning an error here because that would only be returned if we had a bug here (such as filtering out empty lines in lines()), so the error might be misleading. |
By the way, how do you want to extend this type in the future? For example, we could do a coarse splitting into header lines, files list, and description in the constructor, and then we can do more detailed parsing of each header line lazily.