Prior to this commit, every block comment /* */ required two closing tags for
every opening tag in order to terminate the highlighting. Setting and testing
for a variable was the culprit, though I'm not certain why, but they appear to
just be boilerplate lines from whatever pcwalton based this file upon. I've
looked at other officially-distributed vim highlighting files and none seem to
do the test that this commit removes, so I'm fairly certain it didn't provide
anything vital. And now comment highlighting works!
1. make /// ... and //! ... and /** ... */ and /*! ... */ into sugar for #[doc = ...] attributes.
2. add a script in etc/ to help converting doc-attributes to doc-comments
3. add some functions to core::str to help with (1)
type_use was failing to look into ty_boxes, which caused monomorphize
to coalesce instances that shouldn't have been coalesced (because they
should actually use different type glue)
Closes#2734
.. there are some additional FIXME nags in net_tcp (L 1012) about blocking
because libuv is holding unsafe ptrs to task local data. the proposed
fix going is not really feasible w/ the current design, IMO, but i'll
leave it there in case someone really wants to make the case without
creating more hassle than it's worth.
now the best of what we had prior to libuv integration (proper
validation of an ipv4 string), along with libuv support
(initial ipv6 support)
libuv has even weaker facilities for validating an input ipv6
(but still more than what we had), so eventually the "right"
answer would be to roll a proper ipv6 address string parser
in rust
libuv's own ip vetting code appears to in a somewhat woeful state,
for both ipv4 and ipv6 (there are some notes in the tests for net_ip, as
well as stuff added in uv_ll). They are aware of this and welcome patches.
I have rudimentary code in place that can verify whether the provided str
ip was, in fact, validly parsed by libuv, making a few assumptions:
* for ipv4, we assume that the platform's INADDR_NONE val is 0xffffffff ,
I should write a helper to return this value from the platform's libc
headers instead of hard-coding it in rust.
* for ipv6, we assume that the library will always return '::' for
malformed inputs.. as is the case in 64bit ubuntu. I need to verify this
on other platforms.. but at least the debugging output is in place, so
if expectations don't line up, it'll be straightforward to address
.. but the test is kind of broken.. it appears that rust pads structs for
alignment purposes? I can't get the struct to == 28.. that appears to
be the native size of sockaddr_in6.. so we have a size 32 struct, for now.
i mistook an "unconstrained type" error, due to type-inference messup
because i didnt have return vals in some closure wired-up right, for being
due to not having a str as a str/& (a str will actually auto-coerce to a
str/&, so str::as_slice was erroneously added. my bad).
* updated rustdoc info for several functions
* changed read_stop to take control of the port returned by read_start
* made write_future do an explicit data copy with the binary vector it is
passed
