The `AcceptedAlert::write` fn may return having only written some of the
alert buffer. We could either repeatedly call `write` until it
returns `Ok(0)` or an error, or use the new `write_all` fn. This commit
does updates the acceptor example to do the latter.
The `wr: &mut dyn io::Write` provided to `AcceptedAlert::write` may
return from a short write without having written the entire alert
contents. To avoid dropping the remaining data in this circumstance
the caller should make sure to repeatedly call `AcceptedAlert::write`
until it returns `Ok(0)` or an error.
This avoids our Cargo.lock containing a previous version of this
crate, and means a local `cargo build` is sufficient to check
rustls-post-quantum/ builds against the current rustls/.
This allows the new, nightly-only, `--branch` argument to
get everywhere it needs to. That enables branch coverage
tracking.
Example use:
$ ./admin/coverage --branch --html --open
```
error: assigning the result of `Clone::clone()` may be inefficient
--> rustls/tests/api.rs:64:9
|
64 | client_config.alpn_protocols = client_protos.clone();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use `clone_from()`: `client_config.alpn_protocols.clone_from(&client_protos)`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assigning_clones
= note: `-D clippy::assigning-clones` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::assigning_clones)]`
```
To allow for easy running and simplification of benchmarking, add cargo
build to the bench measure.
Also add .PHONY for recipes with no output that are always expected to
run.
Previously the `std` feature was in the explicit rustls dependency
feature list, and not opted-in by the provider's own `std` feature.
I believe this means when building the provider with
`--no-default-features` we were still using Rustls w/ the `std` feature.
In these, the server's share has a data dependency on the
client's share. Therefore, fuse the start() and complete()
operations in this case.
This is only supported for TLS1.3. TLS1.2 does not allow this
arrangement.
The vast majority of Cargo features in the crates ecosystem use dashes
to separate words, rather than underscores. The fact that `aws_lc_rs`
uses underscores, and some crates depending on rustls naturally use the
same name for the feature that rustls does, has led some crates to end
up with inconsistent feature naming that throws people off (e.g. using
the wrong feature name and being surprised at the resulting compilation
failures), and has led other crates to use `aws-lc-rs` for consistency
with their other features which causes inconsistency with rustls.
Add an alias, so that it works either way, and people can reference
either one.
This is complaining about the import of the `env` module from
`std::env`, instead of `core::env`.
However, `core::env` is a completely different item -- it is
the `env!` macro.