2020-02-11 22:39:02 +01:00
|
|
|
//! This crates defines the type inference engine.
|
2020-01-06 20:13:24 +01:00
|
|
|
//!
|
|
|
|
//! - **Type inference.** The type inference code can be found in the `infer` module;
|
|
|
|
//! this code handles low-level equality and subtyping operations. The
|
2022-09-26 13:00:29 +02:00
|
|
|
//! type check pass in the compiler is found in the `rustc_hir_analysis` crate.
|
2020-01-06 20:13:24 +01:00
|
|
|
//!
|
2020-03-05 18:07:42 -03:00
|
|
|
//! For more information about how rustc works, see the [rustc dev guide].
|
2020-01-06 20:13:24 +01:00
|
|
|
//!
|
2020-03-09 18:33:04 -03:00
|
|
|
//! [rustc dev guide]: https://rustc-dev-guide.rust-lang.org/
|
2020-01-06 20:13:24 +01:00
|
|
|
//!
|
|
|
|
//! # Note
|
|
|
|
//!
|
|
|
|
//! This API is completely unstable and subject to change.
|
|
|
|
|
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
|
2023-11-13 07:39:17 -05:00
|
|
|
#![allow(internal_features)]
|
2024-02-06 09:51:39 +11:00
|
|
|
#![allow(rustc::diagnostic_outside_of_impl)]
|
|
|
|
#![allow(rustc::untranslatable_diagnostic)]
|
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
|
|
|
#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")]
|
|
|
|
#![doc(rust_logo)]
|
2024-08-11 12:10:36 -04:00
|
|
|
#![feature(assert_matches)]
|
2020-05-12 20:09:55 -07:00
|
|
|
#![feature(extend_one)]
|
2023-12-25 21:37:29 +00:00
|
|
|
#![feature(iterator_try_collect)]
|
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
|
|
|
#![feature(let_chains)]
|
|
|
|
#![feature(rustdoc_internals)]
|
2020-02-11 22:39:02 +01:00
|
|
|
#![recursion_limit = "512"] // For rustdoc
|
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
|
2020-01-06 20:13:24 +01:00
|
|
|
|
2022-08-21 20:56:00 +03:00
|
|
|
mod errors;
|
2020-01-06 20:13:24 +01:00
|
|
|
pub mod infer;
|
|
|
|
pub mod traits;
|
2022-10-13 10:13:02 +01:00
|
|
|
|
2023-11-22 09:53:07 +11:00
|
|
|
rustc_fluent_macro::fluent_messages! { "../messages.ftl" }
|