rust/compiler/rustc_const_eval/src
Stuart Cook 599b08ada8
Rollup merge of #140874 - mejrs:rads, r=WaffleLapkin
make `rustc_attr_parsing` less dominant in the rustc crate graph

It has/had a glob re-export of `rustc_attr_data_structures`, which is a crate much lower in the graph, and a lot of crates were using it *just* (or *mostly*) for that re-export, while they can rely on `rustc_attr_data_structures` directly.

Previous graph:
![graph_1](https://github.com/user-attachments/assets/f4a5f13c-4222-4903-b56d-28c83511fcbd)

Graph with this PR:
![graph_2](https://github.com/user-attachments/assets/1e053d9c-75cc-402b-84df-86229c98277a)

The first commit keeps the re-export, and just changes the dependency if possible. The second commit is the "breaking change" which removes the re-export, and "explicitly" adds the `rustc_attr_data_structures` dependency where needed. It also switches over some src/tools/*.

The second commit is actually a lot more involved than I expected. Please let me know if it's a better idea to back it out and just keep the first commit.
2025-05-19 13:24:54 +10:00
..
check_consts don't depend on rustc_attr_parsing if rustc_data_structures will do 2025-05-09 23:16:55 +02:00
const_eval Move DisambiguatorState into intern_const_alloc_recursive 2025-05-02 15:51:26 +02:00
interpret Rollup merge of #135808 - tiif:conv_display, r=workingjubilee 2025-05-17 15:45:19 +02:00
util Remove weak alias terminology 2025-04-24 11:59:20 +01:00
errors.rs interpret: better error message for out-of-bounds pointer arithmetic and accesses 2025-04-30 18:45:41 +02:00
lib.rs update cfg(bootstrap) 2025-05-12 15:33:37 +02:00