Triage the issue tracker

[dtolnay]

It would be helpful to label and prioritize issues that are blocking a 1.0 release of memmap. Here is what I am able to tell:

• Add named map support #2—From a skip through the code, this looks like a backward compatible addition. Is this a blocker for 1.0? It has been 2 years. Do we still want something like this? If a different approach would be better, let's close the PR and file an issue to track it.
• Clarification #18—Looks like this has been resolved, possibly with a documentation clarification outstanding. Let's file a separate issue to track specifically the docs work.
• Add MAP_FIXED mode #21—How likely is this to happen? Is it a blocker for 1.0? Can it be backward compatible?
• Safety of Mmap::as_slice ? #25—This needs to be documented better. I would consider this important for 1.0.
• Huge Pages #26—Is this a blocker for 1.0? Can it be backward compatible?
• memmap doesn't support an execute-only mapping. #29—Do we still want an mprotect wrapper in memmap? Is it a blocker for 1.0?
• Support discontinuous memory maps #30—How likely is this to happen? It won't work on Windows.
• Separate virtual page allocation from memory maps backed by page file #31—This seems like a high priority to address before stabilizing anything.
• Expand crate-level documentation #32—This needs work before 1.0 but is blocked by Overhaul API #33.
• Overhaul API #33—This may or may not be done. All the checkboxes are checked. If there is remaining work, it should be tracked in a separate issue.
• Add examples to methods #34—This should have been closed.
• Document error conditions for fallible methods in a separate "Errors" section #37—This needs work before 1.0 but is blocked by Overhaul API #33.
• Remove Protection #46—Unclear what the remaining work is. Please explain in a comment in case somebody else is motivated to pick it up. This seems like a blocker for 1.0.
• Documentation / user guide #47—I agree that "quite a bit more documentation would be useful," even if that means linking heavily to system man pages. I feel this needs attention before 1.0.
• add addr(*mut u8) to set the desired target address #48—This would be a breaking change so it needs to be settled before 1.0.
• File ownership #49—Looks like this has been resolved and no change is needed.

[danburkert]

Hey David, thanks for taking the time to do this, it's much appreciated. I've gone through and commented or closed on pretty much every issue on that list.

As far as 1.0, the only hard blockers I have are landing #46, a resolution to #31, and documentation. #46 has turned out to be a fairly big API refactor/simplification, and I'd like to get a good review from the various stakeholders on that. I'll make sure to ping people on that once it goes green.