BTreeMap: refactor Entry out of map.rs into its own file

[exrook]

btree/map.rs is approaching the 3000 line mark, splitting out the entry
code buys about 500 lines of headroom.

I've created this PR because the changes I've made in #77438 will push map.rs over the 3000 line limit and cause tidy to complain.

I picked Entry to factor out because it feels less tightly coupled to the rest of BTreeMap than the various iterator implementations.

Related: #60302

[rust-highfive]

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

[pickfire]

Should we make it more explicit and not use use Entry::*?

[exrook]

I don't think so, in this file I think it's pretty clear that Vacant and Occupied are variants of Entry. I don't think adding Entry:: in front of them is really worth it.

In map.rs it may make more sense to remove the glob import, given that there's only 2 uses each of the unqualified variant names

[jyn514]

r? @ssomers

[ssomers]

That 3000 limit can easily be ignored, and map.rs was much longer not too long ago. But it is unwieldly. I moved the remove related functions and methods in one of my branches.

Separating off Entry is probably better, but then it seems weird to me to leave remove_kv_tracking and all the underflow-handling code in map.rs.

[ssomers]

Separating off Entry is probably better

Actually, I changed my mind. It builds with remove_kv_tracking left behind because of the back-to-the-future reference to super::BTreeMap. All the other submodules don't do that: they supply building blocks for our beloved BTreeMap. remove_kv_tracking, with its private functions and types for underflow handling, is such a building block. MergeIter is one too, one that I wanted to reuse in BTreeSet and ended up rewriting. Entry is an even bigger building block, but unfortunately it is strongly tied to BTreeMap.

[dtolnay]

Thanks!

[dtolnay]

@bors r+

[bors]

📌 Commit 4b96049 has been approved by dtolnay

[JohnTitor]

Failed in https://github.com/rust-lang-ci/rust/runs/1266196319 (clippy test):

...

 error: use of `or_insert` followed by a function call
   --> $DIR/or_fun_call.rs:62:19
    |
 LL |     map.entry(42).or_insert(String::new());
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `or_insert_with(String::new)`
 
-error: use of `or_insert` followed by a function call
-  --> $DIR/or_fun_call.rs:65:21
-   |
-LL |     btree.entry(42).or_insert(String::new());
-   |                     ^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `or_insert_with(String::new)`
-
 error: use of `unwrap_or` followed by a function call
   --> $DIR/or_fun_call.rs:68:21
    |
 LL |     let _ = stringy.unwrap_or("".to_owned());
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `unwrap_or_else(|| "".to_owned())`
 
 error: use of `or` followed by a function call
   --> $DIR/or_fun_call.rs:93:35
    |
 LL |     let _ = Some("a".to_string()).or(Some("b".to_string()));
    |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `or_else(|| Some("b".to_string()))`
 
 error: use of `or` followed by a function call
   --> $DIR/or_fun_call.rs:97:10
    |
 LL |         .or(Some(Bar(b, Duration::from_secs(2))));
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `or_else(|| Some(Bar(b, Duration::from_secs(2))))`
 
-error: aborting due to 15 previous errors
+error: aborting due to 14 previous errors

Here's the test: https://github.com/rust-lang/rust-clippy/blob/master/tests/ui/or_fun_call.rs

I guess we cannot find or_insert_with?
@bors r- but correct me if it's wrong.

[ssomers]

but correct me if it's wrong.

I'm inclined to think it's wrong. The 3rd and 4th error have nothing to do with btree, and when I try to invoke BTreeMap's or_insert function outside of the btree modules (since I couldn't find any use of it in the Rust code), it builds normally.

[JohnTitor]

@ssomers Hmm, but the test with gh pr checkout 77851 && git rebase master && x.py test src/tools/clippy fails on my local (master is fine). I still think this PR is the cause.

[ssomers]

Indeed. The path to the Entry struct is hardcoded as BTREEMAP_ENTRY in src/tools/clippy/clippy_lints/src/utils/paths.rs.

[exrook]

I believe I've fixed the failing clippy test, thanks @ssomers for pointing out the hardcoded path.

r? @JohnTitor

[jyn514]

@bors r=dtolnay rollup=iffy

[bors]

📌 Commit 3e2121c has been approved by dtolnay

[JohnTitor]

Confirmed this passes the clippy test, thanks!
This should be fine with @bors rollup=maybe now.

[bors]

⌛ Testing commit 3e2121c with merge 043eca7...