A week? Might make sense to refactor, or just clone the data? Or ask the subreddit, discord, or whatever place you want for help.
I haven't run into a borrowchecker issue that took me more than a few seconds in a few years. The trick is I'm not crazy about avoiding cloning - Rust is still super fast. The curse of Rust making cloning explicit, and move by default being cheap/ memcopy, is that you often feel like "if only I could express it" and that problem seems to get worse the better you are, and then for me I hit a point where I stopped caring and just got shit done.
It's easy to remove clones later in my experience, once benchmarks show it matters.
Rust has one curse (it has many, but this one is critical): inefficient code is generally visible. Experienced developers hate to notice that their code is inefficient. They will balk at seeing `Arc<RefCell<T>>`, but won't bat an eye at using Python. I know because I have the same instinct! This makes it much harder to learn Rust for experienced devs because they go from the "simple code that will work but is slightly inefficient" and in an effort to improve it they land squarely in parts of the language they haven't yet developed a mental model for.
The most important mental model to develop is a model of what can and cannot be feasibly optimized. Sometimes there really is no alternative to stuff like Rc<RefCell<>>, Arc<RwLock<>> or Arc<Mutex<>> - because you'll be working with pieces of data that have to be mutated from multiple places, and don't even have a well-defined lifetime so have to be reference counted. In that case, you should write a comment to that effect and move on. It's still good to see that RefCell<> and the like, because shared mutability is known to be a source of logical bugs. It's a bit like a low-key `unsafe`.
Yes, a week (no shame, damnit). The case was that I couldn't understand what the problem even was. I understood that there can be only one owner, but I didn't see how what I was doing was a problem. I literally looked at every error message it gave me and was like "so what?"
I think Rust initially suggested I implement the Copy trait or something, and so I had to brush up on traits and all that (which I did), only to find that my types can't have traits because vec<T> doesn't implement the Copy trait. So I abandoned that.
The problem turned out to be that I needed a minor refactoring. I think the issue eventually turned out to be that I was mutably iterating through a list reading from TCPStreams, and then trying to write back to those streams. So it was like a read_object_from_stream(stream) on each element in a vector, and then the next line was a broadcast_to_all_streams(message) (I'm psuedocoding).
The fix for me (when I finally came to understand what was happening) was to read_object_from_stream(stream) in to an intermediary vector (I named it cache), and THEN iterate through the intermediary and broadcast each item.
In my notes I paraphrased it as "Instead of doing a readwrite, I separated my algorithm in to a READ and then a separate WRITE", because the way things were written I was double borrowing.
I haven't run into a borrowchecker issue that took me more than a few seconds in a few years. The trick is I'm not crazy about avoiding cloning - Rust is still super fast. The curse of Rust making cloning explicit, and move by default being cheap/ memcopy, is that you often feel like "if only I could express it" and that problem seems to get worse the better you are, and then for me I hit a point where I stopped caring and just got shit done.
It's easy to remove clones later in my experience, once benchmarks show it matters.