aboutsummaryrefslogtreecommitdiff
path: root/CHANGELOG
diff options
context:
space:
mode:
Diffstat (limited to 'CHANGELOG')
-rw-r--r--CHANGELOG84
1 files changed, 82 insertions, 2 deletions
diff --git a/CHANGELOG b/CHANGELOG
index 4fb39ab..8cde9b8 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,8 +1,88 @@
-## 0.3.0
+## TODO
-TODO: Reader::next_n should return the number of items read as Err(ReadError::Incomplete(n)) if the buffer is exhausted
+~~TODO: Reader::next_n should return the number of items read as Err(ReadError::Incomplete(n)) if the buffer is exhausted~~
+* a reader's `.offset()` should reflect the amount of items that were consumed, if any. if a reader can quickly determine
+ there is not enough input, should it return Incomplete(0) or ExhaustedInput? Incomplete(0) vs ExhaustedInput may still
+ imply that some state was changed (an access mode, for example). this needs more thought.
TODO: Reader::offset should return an AddressDiff<Address>, not a bare Address
+* quick look seems reasonable enough, should be changed in concert with
+ yaxpeax-core though and that's more than i'm signing up for today
TODO: impls of `fn one` and `fn zero` so downstream users don't have to import num_traits directly
+* seems nice at first but this means that there are conflicting functions when Zero or One are in scope
+ ... assuming that the idea at the time was to add `fn one` and `fn zero` to `AddressBase`.
+TODO: 0.4.0 or later:
+ * remove `mod colors`, crossterm dependency, related feature flags
+
+## 0.3.2
+
+fix yaxpeax-arch not building for non-x86 targets when alloc is not enabled
+
+## 0.3.1
+
+fix InstructionTextSink::write_char to not panic in debug builds
+
+## 0.3.0
+
+added a new crate feature flag, `alloc`.
+ this flag is for any features that do not require std, but do require
+ containers from `liballoc`. good examples are `alloc::string::String` or
+ `alloc::vec::Vec`.
+
+added `yaxpeax_arch::display::DisplaySink` after revisiting output colorization.
+ `DisplaySink` is better suited for general markup, rather than being focused
+ specifically on ANSI/console text coloring. `YaxColors` also simply does not
+ style text in some unfortunate circumstances, such as when the console that
+ needs to be styled is only written to after intermediate buffering.
+
+ `DisplaySink` also includes specializable functions for writing text to an
+ output, and the implementation for `alloc::string::String` takes advantage of
+ this: writing through `impl DisplaySink for String` will often be substantially
+ more performant than writing through `fmt::Write`.
+
+added `mod color_new`:
+ this includes an alternate vision for `YaxColors` and better fits with the
+ new `DisplaySink` machinery; ANSI-style text markup can be done through the
+ new `yaxpeax_arch::color_new::ansi::AnsiDisplaySink`.
+
+ this provides more flexibility than i'd initially expected! yours truly will
+ be using this to render instructions with HTML spans (rather than ANSI
+ sequences) to colorize dis.yaxpeax.net.
+
+ in the future, `mod colored` will be removed, `mod color_new` will be renamed
+ to `mod color`.
+
+deprecated `mod colored`:
+ generally, colorization of text is a presentation issue; `trait Colorize`
+ mixed formatting of data to text with how that text is presented, but that is
+ at odds with the same text being presented in different ways for which
+ colorization is not generic. for example, rendering an instruction as marked
+ up HTML involves coloring in an entirely different way than rendering an
+ instruction with ANSI sequences for a VT100-like terminal.
+
+added `yaxpeax_arch::safer_unchecked` to aid in testing use of unchecked methods
+ these were originally added to improve yaxpeax-x86 testing:
+ https://github.com/iximeow/yaxpeax-x86/pull/17, but are being pulled into
+ yaxpeax-arch as they're generally applicable and overall wonderful tools.
+ thank you again 522!
+
+added `mod testkit`:
+ this module contains tools to validate the correctness of crates implementing
+ `yaxpeax-arch` traits. these initial tools are focused on validating the
+ correctness of functions that write to `DisplaySink`, especially that span
+ management is correct.
+
+ `yaxpeax-x86`, for example, will imminently have fuzz targets to use these
+ types for its own validation.
+
+made VecSink's `records` private. instead of extracting records from the struct
+ by accessing this field directly, call `VecSink::into_inner()`.
+
+made VecSink is now available through the `alloc` feature flag as well as `std`.
+
+meta: the major omission in this release is an architecture-agnostic way to
+format an instruction into a `DisplaySink`. i haven't been able to figure out
+quite the right shape for that! it is fully expected in the future, and will
+probably end up somehow referenced through `yaxpeax_arch::Arch`.
## 0.2.8