Giter VIP home page Giter VIP logo

lasso's People

Contributors

1011x avatar andrew-rj avatar coastalwhite avatar domenicquirl avatar jameysharp avatar jonas-schievink avatar jyn514 avatar kixiron avatar nerosnm avatar nhwn avatar paolobarbolini avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

lasso's Issues

Rodeo memory use is at least twice the theoretical requirement

(I wrote a comparison of memory usage of different interners. This issue is suggesting some improvements from my own interner implementation that are the cause of the nearly 3x memory usage difference.) You've quoted memory footprint as a key feature of lasso, so I thought you'd be interested to see my analysis. I've not actually measured performance characteristics of any of these tweaks, just the memory usage patterns.

The current definition of the (single threaded) Rodeo is roughly (degenericized)

struct Rodeo {
    arena: Arena<u8>,
    string_to_spur: HashMap<&'self.arena [u8], Spur>,
    spur_to_string: Vec<&'self.arena [u8]>,
}

When using the raw_entry API, the size of the str -> Spur map can be cut at least to a third by instead storing (effectively) HashSet<Spur> (though for raw_entry it's a HashMap<Spur, ()>) and using raw_entry to compare the Spur entries as if they were the string they map to. The cost for this memory saving is an extra indirection involved in hashing/comparing entries in the map (for any str -> Spur conversions).

There is also a further optimization potential for the Spur -> str map. There are two potential options here:

  1. Reduce memory usage of the map by about 25%. Instead of storing the &[u8] directly in the vector, store indexes into the arena. IIUC, these would minimally be { bucket_idx: u32, start_idx: u32, end_idx: u32 } for the current arena. (In my own crate, it's just (u32, u32) as the arena is a single contiguous allocation; however, I believe the less-copies arena approach you have here to probably be significantly better for tail-latency.) The cost would be extra indirection both on Spur -> str lookups and on str -> Spur lookups if the above change to that map is used.

  2. Allow interning of real &'static str in the interner without copying them into internal storage. With a direct Spur -> str map that doesn't go indirect through the arena, this is trivial to support; just put the &'static str into the map. And interning of statically known strings is a surprisingly common and useful thing to be able to do; most contexts that benefit from an interner have some set of known names they know they'll always use and already have baked into the binary's static data section in order to treat them specially. (Here's rustc's list!)

If lasso can incorporate even just the first size optimization for the Spur -> str map, even if just with the hashbrown feature, I'd feel a lot more comfortable recommending lasso instead of maintaining my own interner.

Possible race condition in ThreadedRodeo

Hi,

Really appreciate this great library! I've encountered a small issue, which I believe could be a race condition in ThreadedRodeo.

It is located in https://github.com/Kixiron/lasso/blob/master/src/multi_threaded.rs#L341-L342

self.map.insert(string, key);
self.strings.insert(key, string);

Suppose a new string is being interned by two threads running at the same time, then the if at line 331 (shard.read().get(...)) would return None for both threads. Both threads continue to line 341, one will call self.map.insert() which will write the string into the map, the second thread would do the same, overwriting the value from the first thread.

This would then create a situation where two Spurs could exist that resolve to identical strings, but not be equal to each other because their keys are different.

One option to address this would be to lock the shard for the duration as we insert into the arena and increment the key. If we would like to avoid locking for that long, perhaps checking the return value from self.map.insert(...) would help, as we can verify that we already added that string in, and just return its key, but then we would need to undo the other operations, and it doesn't seem possible to remove strings from the arena. This way we may end up using slightly more memory and keys than actually needed (which is already the case in this scenario), but at the very least, the Spur equality property would be maintained.

`raw_entry_mut` to speed up `try_get_or_intern`?

To my knowledge dashmap can't do dat, but on nightly std's hash map and hashbrown on stable can. What this allows you to do is performing a single hash map look-up, no matter whether the input is already interned or needs to be stored.

The big downside is more complicated code, especially with some feature cfgs for nightly, and, well, this only being an optimisation for the ST interner. So all this may be considered »not worth it«.

Allocation failures due to enormous (many TB) allocation attempts

We've been using ThreadedRodeo in production for a while to implement a global string interner. For the most part it works great, but recently when we increased the concurrency of our workload from 10 CPUs to 64 CPUs we started seeing sporadic allocation failures, due to attempts to mmap between 2 TB and a few PB. And even when there isn't a crash, we had absurdly high virtual memory usage, commonly 50 GB of resident set size would come with 2 TB virtual memory usage.

I believe the root cause is that lasso is missing some synchronization in its lockfree allocation strategy. Or alternatively, that the entire design of this lockfree allocation is not viable. The memory for ThreadedRodeo strings in the 0.7 release series is allocated in a lock-free strategy using a linked list of AtomicBucket. This is the responsible code:

// Check that we haven't exhausted our memory limit
self.allocate_memory(next_capacity)?;
// Set the capacity to twice of what it currently is to allow for fewer allocations as more strings are interned
self.set_bucket_capacity(next_capacity);
// Safety: `next_capacity` will never be zero
let capacity = unsafe { NonZeroUsize::new_unchecked(next_capacity) };
debug_assert_ne!(next_capacity, 0);
let mut bucket = AtomicBucket::with_capacity(capacity)?;
// Safety: The new bucket will have enough room for the string
let allocated_string = unsafe { bucket.push_slice(slice) };
self.buckets.push_front(bucket.into_ref());
Ok(allocated_string)

The ideal behavior of this data structure is for one thread to get here at a time, double the capacity, then stick its allocated slab onto the linked list. But if many threads race to this point in the code, they will not realize that there is another thread allocating (that's the whole point!) and they will double the size in sequence and allocate that doubled size.

If 64 threads race on this code in perfect synchrony, this would attempt to allocate more than the entire address space.

We've worked around this for now by forking lasso and back-porting some changes from 0.7.2 onto 0.6.0.

Regression in 0.3.0: The same string is interned differently

Hello,

I've recently come across a very interesting case that seems to cause the interner to give different indices for the same string interned twice.

This is a regression from 0.2.0 to 0.3.0.

I have reduced the case to

use lasso::Rodeo;

fn main() {
    let mut rodeo = Rodeo::default();

    rodeo.get_or_intern("a");
    rodeo.get_or_intern("b");
    rodeo.get_or_intern("c");
    rodeo.get_or_intern("d");
    rodeo.get_or_intern("e");
    rodeo.get_or_intern("f");
    rodeo.get_or_intern("g");
    rodeo.get_or_intern("h");
    rodeo.get_or_intern("i");
    rodeo.get_or_intern("j");
    rodeo.get_or_intern("k");
    rodeo.get_or_intern("l");
    rodeo.get_or_intern("m");
    rodeo.get_or_intern("n");
    rodeo.get_or_intern("o");
    rodeo.get_or_intern("p");
    rodeo.get_or_intern("q");
    rodeo.get_or_intern("r");
    rodeo.get_or_intern("s");
    rodeo.get_or_intern("t");
    rodeo.get_or_intern("u");
    rodeo.get_or_intern("v");
    rodeo.get_or_intern("w");
    rodeo.get_or_intern("x");
    rodeo.get_or_intern("y");
    rodeo.get_or_intern("z");
    rodeo.get_or_intern("aa");
    rodeo.get_or_intern("bb");
    rodeo.get_or_intern("cc");
    rodeo.get_or_intern("dd");
    rodeo.get_or_intern("ee");
    rodeo.get_or_intern("ff");
    rodeo.get_or_intern("gg");
    rodeo.get_or_intern("hh");
    rodeo.get_or_intern("ii");
    rodeo.get_or_intern("jj");
    rodeo.get_or_intern("kk");
    rodeo.get_or_intern("ll");
    rodeo.get_or_intern("mm");
    rodeo.get_or_intern("nn");
    rodeo.get_or_intern("oo");
    rodeo.get_or_intern("pp");
    rodeo.get_or_intern("qq");
    rodeo.get_or_intern("rr");
    rodeo.get_or_intern("ss");
    rodeo.get_or_intern("tt");
    rodeo.get_or_intern("uu");
    rodeo.get_or_intern("vv");
    rodeo.get_or_intern("ww");
    rodeo.get_or_intern("xx");
    rodeo.get_or_intern("yy");
    rodeo.get_or_intern("zz");
    rodeo.get_or_intern("aaa");
    rodeo.get_or_intern("bbb");
    rodeo.get_or_intern("ccc");

    let var = rodeo.get_or_intern("ddd");

    rodeo.get_or_intern("eee");

    dbg!(var, rodeo.get_or_intern("ddd"));
}
[dependencies]
lasso = "0.3.0"

The output that I see from this is

[src/main.rs:66] var = Spur {
    key: 56,
}
[src/main.rs:66] rodeo.get_or_intern("ddd") = Spur {
    key: 58,
}

LockfreeArena::store_str contains a data race

This simple stress test encounters a data race:

use std::sync::Arc;
use rand::{SeedableRng, Rng};
use rand::rngs::SmallRng;

fn main() {
    let rodeo: Arc<lasso::ThreadedRodeo<lasso::Spur>> = Arc::new(lasso::ThreadedRodeo::new());
    let mut threads = Vec::new();
    for _ in 0..64 {
        let rodeo = Arc::clone(&rodeo);
        let handle = std::thread::spawn(move || {
            let mut rng = SmallRng::from_entropy();
            for _ in 0..1_000 {
                rodeo.get_or_intern(rng.gen::<u64>().to_string());
            }
        });
        threads.push(handle);
    }
    for t in threads {
        t.join().unwrap();
    }
}

Miri says:


error: Undefined Behavior: Data race detected between (1) Read on thread `<unnamed>` and (2) Write on thread `<unnamed>` at alloc120819+0x8. (2) just happened here
   --> /home/ben/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lasso-0.7.0/src/arenas/atomic_bucket.rs:178:13
    |
178 |             addr_of_mut!((*self.as_ptr()).len).write(new_length);
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data race detected between (1) Read on thread `<unnamed>` and (2) Write on thread `<unnamed>` at alloc120819+0x8. (2) just happened here
    |
help: and (1) occurred earlier here
   --> src/main.rs:13:17
    |
13  |                 rodeo.get_or_intern(rng.gen::<u64>().to_string());
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = note: BACKTRACE (of the first span):
    = note: inside `lasso::arenas::atomic_bucket::UniqueBucketRef::set_len` at /home/ben/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lasso-0.7.0/src/arenas/atomic_bucket.rs:178:13: 178:65
    = note: inside `lasso::arenas::atomic_bucket::UniqueBucketRef::push_slice` at /home/ben/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lasso-0.7.0/src/arenas/atomic_bucket.rs:212:18: 212:49
    = note: inside `lasso::arenas::lockfree::LockfreeArena::store_str` at /home/ben/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lasso-0.7.0/src/arenas/lockfree.rs:121:46: 121:70
    = note: inside `lasso::ThreadedRodeo::try_get_or_intern::<std::string::String>` at /home/ben/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lasso-0.7.0/src/threaded_rodeo.rs:322:49: 322:83
    = note: inside `lasso::ThreadedRodeo::get_or_intern::<std::string::String>` at /home/ben/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lasso-0.7.0/src/threaded_rodeo.rs:289:9: 289:36
note: inside closure
   --> src/main.rs:13:17
    |
13  |                 rodeo.get_or_intern(rng.gen::<u64>().to_string());
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to previous error; 1 warning emitted

Outside of Miri, this readily manifests as an infinite loop or a panic.

Implement FromIterator

string_interner uses FromIterator to allow this example:

let interner = vec!["Elephant", "Tiger", "Horse", "Tiger"]
    .into_iter()
    .collect::<StringInterner>();

Would be nice to do the same with no boilerplate using lasso!

A few bits I noticed in 72a56a7 (clean code + perf)

https://github.com/Kixiron/lasso/tree/72a56a76564493d7e191bb46b0f53034452ecd99

  • Arena allocator for the strings to fragment heap memory less?
    • Capacity would then relate to spare bytes in the current arena allocator chunk.
    • You could use the typed-arena crate. Has good code.
  • NonZeroUsize::new(int + 1).unwrap_or_else(|| { can just be a new_unchecked call.
  • You can blanket-implement from_usize for all Keys by just expecting try_from_usize.

Other than that code's lookin' good. °^°b

`Default` trait is not implemented for rodeo with spur types other than `Spur`

I tried this code

#[derive(Default)]
struct Foo {
    strings: Rodeo<lasso::MiniSpur>,
}

I expected this to happen

The code compiles.

Instead this happened

This does not compile.
Compiler says error[E0277]: the trait bound `lasso::Rodeo<lasso::MiniSpur>: std::default::Default` is not satisfied.

Meta

Lasso version: 0.5.0

Rustc version: 1.52.0

> rustc -Vv
rustc 1.52.0 (88f19c6da 2021-05-03)
binary: rustc
commit-hash: 88f19c6dab716c6281af7602e30f413e809c5974
commit-date: 2021-05-03
host: x86_64-unknown-linux-gnu
release: 1.52.0
LLVM version: 12.0.0

Additional context

impl Default for Rodeo<Spur, RandomState> redirects to Self::new(), and Self::new() is implemented for any Rodeo<K, RandomState> where K: Key.
Is there any reason not to implement impl<K: Key> Default for Rodeo<K, RandomState>?

impl Index<Key> for Rodeo

Indexing an interner by key seems very convenient. Unfortunately none of the Rodeo family of types currently allow for that. I propose that for each of the Rodeo types:

  1. rodeo[key] replace the behavior of rodeo.resolve(key),
  2. rodeo.resolve(key) replace the behavior of rodeo.try_resolve(key),
  3. rodeo.try_resolve() be deprecated.

Obviously (2) will result in an API breaking change. This shouldn't be an issue since lasso is still pre-v1.0.0, but if avoiding this is desired, there are other options. In addition to (1), we could:

  • leave .try_resolve() and deprecate .resolve() (unnecessarily wordy; inconsistent naming),
  • leave both .try_resolve() and .resolve() (there's now more than one way of doing something).

I'm not completely happy with either of these alternative solutions, but then again, I don't even use lasso (yet) so perhaps consideration should be placed on its users rather than my API preferences.

`Clone` implementation?

Hello, I noticed that Rodeo doesn't have a Clone impl. Is there a reason for this? (Just out of curiosity; it won't be too hard to work around it.)

Files with spaces break bazel

Hello,

There are 2 files that spaces in the name: Before Release.md, and To Do.md.

Those 2 break rust bazel projects that use lasso.

Will you consider a PR to fix this?

Feature request: Update to new hashbrown version to avoid duplicated dependencies

There is a new semver version of hashbrown. It would be nice to get a new release of lasso that uses it so we can avoid duplicate dependencies. From the output of cargo deny check:

45 │ ╭ hashbrown 0.13.2 registry+https://github.com/rust-lang/crates.io-index
46 │ │ hashbrown 0.14.3 registry+https://github.com/rust-lang/crates.io-index
   │ ╰──────────────────────────────────────────────────────────────────────^ lock entries
   │  
   = hashbrown v0.13.2
     └── lasso v0.7.2
         └── my_crate 0.1.0
   = hashbrown v0.14.3
     ├── dashmap v5.5.3
     │   └── lasso v0.7.2
     │       └── my_crate 0.1.0
     └── ordered-multimap v0.7.1
         └── rust-ini v0.20.0
             └── my_crate 0.1.0

As can be seen, lasso on it's own (with the multi-threaded feature) is enough to pull in two versions thanks to dashmap depending on the newer version. Other libraries that I use (like rust-ini) also pulls in the newer version.

serialize+multi-threaded feature combination doesn't compile

When I try to use both features I get the following compile error:

   Compiling lasso v0.6.0
error[E0599]: no function or associated item named `deserialize` found for struct `Vec<_, _>` in the current scope
   --> /home/xxxxx/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.6.0/src/reader.rs:423:40
    |
423 |         let vector: Vec<String> = Vec::deserialize(deserializer)?;
    |                                        ^^^^^^^^^^^ function or associated item not found in `Vec<_, _>`

error[E0599]: no function or associated item named `deserialize` found for struct `Vec<_, _>` in the current scope
   --> /home/xxxxx/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.6.0/src/resolver.rs:305:40
    |
305 |         let vector: Vec<String> = Vec::deserialize(deserializer)?;
    |                                        ^^^^^^^^^^^ function or associated item not found in `Vec<_, _>`

error[E0599]: no function or associated item named `deserialize` found for struct `Vec<_, _>` in the current scope
   --> /home/xxxxx/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.6.0/src/single_threaded.rs:928:40
    |
928 |         let vector: Vec<String> = Vec::deserialize(deserializer)?;
    |                                        ^^^^^^^^^^^ function or associated item not found in `Vec<_, _>`

error[E0277]: the trait bound `String: Deserialize<'_>` is not satisfied
   --> /home/xxxxx/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.6.0/src/multi_threaded.rs:963:45
    |
963 |         let deser_map: HashMap<String, K> = HashMap::deserialize(deserializer)?;
    |                                             ^^^^^^^^^^^^^^^^^^^^ the trait `Deserialize<'_>` is not implemented for `String`
    |
    = help: the trait `Deserialize<'de>` is implemented for `&'a str`
    = note: required for `hashbrown::HashMap<String, K>` to implement `Deserialize<'_>`

Some errors have detailed explanations: E0277, E0599.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `lasso` due to 4 previous errors

Compilation exited abnormally with code 101 at Tue Nov 15 14:06:59

Deadlock / panics for multi-threading in 0.7.0

Hi, just used lasso for the first time and I was getting deadlocks and panics inside of DashMap - had no idea what I was doing wrong. After like an hour of debugging I noticed that 0.7.0 just came out a week ago so on a hunch I tried 0.6.0 - deadlocks and panics went away!

If it helps here's the panic trace:

   0: std::panicking::begin_panic_handler
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library\std\src\panicking.rs:577
   1: core::panicking::panic_fmt
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library\core\src\panicking.rs:67
   2: core::panicking::panic
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library\core\src\panicking.rs:117
   3: dashmap::mapref::entry::VacantEntry<ref$<str$>,lasso::keys::Spur,ahash::random_state::RandomState>::insert<ref$<str$>,lasso::keys::Spur,ahash::random_state::RandomState>
             at C:\Users\Andy\.cargo\registry\src\index.crates.io-6f17d22bba15001f\dashmap-5.4.0\src\mapref\entry.rs:106
   4: enum2$<dashmap::mapref::entry::Entry<ref$<str$>,lasso::keys::Spur,ahash::random_state::RandomState> >::or_try_insert_with
             at C:\Users\Andy\.cargo\registry\src\index.crates.io-6f17d22bba15001f\dashmap-5.4.0\src\mapref\entry.rs:82
   5: lasso::threaded_rodeo::ThreadedRodeo<lasso::keys::Spur,ahash::random_state::RandomState>::try_get_or_intern
             at C:\Users\Andy\.cargo\registry\src\index.crates.io-6f17d22bba15001f\lasso-0.7.0\src\threaded_rodeo.rs:329
   6: lasso::threaded_rodeo::ThreadedRodeo<lasso::keys::Spur,ahash::random_state::RandomState>::get_or_intern<lasso::keys::Spur,ahash::random_state::RandomState,ref$<str$> >
             at C:\Users\Andy\.cargo\registry\src\index.crates.io-6f17d22bba15001f\lasso-0.7.0\src\threaded_rodeo.rs:289

Compilation failure on nightly rust

I tried this code

Nightly: nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.78.0-nightly (4a0cc881d 2024-03-11)

cargo +nightly check -F serialize

Results in compilation error:

error[E0275]: overflow evaluating the requirement `&_ well-formed`
   --> src/util.rs:445:13
    |
445 |             $slice[$idx]
    |             ^^^^^^^^^^^^
    |
   ::: src/reader.rs:453:49
    |
453 |                 let key_string: &str = unsafe { index_unchecked!(strings, key.into_usize()) };
    |                                                 ------------------------------------------- in this macro invocation
    |
    = note: this error originates in the macro `index_unchecked` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0275]: overflow evaluating the requirement `&_ well-formed`
    --> src/util.rs:445:13
     |
445  |             $slice[$idx]
     |             ^^^^^^^^^^^^
     |
    ::: src/rodeo.rs:1132:49
     |
1132 |                 let key_string: &str = unsafe { index_unchecked!(strings, key.into_usize()) };
     |                                                 ------------------------------------------- in this macro invocation
     |
     = note: this error originates in the macro `index_unchecked` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0275`.
warning: `lasso` (lib) generated 7 warnings
error: could not compile `lasso` (lib) due to 2 previous errors; 7 warnings emitted

Possibly related to #45, but a fix will be required for debug.

Issue producing a release build

Thaks for this nice library :) Here is the issue I am facing:

When producing a release build of a library using lasso 0.4 with the following dependencies

serde = { version = "1.0.114", features = ["derive"] }
serde_json = "1.0.56"
typetag = "0.1"
lasso = { version = "0.4", features = ["multi-threaded", "serialize"] }

During

cargo build --release

Following compilation errors appear

error[E0277]: the size for values of type `str` cannot be known at compilation time
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/util.rs:457:31
    |
457 |         let elem: &_ = $slice.get_unchecked($idx);
    |                               ^^^^^^^^^^^^^ doesn't have a size known at compile-time
    |
   ::: /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/reader.rs:455:49
    |
455 |                 let key_string: &str = unsafe { index_unchecked!(strings, key.into_usize()) };
    |                                                 ------------------------------------------- in this macro invocation
    |
    = help: the trait `std::marker::Sized` is not implemented for `str`
    = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the size for values of type `str` cannot be known at compilation time
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/reader.rs:433:27
    |
433 |         let mut strings = Vec::with_capacity(capacity.strings);
    |                           ^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `std::marker::Sized` is not implemented for `str`
    = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
    = note: required by `std::vec::Vec::<T>::with_capacity`

error[E0599]: no method named `push` found for struct `std::vec::Vec<str>` in the current scope
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/reader.rs:471:29
    |
471 |                     strings.push(allocated);
    |                             ^^^^ method not found in `std::vec::Vec<str>`
    |
    = note: the method `push` exists but the following trait bounds were not satisfied:
            `str: std::marker::Sized`

error[E0599]: no method named `get_unchecked` found for struct `std::vec::Vec<str>` in the current scope
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/util.rs:457:31
    |
457 |         let elem: &_ = $slice.get_unchecked($idx);
    |                               ^^^^^^^^^^^^^ method not found in `std::vec::Vec<str>`
    |
   ::: /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/reader.rs:476:38
    |
476 | ...                   unsafe { index_unchecked!(strings, key.into_usize()) };
    |                                ------------------------------------------- in this macro invocation
    |
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/reader.rs:490:13
    |
490 |             strings,
    |             ^^^^^^^ expected `&str`, found `str`
    |
    = note: expected struct `std::vec::Vec<&'static str>`
               found struct `std::vec::Vec<str>`

error[E0277]: the size for values of type `str` cannot be known at compilation time
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/util.rs:457:31
    |
457 |         let elem: &_ = $slice.get_unchecked($idx);
    |                               ^^^^^^^^^^^^^ doesn't have a size known at compile-time
    |
   ::: /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/single_threaded.rs:960:49
    |
960 |                 let key_string: &str = unsafe { index_unchecked!(strings, key.into_usize()) };
    |                                                 ------------------------------------------- in this macro invocation
    |
    = help: the trait `std::marker::Sized` is not implemented for `str`
    = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the size for values of type `str` cannot be known at compilation time
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/single_threaded.rs:938:27
    |
938 |         let mut strings = Vec::with_capacity(capacity.strings);
    |                           ^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `std::marker::Sized` is not implemented for `str`
    = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
    = note: required by `std::vec::Vec::<T>::with_capacity`

error[E0599]: no method named `push` found for struct `std::vec::Vec<str>` in the current scope
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/single_threaded.rs:976:29
    |
976 |                     strings.push(allocated);
    |                             ^^^^ method not found in `std::vec::Vec<str>`
    |
    = note: the method `push` exists but the following trait bounds were not satisfied:
            `str: std::marker::Sized`

error[E0599]: no method named `get_unchecked` found for struct `std::vec::Vec<str>` in the current scope
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/util.rs:457:31
    |
457 |         let elem: &_ = $slice.get_unchecked($idx);
    |                               ^^^^^^^^^^^^^ method not found in `std::vec::Vec<str>`
    |
   ::: /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/single_threaded.rs:981:38
    |
981 | ...                   unsafe { index_unchecked!(strings, key.into_usize()) };
    |                                ------------------------------------------- in this macro invocation
    |
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0308]: mismatched types
   --> /Users/pablomartinez/.cargo/registry/src/github.com-1ecc6299db9ec823/lasso-0.4.1/src/single_threaded.rs:995:13
    |
995 |             strings,
    |             ^^^^^^^ expected `&str`, found `str`
    |
    = note: expected struct `std::vec::Vec<&'static str>`
               found struct `std::vec::Vec<str>`

error: aborting due to 10 previous errors

Some errors have detailed explanations: E0277, E0308, E0599.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `lasso`.

The issue doesn't appear when producing a non release build. Ended moving to lasso 0.3.1 but the Key serializations isn't as nicer as in 0.4.1 :)

Thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.