POSIX has recvfrom(2) and sendto(2), but their name seem not to be
suitable with Rust. We already renamed getpeername(2) and
getsockname(2), so I think it makes sense.
Alternatively, `receive_from` would be fine. However, we have `.recv()`
so I chose `recv_from`.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
- Fix a couple mistakes:
- `Ordering` is an enum, not a trait.
- `Container` is now named `Collection`.
- Add missing `CheckedDiv`.
- Remove obsolete `OwnedVector`.
- Reorganize some lines to match [prelude's arrangement](http://doc.rust-lang.org/std/prelude/#reexports), making mistakes easier to spot in the future.
I'm going to move testing to be right AFTER the guessing game. I wanted it
to be borderline TDD, but I think that, since the first example is just one
file, it might be a bit overkill.
I'm doing this in its own commit to hopefully avoid merge conflicts.
Earlier commits have established a baseline of `experimental` stability
for all crates under the facade (so their contents are considered
experimental within libstd). Since `experimental` is `allow` by
default, we should use the same baseline stability for libstd itself.
This commit adds `experimental` tags to all of the modules defined in
`std`, and `unstable` to `std` itself.
This does two things:
* Reorganizes the declaration order to be more readable, less random.
* Removes the `slice::traits` module, a public module that does nothing but declare impls of `cmp` traits.
Part of #14248
Main authors:
- @Ryman: OK
- @TeXitoi: OK
- @pcwalton: OK
Minor authors:
- @brson: OK
- @alexcrichton: OK
- @kballard: OK
Remark: @tedhorst was a main contributor, but its contribution
disapear with @pcwalton rewrite at af4ea11
This commit hooks rustdoc into the stability index infrastructure in two
ways:
1. It looks up stability levels via the index, rather than by manual
attributes.
2. It adds stability level information throughout rustdoc output, rather
than just at the top header. In particular, a stability color (with
mouseover text) appears next to essentially every item that appears
in rustdoc's HTML output.
Along the way, the stability index code has been lightly refactored.
Earlier commits have established a baseline of `experimental` stability
for all crates under the facade (so their contents are considered
experimental within libstd). Since `experimental` is `allow` by
default, we should use the same baseline stability for libstd itself.
This commit adds `experimental` tags to all of the modules defined in
`std`, and `unstable` to `std` itself.
This commit hooks rustdoc into the stability index infrastructure in two
ways:
1. It looks up stability levels via the index, rather than by manual
attributes.
2. It adds stability level information throughout rustdoc output, rather
than just at the top header. In particular, a stability color (with
mouseover text) appears next to essentially every item that appears
in rustdoc's HTML output.
Along the way, the stability index code has been lightly refactored.
I'm working on adding examples to the API documentation. Should future pull requests include examples for more than one function? Or is this about the right size for a pull request?
./hello_world is not recognized on Windows.
We can type either hello_world or hello_world.exe to run the executable. I chose "hello_world.exe", which seems more conventional on Windows.
### Breaking changes:
* **Removed unnecessary `box` from enum variant (`Object(Box<Object>)` becomes `Object(Object)`)**
* **Deprecated `Encoder::str_encode`**
### Other changes:
* Tried to make the code more idiomatic
* Renamed the `wr` field of the `Encoder` and `PrettyEncoder` structs to `writer`
* Replaced some `from_utf8` by `from_utf8_owned` to avoid unnecessary allocations
* Removed unnecessary `unsafe` code
* Added `encode` and `decode` shortcut functions
* Implemented `FromStr` for `Json`
* Implemented `ToJson` for tuples of arity up to 12
* Fixed some details in the documentation
### Questions
* ~~The `encode` shortcut function does the same as the `Encoder::str_encode` function. It seems wrong to me that two functions do exactly the same. Should we deprecate `Encoder::str_encode`?~~
* ~~Do we really want the ToJson trait for tuples? At the moment we have it for (), (A, B), (A, B, C). I would like to remove them.~~
* ~~We are using `String` as key in the `TreeMap` representing a `Json` object. It would be better to use `&str`, but this would require to annotate lots of lifetimes. Is there any easy solution for this?~~
* There is a lot of duplicated code (`PrettyEncoder` copies about 50 lines from `Encoder`). In an OO language this could be solved very elegantly by using inheritance and overriding. What can we do here to reduce the amount of boilerplate?
[breaking-change]
Now you can just use `json::encode` and `json::decode`, which is very
practical
**Deprecated `Encoder::str_encode` in favor of `json::encode`**
[breaking-change]
* Tried to make the code more idiomatic
* Renamed the `wr` field of the `Encoder` and `PrettyEncoder` structs to `writer`
* Replaced some `from_utf8` by `from_utf8_owned` to avoid unnecessary allocations
* Removed unnecessary `unsafe` code
Closes#14358.
~~The tests are not yet moved to `utf16_iter`, so this probably won't compile. I'm submitting this PR anyway so it can be reviewed and since it was mentioned in #14611.~~ EDIT: Tests now use `utf16_iter`.
This deprecates `.to_utf16`. `x.to_utf16()` should be replaced by either `x.utf16_iter().collect::<Vec<u16>>()` (the type annotation may be optional), or just `x.utf16_iter()` directly, if it can be used in an iterator context.
[breaking-change]
cc @huonw
This deprecates `.to_utf16`. `x.to_utf16()` should be replaced by either
`x.utf16_units().collect::<Vec<u16>>()` (the type annotation may be optional), or
just `x.utf16_units()` directly, if it can be used in an iterator context.
Closes#14358
[breaking-change]
It turns out that HashMap's from_iter implementation was being
initialized without the sip keys being randomized. This adds
a custom default hasher that should avoid this potential vulnerability.
