rust/compiler/rustc_incremental/src/lib.rs

//! Support for serializing the dep-graph and reloading it.

// tidy-alphabetical-start
#![allow(internal_features)]
#![deny(missing_docs)]
#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")]
#![doc(rust_logo)]
#![feature(rustdoc_internals)]
// tidy-alphabetical-end

mod assert_dep_graph;
mod errors;
mod persist;

pub use persist::copy_cgu_workproduct_to_incr_comp_cache_dir;
pub use persist::finalize_session_directory;
pub use persist::in_incr_comp_dir;
pub use persist::in_incr_comp_dir_sess;
pub use persist::load_query_result_cache;
pub use persist::save_dep_graph;
pub use persist::save_work_product_index;
pub use persist::setup_dep_graph;
pub use persist::LoadResult;

rustc_fluent_macro::fluent_messages! { "../messages.ftl" }
make an incremental crate for now, this houses `svh` and the code to check `assert_dep_graph` is sane 2016-03-28 17:36:56 -04:00			`//! Support for serializing the dep-graph and reloading it.`

Use `tidy` to sort crate attributes for all compiler crates. We already do this for a number of crates, e.g. `rustc_middle`, `rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`. For the ones we don't, in many cases the attributes are a mess. - There is no consistency about order of attribute kinds (e.g. `allow`/`deny`/`feature`). - Within attribute kind groups (e.g. the `feature` attributes), sometimes the order is alphabetical, and sometimes there is no particular order. - Sometimes the attributes of a particular kind aren't even grouped all together, e.g. there might be a `feature`, then an `allow`, then another `feature`. This commit extends the existing sorting to all compiler crates, increasing consistency. If any new attribute line is added there is now only one place it can go -- no need for arbitrary decisions. Exceptions: - `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`, because they have no crate attributes. - `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's ignored in `rustfmt.toml`). 2024-06-12 13:49:36 +10:00			`// tidy-alphabetical-start`
			`#![allow(internal_features)]`
Document all public items in `rustc_incremental` Also: - Review and edit current docs - Enforce documentation for crate Co-authored-by: r00ster <r00ster91@protonmail.com> Co-authored-by: Camille Gillot <gillot.camille@gmail.com> 2021-10-29 12:14:17 -05:00			`#![deny(missing_docs)]`
/nightly/nightly-rustc 2020-09-23 21:51:56 +02:00			`#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")]`
Bump cfg(bootstrap)s 2023-11-13 07:39:17 -05:00			`#![doc(rust_logo)]`
			`#![feature(rustdoc_internals)]`
Use `tidy` to sort crate attributes for all compiler crates. We already do this for a number of crates, e.g. `rustc_middle`, `rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`. For the ones we don't, in many cases the attributes are a mess. - There is no consistency about order of attribute kinds (e.g. `allow`/`deny`/`feature`). - Within attribute kind groups (e.g. the `feature` attributes), sometimes the order is alphabetical, and sometimes there is no particular order. - Sometimes the attributes of a particular kind aren't even grouped all together, e.g. there might be a `feature`, then an `allow`, then another `feature`. This commit extends the existing sorting to all compiler crates, increasing consistency. If any new attribute line is added there is now only one place it can go -- no need for arbitrary decisions. Exceptions: - `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`, because they have no crate attributes. - `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's ignored in `rustfmt.toml`). 2024-06-12 13:49:36 +10:00			`// tidy-alphabetical-end`
make an incremental crate for now, this houses `svh` and the code to check `assert_dep_graph` is sane 2016-03-28 17:36:56 -04:00
			`mod assert_dep_graph;`
incremental: migrate diagnostics Migrate the `rustc_incremental` crate's diagnostics to translatable diagnostic structs. Signed-off-by: David Wood <david.wood@huawei.com> 2022-09-26 15:42:12 +01:00			`mod errors;`
make an incremental crate for now, this houses `svh` and the code to check `assert_dep_graph` is sane 2016-03-28 17:36:56 -04:00			`mod persist;`

Change `WorkProduct::saved_files` to an `Option`. Because there is at most one file. 2020-05-12 15:56:02 +10:00			`pub use persist::copy_cgu_workproduct_to_incr_comp_cache_dir;`
Implement copy-on-write scheme for managing the incremental compilation cache. 2016-08-11 19:02:39 -04:00			`pub use persist::finalize_session_directory;`
Modify trans to skip generating `.o` files This checks the `previous_work_products` data from the dep-graph and tries to simply copy a `.o` file if possible. We also add new work-products into the dep-graph, and create edges to/from the dep-node for a work-product. 2016-07-21 12:49:59 -04:00			`pub use persist::in_incr_comp_dir;`
Persist ThinLTO import data in incr. comp. session directory. 2018-08-17 16:07:23 +02:00			`pub use persist::in_incr_comp_dir_sess;`
incr.comp.: Implement query diagnostic persistence. 2017-10-19 14:32:39 +02:00			`pub use persist::load_query_result_cache;`
Implement copy-on-write scheme for managing the incremental compilation cache. 2016-08-11 19:02:39 -04:00			`pub use persist::save_dep_graph;`
incr.comp.: Use red/green tracking for CGU re-use. 2017-09-28 11:58:45 +02:00			`pub use persist::save_work_product_index;`
Don't use a thread to load the dep graph 2023-09-20 15:38:18 +02:00			`pub use persist::setup_dep_graph;`
incr.comp.: Run cache directory garbage collection before loading dep-graph. 2018-02-13 13:37:32 +01:00			`pub use persist::LoadResult;`
errors: generate typed identifiers in each crate Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter. Signed-off-by: David Wood <david.wood@huawei.com> 2022-10-13 10:13:02 +01:00
Use `rustc_fluent_macro::fluent_messages!` directly. Currently we always do this: ``` use rustc_fluent_macro::fluent_messages; ... fluent_messages! { "./example.ftl" } ``` But there is no need, we can just do this everywhere: ``` rustc_fluent_macro::fluent_messages! { "./example.ftl" } ``` which is shorter. 2023-11-22 09:53:07 +11:00			`rustc_fluent_macro::fluent_messages! { "../messages.ftl" }`