into the vtable
also break `drainTo` and `sendFileTo` into lower level primitives
`writeSplatHeader` and `sendFileHeader` respectively. these are easier
to reason about in drain implementations.
A lot of this logic disappears in the face of the new buffered reader
and buffered writer interface.
This is passing ast-check only; semantic analysis to be solved next.
- flatten std.crypto.hash.Sha1 and give it a writable interface that
optimizes splats
- flatten std.hash.crc and give it a writable interface that optimizes
splats
- remove old writer impls from std.crypto
- add fs.File.Writer.moveToReader
- add fs.File.Writer.seekTo
- add std.io.Reader.Hashed and std.io.Writer.Hashed which are
passthrough streams. Instead of passing through to null writer, use
the writable interface implemented directly on hashers which doesn't
have to account for passing through the data.
- add std.io.BufferedWriter.writeSplatAll
- use ArrayList strategically to reduce allocations
- use a BufferedReader to avoid unnecessary memcpy of the certs
- use for loops
- skip certs with invalid magic instead of asserting
- use labeled continue
- avoid anytype
- avoid dependency on a "seeking" API
- simpler, more optimal VM interpreter loop
- progress decoupling from host machine
- type safety for opcodes. see #15556
I think this is generally more useful than the existing add function
because it doesn't unnecessarily rely on the types of the operands - the
error only occurs if the final mathematical result cannot be stored in
the desired result type.
instead this use case is better served with passthrough streams. For
instance, hashing writers should support being passed an underlying
writer, and the buffer can go in front of the hasher for optimal code.
