employer
/
tame
1
0
Fork 0
Code Packages Releases Activity
tame/tamer/Cargo.lock

134 lines
3.5 KiB
Plaintext
Raw Normal View History

TAMER: Initial commit
2019-11-14 16:43:07 -05:00
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
tamer: Remove default SymbolIndex (et al) index type Oh boy. What a mess of a change. This demonstrates some significant issues we have with Symbol. I had originally modelled the system a bit after Rustc's, but deviated in certain regards: 1. This has a confurable base type to enable better packing without bit twiddling and potentially unsafe tricks I'd rather avoid unless necessary; and 2. The lifetime is not static, and there is no global, singleton interner; and 3. I pass around references to a Symbol rather than passing around an index into an interner. For #3---this is done because there's no singleton interner and therefore resolving a symbol requires a direct reference to an available interner. It also wasn't clear to me (and still isn't, in fact) whether more than one interner may be used for different contexts. But, that doesn't preclude removing lifetimes and just passing around indexes; in fact, I plan to do this in the frontend where the parser and such will have direct interner access and can therefore just look up based on a symbol index. We could reserve references for situations where exposing an interner would be undesirable. Anyway, more to come...
2021-07-29 14:26:40 -04:00
version = 3
tamer: Start of XIR-based xmle writer This has been a long time coming, and has been repeatedly stashed as other parts of the system have evolved to support it. The introduction of the XIR tree was to write tests for this (which are sloppy atm). This currently writes out the `xmle` header and _most_ of the `l:dep` section; it's missing the object-type-specific attributes. There is, relatively speaking, not much more work to do here. The feature flag `wip-xir-xmle-writer` was introduced to toggle this system in place of `XmleWriter`. Initial benchmarks show that it will be competitive with the quick-xml-based writer, but remember that is not the goal: the purpose of this is to test XIR in a production system before we continue to implement it for a frontend, and to refactor so that we do not have multiple implementations writing XML files (once we echo the source XML files). I'm excited to get this done with so that I can move on. This has been rather exhausting.
2021-09-28 14:52:31 -04:00
[[package]]
name = "arrayvec"
tamer: Remove tests invoking cargo and associated libs There are a number of reasons for this, where the benefits do not make up for the losses. First: this is actually invoking cargo. Not only is this not necessary, but it's not desirable: cargo by default hits the network and does all sorts of other stuff, when all we want to do is invoke the executable. So the tests aren't really testing the right thing in that sense. See the previous commit for more information. The way it invokes cargo is different than the way the Makefile invokes cargo, so on my system, it's actually invoking a _different cargo_! This is causing problems, in particular with lock files, which causes my tests to fail. Importantly, this also removes a _lot_ of dependencies, which removes a lot of supplier chain risk and a lot of code to audit. This provides significant security benefits, especially given that what was being tested was rather small, and could be done in a shell script. TAMER will receive significant system testing later on. But for now, none of this was worth it. Further audits of dependencies will come later on. I've always been fairly insistent on keeping the dependency graph small and auditable, but recent supply chain attacks have given me a better way to rationalize the security risk. Further, I'm the only one on this project right now.
2021-12-02 12:32:56 -05:00
version = "0.7.2"
tamer: Start of XIR-based xmle writer This has been a long time coming, and has been repeatedly stashed as other parts of the system have evolved to support it. The introduction of the XIR tree was to write tests for this (which are sloppy atm). This currently writes out the `xmle` header and _most_ of the `l:dep` section; it's missing the object-type-specific attributes. There is, relatively speaking, not much more work to do here. The feature flag `wip-xir-xmle-writer` was introduced to toggle this system in place of `XmleWriter`. Initial benchmarks show that it will be competitive with the quick-xml-based writer, but remember that is not the goal: the purpose of this is to test XIR in a production system before we continue to implement it for a frontend, and to refactor so that we do not have multiple implementations writing XML files (once we echo the source XML files). I'm excited to get this done with so that I can move on. This has been rather exhausting.
2021-09-28 14:52:31 -04:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Remove tests invoking cargo and associated libs There are a number of reasons for this, where the benefits do not make up for the losses. First: this is actually invoking cargo. Not only is this not necessary, but it's not desirable: cargo by default hits the network and does all sorts of other stuff, when all we want to do is invoke the executable. So the tests aren't really testing the right thing in that sense. See the previous commit for more information. The way it invokes cargo is different than the way the Makefile invokes cargo, so on my system, it's actually invoking a _different cargo_! This is causing problems, in particular with lock files, which causes my tests to fail. Importantly, this also removes a _lot_ of dependencies, which removes a lot of supplier chain risk and a lot of code to audit. This provides significant security benefits, especially given that what was being tested was rather small, and could be done in a shell script. TAMER will receive significant system testing later on. But for now, none of this was worth it. Further audits of dependencies will come later on. I've always been fairly insistent on keeping the dependency graph small and auditable, but recent supply chain attacks have given me a better way to rationalize the security risk. Further, I'm the only one on this project right now.
2021-12-02 12:32:56 -05:00
checksum = "8da52d66c7071e2e3fa2a1e5c6d088fec47b593032b254f5e980de8ea54454d6"
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
[[package]]
name = "autocfg"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
version = "1.1.0"
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
checksum = "d468802bab17cbc0cc575e9b053f41e72aa36bfa6b7f55e3529ffa43161b97fa"
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
TAMER: Arena-based string interner Contrary to what I said previously, this replaces the previous implementation with an arena-backed internment system. The motivation for this change was investigating how Rustc performed its string interning, and why they chose to associate integer identifiers with symbols. The intent was originally to use Rustc's arena allocator directly, but that create pulled in far too many dependencies and depended on nightly Rust. Bumpalo provides a very similar implementation to Rustc's DroplessArena, so I went with that instead. Rustc also relies on a global, singleton interner. I do not do that here. Instead, the returned Symbol carries a lifetime of the underlying arena, as well as a pointer to the interned string. Now that this is put to rest, it's time to move on.
2019-12-23 23:26:42 -05:00
[[package]]
name = "bumpalo"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
version = "3.9.1"
TAMER: Arena-based string interner Contrary to what I said previously, this replaces the previous implementation with an arena-backed internment system. The motivation for this change was investigating how Rustc performed its string interning, and why they chose to associate integer identifiers with symbols. The intent was originally to use Rustc's arena allocator directly, but that create pulled in far too many dependencies and depended on nightly Rust. Bumpalo provides a very similar implementation to Rustc's DroplessArena, so I went with that instead. Rustc also relies on a global, singleton interner. I do not do that here. Instead, the returned Symbol carries a lifetime of the underlying arena, as well as a pointer to the interned string. Now that this is put to rest, it's time to move on.
2019-12-23 23:26:42 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
checksum = "a4a45a46ab1f2412e53d3a0ade76ffad2025804294569aae387231a0cd6e0899"
TAMER: Arena-based string interner Contrary to what I said previously, this replaces the previous implementation with an arena-backed internment system. The motivation for this change was investigating how Rustc performed its string interning, and why they chose to associate integer identifiers with symbols. The intent was originally to use Rustc's arena allocator directly, but that create pulled in far too many dependencies and depended on nightly Rust. Bumpalo provides a very similar implementation to Rustc's DroplessArena, so I went with that instead. Rustc also relies on a global, singleton interner. I do not do that here. Instead, the returned Symbol carries a lifetime of the underlying arena, as well as a pointer to the interned string. Now that this is put to rest, it's time to move on.
2019-12-23 23:26:42 -05:00
tamer::sym: FNV => Fx Hash For strings of any notable length, Fx Hash outperforms FNV. Rustc also moved to this hash function and noticed performance improvements. Fortunately, as was accounted for in the design, this was a trivial switch. Here are some benchmarks to back up that claim: test hash_set::fnv::with_all_new_1000 ... bench: 133,096 ns/iter (+/- 1,430) test hash_set::fnv::with_all_new_1000_with_capacity ... bench: 82,591 ns/iter (+/- 592) test hash_set::fnv::with_all_new_rc_str_1000_baseline ... bench: 162,073 ns/iter (+/- 1,277) test hash_set::fnv::with_one_new_1000 ... bench: 37,334 ns/iter (+/- 256) test hash_set::fnv::with_one_new_rc_str_1000_baseline ... bench: 18,263 ns/iter (+/- 261) test hash_set::fx::with_all_new_1000 ... bench: 85,217 ns/iter (+/- 1,111) test hash_set::fx::with_all_new_1000_with_capacity ... bench: 59,383 ns/iter (+/- 752) test hash_set::fx::with_all_new_rc_str_1000_baseline ... bench: 98,802 ns/iter (+/- 1,117) test hash_set::fx::with_one_new_1000 ... bench: 42,484 ns/iter (+/- 1,239) test hash_set::fx::with_one_new_rc_str_1000_baseline ... bench: 15,000 ns/iter (+/- 233) test hash_set::with_all_new_1000 ... bench: 137,645 ns/iter (+/- 1,186) test hash_set::with_all_new_rc_str_1000_baseline ... bench: 163,129 ns/iter (+/- 1,725) test hash_set::with_one_new_1000 ... bench: 59,051 ns/iter (+/- 1,202) test hash_set::with_one_new_rc_str_1000_baseline ... bench: 37,986 ns/iter (+/- 771)
2019-12-10 15:32:25 -05:00
[[package]]
name = "byteorder"
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
version = "1.4.3"
tamer::sym: FNV => Fx Hash For strings of any notable length, Fx Hash outperforms FNV. Rustc also moved to this hash function and noticed performance improvements. Fortunately, as was accounted for in the design, this was a trivial switch. Here are some benchmarks to back up that claim: test hash_set::fnv::with_all_new_1000 ... bench: 133,096 ns/iter (+/- 1,430) test hash_set::fnv::with_all_new_1000_with_capacity ... bench: 82,591 ns/iter (+/- 592) test hash_set::fnv::with_all_new_rc_str_1000_baseline ... bench: 162,073 ns/iter (+/- 1,277) test hash_set::fnv::with_one_new_1000 ... bench: 37,334 ns/iter (+/- 256) test hash_set::fnv::with_one_new_rc_str_1000_baseline ... bench: 18,263 ns/iter (+/- 261) test hash_set::fx::with_all_new_1000 ... bench: 85,217 ns/iter (+/- 1,111) test hash_set::fx::with_all_new_1000_with_capacity ... bench: 59,383 ns/iter (+/- 752) test hash_set::fx::with_all_new_rc_str_1000_baseline ... bench: 98,802 ns/iter (+/- 1,117) test hash_set::fx::with_one_new_1000 ... bench: 42,484 ns/iter (+/- 1,239) test hash_set::fx::with_one_new_rc_str_1000_baseline ... bench: 15,000 ns/iter (+/- 233) test hash_set::with_all_new_1000 ... bench: 137,645 ns/iter (+/- 1,186) test hash_set::with_all_new_rc_str_1000_baseline ... bench: 163,129 ns/iter (+/- 1,725) test hash_set::with_one_new_1000 ... bench: 59,051 ns/iter (+/- 1,202) test hash_set::with_one_new_rc_str_1000_baseline ... bench: 37,986 ns/iter (+/- 771)
2019-12-10 15:32:25 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
checksum = "14c189c53d098945499cdfa7ecc63567cf3886b3332b312a5b4585d8d3a6a610"
tamer::sym: FNV => Fx Hash For strings of any notable length, Fx Hash outperforms FNV. Rustc also moved to this hash function and noticed performance improvements. Fortunately, as was accounted for in the design, this was a trivial switch. Here are some benchmarks to back up that claim: test hash_set::fnv::with_all_new_1000 ... bench: 133,096 ns/iter (+/- 1,430) test hash_set::fnv::with_all_new_1000_with_capacity ... bench: 82,591 ns/iter (+/- 592) test hash_set::fnv::with_all_new_rc_str_1000_baseline ... bench: 162,073 ns/iter (+/- 1,277) test hash_set::fnv::with_one_new_1000 ... bench: 37,334 ns/iter (+/- 256) test hash_set::fnv::with_one_new_rc_str_1000_baseline ... bench: 18,263 ns/iter (+/- 261) test hash_set::fx::with_all_new_1000 ... bench: 85,217 ns/iter (+/- 1,111) test hash_set::fx::with_all_new_1000_with_capacity ... bench: 59,383 ns/iter (+/- 752) test hash_set::fx::with_all_new_rc_str_1000_baseline ... bench: 98,802 ns/iter (+/- 1,117) test hash_set::fx::with_one_new_1000 ... bench: 42,484 ns/iter (+/- 1,239) test hash_set::fx::with_one_new_rc_str_1000_baseline ... bench: 15,000 ns/iter (+/- 233) test hash_set::with_all_new_1000 ... bench: 137,645 ns/iter (+/- 1,186) test hash_set::with_all_new_rc_str_1000_baseline ... bench: 163,129 ns/iter (+/- 1,725) test hash_set::with_one_new_1000 ... bench: 59,051 ns/iter (+/- 1,202) test hash_set::with_one_new_rc_str_1000_baseline ... bench: 37,986 ns/iter (+/- 771)
2019-12-10 15:32:25 -05:00
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
[[package]]
name = "exitcode"
version = "1.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
checksum = "de853764b47027c2e862a995c34978ffa63c1501f2e15f987ba11bd4f9bba193"
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
Cargo.toml: Add petgraph This will be used to represent the dependency graph.
2019-11-27 13:48:00 -05:00
[[package]]
name = "fixedbitset"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
version = "0.4.1"
Cargo.toml: Add petgraph This will be used to represent the dependency graph.
2019-11-27 13:48:00 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
checksum = "279fb028e20b3c4c320317955b77c5e0c9701f05a1d309905d6fc702cdc5053e"
Cargo.toml: Add petgraph This will be used to represent the dependency graph.
2019-11-27 13:48:00 -05:00
TAMER: Initial string interning abstraction This is missing two key things that I'll add shortly: a HashMap-based one for use in the ASG for node mapping, and an entry-based system for manipulations. This has been a nice start for exploring various aspects of Rust development, as well as conventions that I'd like to implement. In particular: - Robust documentation intended to guide people through learning the necessary material about the compiler, as well as related work to rationalize design decisions; - Benchmarks; - TDD; - And just getting used to Rust in general. I've beat this one to death, so I'll commit this and make smaller changes going forward to show how easily it can evolve. (This module was originally named `intern` but this commit and those that follow rewrote it to `sym`.)
2019-12-06 15:03:29 -05:00
[[package]]
tamer::sym: FNV => Fx Hash For strings of any notable length, Fx Hash outperforms FNV. Rustc also moved to this hash function and noticed performance improvements. Fortunately, as was accounted for in the design, this was a trivial switch. Here are some benchmarks to back up that claim: test hash_set::fnv::with_all_new_1000 ... bench: 133,096 ns/iter (+/- 1,430) test hash_set::fnv::with_all_new_1000_with_capacity ... bench: 82,591 ns/iter (+/- 592) test hash_set::fnv::with_all_new_rc_str_1000_baseline ... bench: 162,073 ns/iter (+/- 1,277) test hash_set::fnv::with_one_new_1000 ... bench: 37,334 ns/iter (+/- 256) test hash_set::fnv::with_one_new_rc_str_1000_baseline ... bench: 18,263 ns/iter (+/- 261) test hash_set::fx::with_all_new_1000 ... bench: 85,217 ns/iter (+/- 1,111) test hash_set::fx::with_all_new_1000_with_capacity ... bench: 59,383 ns/iter (+/- 752) test hash_set::fx::with_all_new_rc_str_1000_baseline ... bench: 98,802 ns/iter (+/- 1,117) test hash_set::fx::with_one_new_1000 ... bench: 42,484 ns/iter (+/- 1,239) test hash_set::fx::with_one_new_rc_str_1000_baseline ... bench: 15,000 ns/iter (+/- 233) test hash_set::with_all_new_1000 ... bench: 137,645 ns/iter (+/- 1,186) test hash_set::with_all_new_rc_str_1000_baseline ... bench: 163,129 ns/iter (+/- 1,725) test hash_set::with_one_new_1000 ... bench: 59,051 ns/iter (+/- 1,202) test hash_set::with_one_new_rc_str_1000_baseline ... bench: 37,986 ns/iter (+/- 771)
2019-12-10 15:32:25 -05:00
name = "fxhash"
version = "0.2.1"
TAMER: Initial string interning abstraction This is missing two key things that I'll add shortly: a HashMap-based one for use in the ASG for node mapping, and an entry-based system for manipulations. This has been a nice start for exploring various aspects of Rust development, as well as conventions that I'd like to implement. In particular: - Robust documentation intended to guide people through learning the necessary material about the compiler, as well as related work to rationalize design decisions; - Benchmarks; - TDD; - And just getting used to Rust in general. I've beat this one to death, so I'll commit this and make smaller changes going forward to show how easily it can evolve. (This module was originally named `intern` but this commit and those that follow rewrote it to `sym`.)
2019-12-06 15:03:29 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
checksum = "c31b6d751ae2c7f11320402d34e41349dd1016f8d5d45e48c4312bc8625af50c"
tamer::sym: FNV => Fx Hash For strings of any notable length, Fx Hash outperforms FNV. Rustc also moved to this hash function and noticed performance improvements. Fortunately, as was accounted for in the design, this was a trivial switch. Here are some benchmarks to back up that claim: test hash_set::fnv::with_all_new_1000 ... bench: 133,096 ns/iter (+/- 1,430) test hash_set::fnv::with_all_new_1000_with_capacity ... bench: 82,591 ns/iter (+/- 592) test hash_set::fnv::with_all_new_rc_str_1000_baseline ... bench: 162,073 ns/iter (+/- 1,277) test hash_set::fnv::with_one_new_1000 ... bench: 37,334 ns/iter (+/- 256) test hash_set::fnv::with_one_new_rc_str_1000_baseline ... bench: 18,263 ns/iter (+/- 261) test hash_set::fx::with_all_new_1000 ... bench: 85,217 ns/iter (+/- 1,111) test hash_set::fx::with_all_new_1000_with_capacity ... bench: 59,383 ns/iter (+/- 752) test hash_set::fx::with_all_new_rc_str_1000_baseline ... bench: 98,802 ns/iter (+/- 1,117) test hash_set::fx::with_one_new_1000 ... bench: 42,484 ns/iter (+/- 1,239) test hash_set::fx::with_one_new_rc_str_1000_baseline ... bench: 15,000 ns/iter (+/- 233) test hash_set::with_all_new_1000 ... bench: 137,645 ns/iter (+/- 1,186) test hash_set::with_all_new_rc_str_1000_baseline ... bench: 163,129 ns/iter (+/- 1,725) test hash_set::with_one_new_1000 ... bench: 59,051 ns/iter (+/- 1,202) test hash_set::with_one_new_rc_str_1000_baseline ... bench: 37,986 ns/iter (+/- 771)
2019-12-10 15:32:25 -05:00
dependencies = [
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
"byteorder",
tamer::sym: FNV => Fx Hash For strings of any notable length, Fx Hash outperforms FNV. Rustc also moved to this hash function and noticed performance improvements. Fortunately, as was accounted for in the design, this was a trivial switch. Here are some benchmarks to back up that claim: test hash_set::fnv::with_all_new_1000 ... bench: 133,096 ns/iter (+/- 1,430) test hash_set::fnv::with_all_new_1000_with_capacity ... bench: 82,591 ns/iter (+/- 592) test hash_set::fnv::with_all_new_rc_str_1000_baseline ... bench: 162,073 ns/iter (+/- 1,277) test hash_set::fnv::with_one_new_1000 ... bench: 37,334 ns/iter (+/- 256) test hash_set::fnv::with_one_new_rc_str_1000_baseline ... bench: 18,263 ns/iter (+/- 261) test hash_set::fx::with_all_new_1000 ... bench: 85,217 ns/iter (+/- 1,111) test hash_set::fx::with_all_new_1000_with_capacity ... bench: 59,383 ns/iter (+/- 752) test hash_set::fx::with_all_new_rc_str_1000_baseline ... bench: 98,802 ns/iter (+/- 1,117) test hash_set::fx::with_one_new_1000 ... bench: 42,484 ns/iter (+/- 1,239) test hash_set::fx::with_one_new_rc_str_1000_baseline ... bench: 15,000 ns/iter (+/- 233) test hash_set::with_all_new_1000 ... bench: 137,645 ns/iter (+/- 1,186) test hash_set::with_all_new_rc_str_1000_baseline ... bench: 163,129 ns/iter (+/- 1,725) test hash_set::with_one_new_1000 ... bench: 59,051 ns/iter (+/- 1,202) test hash_set::with_one_new_rc_str_1000_baseline ... bench: 37,986 ns/iter (+/- 771)
2019-12-10 15:32:25 -05:00
]
TAMER: Initial string interning abstraction This is missing two key things that I'll add shortly: a HashMap-based one for use in the ASG for node mapping, and an entry-based system for manipulations. This has been a nice start for exploring various aspects of Rust development, as well as conventions that I'd like to implement. In particular: - Robust documentation intended to guide people through learning the necessary material about the compiler, as well as related work to rationalize design decisions; - Benchmarks; - TDD; - And just getting used to Rust in general. I've beat this one to death, so I'll commit this and make smaller changes going forward to show how easily it can evolve. (This module was originally named `intern` but this commit and those that follow rewrote it to `sym`.)
2019-12-06 15:03:29 -05:00
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
[[package]]
name = "getopts"
version = "0.2.21"
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
checksum = "14dbbfd5c71d70241ecf9e6f13737f7b5ce823821063188d7e46c41d371eebd5"
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
dependencies = [
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
"unicode-width",
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
]
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
[[package]]
name = "hashbrown"
tamer: Remove tests invoking cargo and associated libs There are a number of reasons for this, where the benefits do not make up for the losses. First: this is actually invoking cargo. Not only is this not necessary, but it's not desirable: cargo by default hits the network and does all sorts of other stuff, when all we want to do is invoke the executable. So the tests aren't really testing the right thing in that sense. See the previous commit for more information. The way it invokes cargo is different than the way the Makefile invokes cargo, so on my system, it's actually invoking a _different cargo_! This is causing problems, in particular with lock files, which causes my tests to fail. Importantly, this also removes a _lot_ of dependencies, which removes a lot of supplier chain risk and a lot of code to audit. This provides significant security benefits, especially given that what was being tested was rather small, and could be done in a shell script. TAMER will receive significant system testing later on. But for now, none of this was worth it. Further audits of dependencies will come later on. I've always been fairly insistent on keeping the dependency graph small and auditable, but recent supply chain attacks have given me a better way to rationalize the security risk. Further, I'm the only one on this project right now.
2021-12-02 12:32:56 -05:00
version = "0.11.2"
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Remove tests invoking cargo and associated libs There are a number of reasons for this, where the benefits do not make up for the losses. First: this is actually invoking cargo. Not only is this not necessary, but it's not desirable: cargo by default hits the network and does all sorts of other stuff, when all we want to do is invoke the executable. So the tests aren't really testing the right thing in that sense. See the previous commit for more information. The way it invokes cargo is different than the way the Makefile invokes cargo, so on my system, it's actually invoking a _different cargo_! This is causing problems, in particular with lock files, which causes my tests to fail. Importantly, this also removes a _lot_ of dependencies, which removes a lot of supplier chain risk and a lot of code to audit. This provides significant security benefits, especially given that what was being tested was rather small, and could be done in a shell script. TAMER will receive significant system testing later on. But for now, none of this was worth it. Further audits of dependencies will come later on. I've always been fairly insistent on keeping the dependency graph small and auditable, but recent supply chain attacks have given me a better way to rationalize the security risk. Further, I'm the only one on this project right now.
2021-12-02 12:32:56 -05:00
checksum = "ab5ef0d4909ef3724cc8cce6ccc8572c5c817592e9285f5464f8e86f8bd3726e"
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
TAMER: Update Cargo dependencies
2020-04-28 16:14:35 -04:00
[[package]]
name = "indexmap"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
version = "1.8.0"
TAMER: Update Cargo dependencies
2020-04-28 16:14:35 -04:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
checksum = "282a6247722caba404c065016bbfa522806e51714c34f5dfc3e4a3a46fcb4223"
TAMER: Update Cargo dependencies
2020-04-28 16:14:35 -04:00
dependencies = [
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
"autocfg",
"hashbrown",
TAMER: Update Cargo dependencies
2020-04-28 16:14:35 -04:00
]
tamer/Cargo.toml: Add quick_xml
2019-11-27 09:16:00 -05:00
[[package]]
name = "memchr"
tamer: Remove tests invoking cargo and associated libs There are a number of reasons for this, where the benefits do not make up for the losses. First: this is actually invoking cargo. Not only is this not necessary, but it's not desirable: cargo by default hits the network and does all sorts of other stuff, when all we want to do is invoke the executable. So the tests aren't really testing the right thing in that sense. See the previous commit for more information. The way it invokes cargo is different than the way the Makefile invokes cargo, so on my system, it's actually invoking a _different cargo_! This is causing problems, in particular with lock files, which causes my tests to fail. Importantly, this also removes a _lot_ of dependencies, which removes a lot of supplier chain risk and a lot of code to audit. This provides significant security benefits, especially given that what was being tested was rather small, and could be done in a shell script. TAMER will receive significant system testing later on. But for now, none of this was worth it. Further audits of dependencies will come later on. I've always been fairly insistent on keeping the dependency graph small and auditable, but recent supply chain attacks have given me a better way to rationalize the security risk. Further, I'm the only one on this project right now.
2021-12-02 12:32:56 -05:00
version = "2.4.1"
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Remove tests invoking cargo and associated libs There are a number of reasons for this, where the benefits do not make up for the losses. First: this is actually invoking cargo. Not only is this not necessary, but it's not desirable: cargo by default hits the network and does all sorts of other stuff, when all we want to do is invoke the executable. So the tests aren't really testing the right thing in that sense. See the previous commit for more information. The way it invokes cargo is different than the way the Makefile invokes cargo, so on my system, it's actually invoking a _different cargo_! This is causing problems, in particular with lock files, which causes my tests to fail. Importantly, this also removes a _lot_ of dependencies, which removes a lot of supplier chain risk and a lot of code to audit. This provides significant security benefits, especially given that what was being tested was rather small, and could be done in a shell script. TAMER will receive significant system testing later on. But for now, none of this was worth it. Further audits of dependencies will come later on. I've always been fairly insistent on keeping the dependency graph small and auditable, but recent supply chain attacks have given me a better way to rationalize the security risk. Further, I'm the only one on this project right now.
2021-12-02 12:32:56 -05:00
checksum = "308cc39be01b73d0d18f82a0e7b2a3df85245f84af96fdddc5d202d27e47b86a"
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
tamer: ir::asg::ident: AsRef impls for SymbolId types This commit will make more sense once the broader context is committed, but it's needed for lowering from `Sections` into a XIR stream. This will also change once we pre-allocate symbols, like rustc, when the interner is initialized. This is my first use of the `paste` crate, which is used to generate identifiers. So this is partly an experiment, and it seems much better than having to write a proc macro, at least at this point in time. If this code stays around, it'll probably be generalized further and used elsewhere, but I'd prefer not to go this route long-term.
2021-09-20 16:46:16 -04:00
[[package]]
name = "paste"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
version = "1.0.6"
tamer: ir::asg::ident: AsRef impls for SymbolId types This commit will make more sense once the broader context is committed, but it's needed for lowering from `Sections` into a XIR stream. This will also change once we pre-allocate symbols, like rustc, when the interner is initialized. This is my first use of the `paste` crate, which is used to generate identifiers. So this is partly an experiment, and it seems much better than having to write a proc macro, at least at this point in time. If this code stays around, it'll probably be generalized further and used elsewhere, but I'd prefer not to go this route long-term.
2021-09-20 16:46:16 -04:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
checksum = "0744126afe1a6dd7f394cb50a716dbe086cb06e255e53d8d0185d82828358fb5"
tamer: ir::asg::ident: AsRef impls for SymbolId types This commit will make more sense once the broader context is committed, but it's needed for lowering from `Sections` into a XIR stream. This will also change once we pre-allocate symbols, like rustc, when the interner is initialized. This is my first use of the `paste` crate, which is used to generate identifiers. So this is partly an experiment, and it seems much better than having to write a proc macro, at least at this point in time. If this code stays around, it'll probably be generalized further and used elsewhere, but I'd prefer not to go this route long-term.
2021-09-20 16:46:16 -04:00
Cargo.toml: Add petgraph This will be used to represent the dependency graph.
2019-11-27 13:48:00 -05:00
[[package]]
name = "petgraph"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
version = "0.6.0"
Cargo.toml: Add petgraph This will be used to represent the dependency graph.
2019-11-27 13:48:00 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Update dependencies Petgraph was previously held back due to petgraph-graphml. I'd like to transition away from that at some point, given that it's tied to petgraph and also pulls in xmlns, on top of quick-xml and our XIR, but that can come down the line.
2022-03-11 10:51:51 -05:00
checksum = "4a13a2fa9d0b63e5f22328828741e523766fff0ee9e779316902290dff3f824f"
Cargo.toml: Add petgraph This will be used to represent the dependency graph.
2019-11-27 13:48:00 -05:00
dependencies = [
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
"fixedbitset",
"indexmap",
Cargo.toml: Add petgraph This will be used to represent the dependency graph.
2019-11-27 13:48:00 -05:00
]
tamer/Cargo.toml: Add quick_xml
2019-11-27 09:16:00 -05:00
[[package]]
name = "quick-xml"
tamer: xir::XirString: WIP implementation (likely going away) I'm not fond of this implementation, which is why it's not fully completed. I wanted to commit this for future reference, and take the opportunity to explain why I don't like it. First: this task started as an idea to implement a third variant to AttrValue and friends that indicates that a value is fixed, in the sense of a fixed-point function: escaped or unescaped, its value is the same. This would allow us to skip wasteful escape/unescape operations. In doing so, it became obvious that there's no need to leak this information through the API, and indeed, no part of the system should care. When we read XML, it should be unescaped, and when we write, it should be escaped. The reason that this didn't quite happen to begin with was an optimization: I'll be creating an echo writer in place of the current filesystem-based copy in tamec shortly, and this would allow streaming XIR directly from the reader to the writer without any unescaping or re-escaping. When we unescape, we know the value that it came from, so we could simply store both symbols---they're 32-bit, so it results in a nicely compressed 64-bit value, so it's essentially cost-free, as long as we accept the expense of internment. This is `XirString`. Then, when we want to escape or unescape, we first check to see whether a symbol already exists and, if so, use it. While this works well for echoing streams, it won't work all that well in practice: the unescaped SymbolId will be taken and the XirString discarded, since nothing after XIR should be coupled with it. Then, when we later construct a XIR stream for writting, XirString will no longer be available and our previously known escape is lost, so the writer will have to re-escape. Further, if we look at XirString's generic for the XirStringEscaper---it uses phantom, which hints that maybe it's not in the best place. Indeed, I've already acknowledged that only a reader unescapes and only a writer escapes, and that the rest of the system works with normal (unescaped) values, so only readers and writers should be part of this process. I also already acknowledged that XirString would be lost and only the unescaped SymbolId would be used. So what's the point of XirString, then, if it won't be a useful optimization beyond the temporary echo writer? Instead, we can take the XirStringWriter and implement two caches on that: mapping SymbolId from escaped->unescaped and vice-versa. These can be simple vectors, since SymbolId is a 32-bit value we will not have much wasted space for symbols that never get read or written. We could even optimize for preinterned symbols using markers, though I'll probably not do so, and I'll explain why later. If we do _that_, we get even _better_ optimizations through caching that _will_ apply in the general case (so, not just for echo), and we're able to ditch XirString entirely and simply use a SymbolId. This makes for a much more friendly API that isn't leaking implementation details, though it _does_ put an onus on the caller to pass the encoder to both the reader and the writer, _if_ it wants to take advantage of a cache. But that burden is not significant (and is, again, optional if we don't want it). So, that'll be the next step.
2021-11-10 09:42:18 -05:00
version = "0.23.0-alpha3"
tamer/Cargo.toml: Add quick_xml
2019-11-27 09:16:00 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: xir::XirString: WIP implementation (likely going away) I'm not fond of this implementation, which is why it's not fully completed. I wanted to commit this for future reference, and take the opportunity to explain why I don't like it. First: this task started as an idea to implement a third variant to AttrValue and friends that indicates that a value is fixed, in the sense of a fixed-point function: escaped or unescaped, its value is the same. This would allow us to skip wasteful escape/unescape operations. In doing so, it became obvious that there's no need to leak this information through the API, and indeed, no part of the system should care. When we read XML, it should be unescaped, and when we write, it should be escaped. The reason that this didn't quite happen to begin with was an optimization: I'll be creating an echo writer in place of the current filesystem-based copy in tamec shortly, and this would allow streaming XIR directly from the reader to the writer without any unescaping or re-escaping. When we unescape, we know the value that it came from, so we could simply store both symbols---they're 32-bit, so it results in a nicely compressed 64-bit value, so it's essentially cost-free, as long as we accept the expense of internment. This is `XirString`. Then, when we want to escape or unescape, we first check to see whether a symbol already exists and, if so, use it. While this works well for echoing streams, it won't work all that well in practice: the unescaped SymbolId will be taken and the XirString discarded, since nothing after XIR should be coupled with it. Then, when we later construct a XIR stream for writting, XirString will no longer be available and our previously known escape is lost, so the writer will have to re-escape. Further, if we look at XirString's generic for the XirStringEscaper---it uses phantom, which hints that maybe it's not in the best place. Indeed, I've already acknowledged that only a reader unescapes and only a writer escapes, and that the rest of the system works with normal (unescaped) values, so only readers and writers should be part of this process. I also already acknowledged that XirString would be lost and only the unescaped SymbolId would be used. So what's the point of XirString, then, if it won't be a useful optimization beyond the temporary echo writer? Instead, we can take the XirStringWriter and implement two caches on that: mapping SymbolId from escaped->unescaped and vice-versa. These can be simple vectors, since SymbolId is a 32-bit value we will not have much wasted space for symbols that never get read or written. We could even optimize for preinterned symbols using markers, though I'll probably not do so, and I'll explain why later. If we do _that_, we get even _better_ optimizations through caching that _will_ apply in the general case (so, not just for echo), and we're able to ditch XirString entirely and simply use a SymbolId. This makes for a much more friendly API that isn't leaking implementation details, though it _does_ put an onus on the caller to pass the encoder to both the reader and the writer, _if_ it wants to take advantage of a cache. But that burden is not significant (and is, again, optional if we don't want it). So, that'll be the next step.
2021-11-10 09:42:18 -05:00
checksum = "e6c002cfafa1de674ef8557e3dbf2ad8c03ac8eb3d162672411b1b7fb4d272ef"
tamer/Cargo.toml: Add quick_xml
2019-11-27 09:16:00 -05:00
dependencies = [
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
"memchr",
tamer/Cargo.toml: Add quick_xml
2019-11-27 09:16:00 -05:00
]
tamer: Remove default SymbolIndex (et al) index type Oh boy. What a mess of a change. This demonstrates some significant issues we have with Symbol. I had originally modelled the system a bit after Rustc's, but deviated in certain regards: 1. This has a confurable base type to enable better packing without bit twiddling and potentially unsafe tricks I'd rather avoid unless necessary; and 2. The lifetime is not static, and there is no global, singleton interner; and 3. I pass around references to a Symbol rather than passing around an index into an interner. For #3---this is done because there's no singleton interner and therefore resolving a symbol requires a direct reference to an available interner. It also wasn't clear to me (and still isn't, in fact) whether more than one interner may be used for different contexts. But, that doesn't preclude removing lifetimes and just passing around indexes; in fact, I plan to do this in the frontend where the parser and such will have direct interner access and can therefore just look up based on a symbol index. We could reserve references for situations where exposing an interner would be undesirable. Anyway, more to come...
2021-07-29 14:26:40 -04:00
[[package]]
name = "static_assertions"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a2eb9349b6444b326872e140eb1cf5e7c522154d69e7a0ffb0fb81c06b37543f"
TAMER: Initial commit
2019-11-14 16:43:07 -05:00
[[package]]
name = "tamer"
version = "0.0.0"
tamer/Cargo.toml: Add quick_xml
2019-11-27 09:16:00 -05:00
dependencies = [
tamer: Start of XIR-based xmle writer This has been a long time coming, and has been repeatedly stashed as other parts of the system have evolved to support it. The introduction of the XIR tree was to write tests for this (which are sloppy atm). This currently writes out the `xmle` header and _most_ of the `l:dep` section; it's missing the object-type-specific attributes. There is, relatively speaking, not much more work to do here. The feature flag `wip-xir-xmle-writer` was introduced to toggle this system in place of `XmleWriter`. Initial benchmarks show that it will be competitive with the quick-xml-based writer, but remember that is not the goal: the purpose of this is to test XIR in a production system before we continue to implement it for a frontend, and to refactor so that we do not have multiple implementations writing XML files (once we echo the source XML files). I'm excited to get this done with so that I can move on. This has been rather exhausting.
2021-09-28 14:52:31 -04:00
"arrayvec",
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
"bumpalo",
"exitcode",
"fxhash",
"getopts",
tamer: memchr benches This adds benchmarking for the memchr crate. It is used primarily by quick-xml at the moment, but the question is whether to rely on it for certain operations for XIR. The benchmarking on an Intel Xeon system shows that memchr and Rust's contains() perform very similarly on small inputs, matching against a single character, and so Rust's built-in should be preferred in that case so that we're using APIs that are familiar to most people. When larger inputs are compared against, there's a greater benefit (a little under ~2x). When comparing against two characters, they are again very close. But look at when we compare two characters against _multiple_ inputs: running 24 tests test large_str::one::memchr_early_match ... bench: 4,938 ns/iter (+/- 124) test large_str::one::memchr_late_match ... bench: 81,807 ns/iter (+/- 1,153) test large_str::one::memchr_non_match ... bench: 82,074 ns/iter (+/- 1,062) test large_str::one::rust_contains_one_byte_early_match ... bench: 9,425 ns/iter (+/- 167) test large_str::one::rust_contains_one_byte_late_match ... bench: 123,685 ns/iter (+/- 3,728) test large_str::one::rust_contains_one_byte_non_match ... bench: 123,117 ns/iter (+/- 2,200) test large_str::one::rust_contains_one_char_early_match ... bench: 9,561 ns/iter (+/- 507) test large_str::one::rust_contains_one_char_late_match ... bench: 123,929 ns/iter (+/- 2,377) test large_str::one::rust_contains_one_char_non_match ... bench: 122,989 ns/iter (+/- 2,788) test large_str::two::memchr2_early_match ... bench: 5,704 ns/iter (+/- 91) test large_str::two::memchr2_late_match ... bench: 89,194 ns/iter (+/- 8,546) test large_str::two::memchr2_non_match ... bench: 85,649 ns/iter (+/- 3,879) test large_str::two::rust_contains_two_char_early_match ... bench: 66,785 ns/iter (+/- 3,385) test large_str::two::rust_contains_two_char_late_match ... bench: 2,148,064 ns/iter (+/- 21,812) test large_str::two::rust_contains_two_char_non_match ... bench: 2,322,082 ns/iter (+/- 22,947) test small_str::one::memchr_mid_match ... bench: 4,737 ns/iter (+/- 842) test small_str::one::memchr_non_match ... bench: 5,160 ns/iter (+/- 62) test small_str::one::rust_contains_one_byte_non_match ... bench: 3,930 ns/iter (+/- 35) test small_str::one::rust_contains_one_char_mid_match ... bench: 3,677 ns/iter (+/- 618) test small_str::one::rust_contains_one_char_non_match ... bench: 5,415 ns/iter (+/- 221) test small_str::two::memchr2_mid_match ... bench: 5,488 ns/iter (+/- 888) test small_str::two::memchr2_non_match ... bench: 6,788 ns/iter (+/- 134) test small_str::two::rust_contains_two_char_mid_match ... bench: 6,203 ns/iter (+/- 170) test small_str::two::rust_contains_two_char_non_match ... bench: 7,853 ns/iter (+/- 713) Yikes. With that said, we won't be comparing against such large inputs short-term. The larger strings (fragments) are copied verbatim, and not compared against---but they _were_ prior to the previous commit that stopped unencoding and re-encoding. So: Rust built-ins for inputs that are expected to be small.
2021-08-18 14:18:24 -04:00
"memchr",
tamer: ir::asg::ident: AsRef impls for SymbolId types This commit will make more sense once the broader context is committed, but it's needed for lowering from `Sections` into a XIR stream. This will also change once we pre-allocate symbols, like rustc, when the interner is initialized. This is my first use of the `paste` crate, which is used to generate identifiers. So this is partly an experiment, and it seems much better than having to write a proc macro, at least at this point in time. If this code stays around, it'll probably be generalized further and used elsewhere, but I'd prefer not to go this route long-term.
2021-09-20 16:46:16 -04:00
"paste",
tamer: Cargo.lock: Dependency updates This project has been on pause for over a year.
2021-06-21 12:46:38 -04:00
"petgraph",
"quick-xml",
tamer: Remove default SymbolIndex (et al) index type Oh boy. What a mess of a change. This demonstrates some significant issues we have with Symbol. I had originally modelled the system a bit after Rustc's, but deviated in certain regards: 1. This has a confurable base type to enable better packing without bit twiddling and potentially unsafe tricks I'd rather avoid unless necessary; and 2. The lifetime is not static, and there is no global, singleton interner; and 3. I pass around references to a Symbol rather than passing around an index into an interner. For #3---this is done because there's no singleton interner and therefore resolving a symbol requires a direct reference to an available interner. It also wasn't clear to me (and still isn't, in fact) whether more than one interner may be used for different contexts. But, that doesn't preclude removing lifetimes and just passing around indexes; in fact, I plan to do this in the frontend where the parser and such will have direct interner access and can therefore just look up based on a symbol index. We could reserve references for situations where exposing an interner would be undesirable. Anyway, more to come...
2021-07-29 14:26:40 -04:00
"static_assertions",
tamer: diagnostic: Column resolution Determining the column number is not as simple as performing byte arithmetic, because certain characters have different widths. Even if we only accepted ASCII, control characters aren't visible to the user. This uses the unicode-width crate as an alternative to POSIX wcwidth, to determine (hopefully) the number of fixed-width cells that a unicode character will take up on a terminal. For example, control characters are zero-width, while an emoji is likely double-width. See test cases for more information on that. There is also the unicode-segmentation crate, which can handle extended grapheme clusters and such, but (a) we'll be outputting the line to the terminal and (b) there's no guarantee that the user's editor displays grapheme clusters as a single column. LSP measures in UTF-16, apparently. I use both Emacs and Vim from a terminal, so unicode-width applies to me. There's too much variation to try to solve that right now. The columns can be considered a visual span---this gives us enough information to draw line annotations, which will happen soon. Here are some useful links: - https://hsivonen.fi/string-length/ - https://unicode.org/reports/tr29/ - https://github.com/rust-analyzer/rowan/issues/17 - https://www.reddit.com/r/rust/comments/gpw2ra/how_is_the_rust_compiler_able_to_tell_the_visible/ DEV-10935
2022-04-21 14:16:21 -04:00
"unicode-width",
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
]
[[package]]
name = "unicode-width"
tamer: Remove tests invoking cargo and associated libs There are a number of reasons for this, where the benefits do not make up for the losses. First: this is actually invoking cargo. Not only is this not necessary, but it's not desirable: cargo by default hits the network and does all sorts of other stuff, when all we want to do is invoke the executable. So the tests aren't really testing the right thing in that sense. See the previous commit for more information. The way it invokes cargo is different than the way the Makefile invokes cargo, so on my system, it's actually invoking a _different cargo_! This is causing problems, in particular with lock files, which causes my tests to fail. Importantly, this also removes a _lot_ of dependencies, which removes a lot of supplier chain risk and a lot of code to audit. This provides significant security benefits, especially given that what was being tested was rather small, and could be done in a shell script. TAMER will receive significant system testing later on. But for now, none of this was worth it. Further audits of dependencies will come later on. I've always been fairly insistent on keeping the dependency graph small and auditable, but recent supply chain attacks have given me a better way to rationalize the security risk. Further, I'm the only one on this project right now.
2021-12-02 12:32:56 -05:00
version = "0.1.9"
[DEV-7081] Add options to tameld We want to add an option to set the output file to the linker so we do not need to redirect output to awk any longer. This also adds integration tests for tameld.
2020-03-04 15:31:20 -05:00
source = "registry+https://github.com/rust-lang/crates.io-index"
tamer: Remove tests invoking cargo and associated libs There are a number of reasons for this, where the benefits do not make up for the losses. First: this is actually invoking cargo. Not only is this not necessary, but it's not desirable: cargo by default hits the network and does all sorts of other stuff, when all we want to do is invoke the executable. So the tests aren't really testing the right thing in that sense. See the previous commit for more information. The way it invokes cargo is different than the way the Makefile invokes cargo, so on my system, it's actually invoking a _different cargo_! This is causing problems, in particular with lock files, which causes my tests to fail. Importantly, this also removes a _lot_ of dependencies, which removes a lot of supplier chain risk and a lot of code to audit. This provides significant security benefits, especially given that what was being tested was rather small, and could be done in a shell script. TAMER will receive significant system testing later on. But for now, none of this was worth it. Further audits of dependencies will come later on. I've always been fairly insistent on keeping the dependency graph small and auditable, but recent supply chain attacks have given me a better way to rationalize the security risk. Further, I'm the only one on this project right now.
2021-12-02 12:32:56 -05:00
checksum = "3ed742d4ea2bd1176e236172c8429aaf54486e7ac098db29ffe6529e0ce50973"