NixPath -> NixString and Error -> Errno#230
Conversation
0a16991 to
f6aaffc
Compare
|
Is the idea to drop |
|
Did @carllerche ever comment on #221? |
That's correct, and why I named the method |
dc64919 to
780ae21
Compare
src/errno.rs
Outdated
There was a problem hiding this comment.
A bit of doc for this would be good. After reading I figured out it's how to determine if an error occurred or not from the return value.
|
Sorry for the delay! I'm commenting on #221 |
84c7fbb to
593ede4
Compare
|
Doing some PR triage. This one's going to hang around a bit longer pending #221, I think! |
|
Hmmm, now this PR fails because Might have to use a build script to determine version features? I wonder if that would help for also replacing |
Well #238 hasn't been closed yet... we could discuss a bit in there? There's also some discussion on the users discourse instance which I'll link to on the other issue.
Not sure what you mean there? |
We could add some conditional compilation magic into nix_string.rs:
This is what the rustc_version crate is for. |
|
I was thinking about how to get further along with what this PR is trying to do. Let's break it down into a few stages:
I think we can get more people to weigh in on the changes if the PRs are smaller. We can also have more focused discussion of two individual changes. I also think it'll help because right now pretty much every merged PR will cause conflicts with this one, making it hard to land. |
|
I'm happy to help break it up if you like, just let me know! |
mm sorry was just testing on CI. It's probably something that should go in its own PR anyway.
However, we can land
This is a strange workflow to me since the intermediate state of the repo would be useless. I guess if we want to break it up I'd do it more like...
The last three seem like a single PR to me, breaking it up by module doesn't seem particularly productive as it's just a search-replace NixPath -> NixString. The feedback on that change won't be limited to any particular function or module, it's a fundamental change that raises the question: do we want to remove the stack allocation, copy, and path length check (thus delegating CString conversions to the caller) or not? Landing |
12ef980 to
c437533
Compare
c437533 to
1da348c
Compare
|
Rebased. The title still applies. |
|
Note that the |
|
☔ The latest upstream changes (presumably #271) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Considering how old this is and how it looks like at least some of this was merged in #247, is there anything worth salvaging from this PR and someone willing to push this work forward? If not, let's go ahead and close this. |
|
The PR still applies, although I'm not sure whether any conclusions were come to re #221. I'm happy to help update/rebase if a particular design is agreed on as the best way forward. This particular PR makes every API call just |
Major API change, it passes on the responsibility of dealing with
CStringconversions to the caller. The error type is now justErrnoitself.Closes #221
cc @kamalmarhubi