aboutsummaryrefslogtreecommitdiff
path: root/src/lib.rs
AgeCommit message (Collapse)Author
2020-01-12color helper for misc instructionsiximeow
2020-01-12decoders are stateful, so decode functions should take them as a parameteriximeow
2020-01-12warnings-b-goneiximeow
2020-01-12addresses are Hashiximeow
2020-01-12remove unused importiximeow
2020-01-12sneak hash/partialeq/etc into yaxpeax-archiximeow
2020-01-12awful tweaks to expose a serde flag on yaxpeax-arch which will trickle ↵iximeow
through everything
2020-01-12add color for program counter register (default to the same as ret and friends)iximeow
2020-01-12expose platform op coloriximeow
2020-01-12add some display logic into archiximeow
2020-01-12tweak how ColorSettings is usediximeow
enum to tie together a color and a thing to be colored, helper methods to build that, and an impl on Option that gives non-colored variants
2020-01-12add many more color types to settings, AddrParse to parse addresses from hex ↵iximeow
or decimal strings
2020-01-12real color settings, and defaultsiximeow
2020-01-12add traits for syntax highlighting and contextualized displayiximeow
these traits are not ideal but are what i can do in rust right now the initial attempt to add these traits involved a trait providing a `colorize` function that returned a struct (or tuple) that impl'd Display but bundled all useful data together. this would be nice because use would be like: ``` println!("the next instruction is: {}", instr.colorize(settings)); ``` but this runs into the same kind of lifetime issues as mentioned in the ContextRead commit. additionally complicating is contextualization, which involves a larger structure than just a copyable color setting - a similar builder-and-display style use would be nice but involves a third lifetime (the content, the colors, the contexts) and is not workable. references could be Rc pointers and this all might work. why not do that? moral opposition to cloning Rc pointers when doing any instruction rendering. might be worth revisiting later if i'm convinced this is too annoying - it's already close. meanwhile, it turns out implementing traits on tuples is currently not possible anyway - tuples are not #[fundamental]. in the future i need to investigate if i can use macros to tie into `derive`, so that a ShowContextual impl can #[derive(Colorize, Display)]. those implementations would really just call ShowContextual.colorize with fewer and fewer parameters non-None. the blanket impl ``` impl <T, U> Colorize for T where T: ShowContextual<U> ``` is entirely just a relic of one attempt, and can be ignored. this idea conflicted with coherence rules because someone else could impl Colorize for some type covered under this blanket impl.
2020-01-12add impls for address as used by x86_64iximeow
2020-01-12tweak core lifetimes, add an address formatteriximeow
2020-01-12require Arch to have addresses that can += and -=, as well as that ↵iximeow
instructions have a debug display
2020-01-12add some predetermined address display stuffiximeow
also add zero and one traits to Address, adjust layout
2020-01-12base definition of an arch to yaxpeaxiximeow