rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
Files
51b51b51d7931da85280382a81c4dd80c73ca754
rust/tests/ui/stats/input-stats.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

179 lines
12 KiB
Plaintext
Raw Normal View History

Add prefix to every line of `-Zhir-stats` output. This is based on `-Zprint-type-sizes` which does the same thing. It makes the output provenance clearer, and helps with post-processing. E.g. if you have `-Zhir-stats` output from numerous compiler invocations you can now easily extract the pre-expansion stats separately from the post-expansion stats.
2022-08-26 13:52:41 +10:00
ast-stats-1 PRE EXPANSION AST STATS
ast-stats-1 Name Accumulated Size Count Item Size
ast-stats-1 ----------------------------------------------------------------
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-1 Crate 40 ( 0.6%) 1 40
Use `ThinVec` in various AST types. This commit changes the sequence parsers to produce `ThinVec`, which triggers numerous conversions.
2022-11-23 11:55:16 +11:00
ast-stats-1 GenericArgs 40 ( 0.6%) 1 40
ast-stats-1 - AngleBracketed 40 ( 0.6%) 1
Use `ThinVec` in `ast::Generics` and related types.
2022-11-22 09:17:20 +11:00
ast-stats-1 ExprField 48 ( 0.7%) 1 48
Use `ThinVec` in `ast::PatKind::Struct`.
2023-01-30 14:58:23 +11:00
ast-stats-1 Attribute 64 ( 1.0%) 2 32
Use `ThinVec` in `ast::WhereClause`.
2022-11-22 16:23:25 +11:00
ast-stats-1 - DocComment 32 ( 0.5%) 1
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-1 - Normal 32 ( 0.5%) 1
Implment `#[cfg]` and `#[cfg_attr]` in `where` clauses
2025-02-05 18:58:29 +08:00
ast-stats-1 WherePredicate 72 ( 1.1%) 1 72
ast-stats-1 - BoundPredicate 72 ( 1.1%) 1
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-1 ForeignItem 80 ( 1.2%) 1 80
ast-stats-1 - Fn 80 ( 1.2%) 1
Detect more cases of `=` to `:` typo When a `Local` is fully parsed, but not followed by a `;`, keep the `:` span arround and mention it. If the type could continue being parsed as an expression, suggest replacing the `:` with a `=`. ``` error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` --> file.rs:2:32 | 2 | let _: std::env::temp_dir().join("foo"); | - ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=` | | | while parsing the type for `_` | help: use `=` if you meant to assign ``` Fix #119665.
2024-02-27 00:48:32 +00:00
ast-stats-1 Local 80 ( 1.2%) 1 80
ast: Standardize visiting order Id, attributes, inner nodes in source order if possible, tokens, span. Also always use exhaustive matching in visiting infra, and visit some missing nodes.
2024-06-26 15:25:57 +03:00
ast-stats-1 Arm 96 ( 1.4%) 2 48
Use `ThinVec` in various AST types. This commit changes the sequence parsers to produce `ThinVec`, which triggers numerous conversions.
2022-11-23 11:55:16 +11:00
ast-stats-1 FnDecl 120 ( 1.8%) 5 24
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-1 Param 160 ( 2.4%) 4 40
Refactor AST trait bound modifiers
2023-12-20 15:22:06 +01:00
ast-stats-1 Stmt 160 ( 2.4%) 5 32
Update `tests/ui/stats/hir-stats.stderr` output
2024-03-14 12:00:46 +01:00
ast-stats-1 - Let 32 ( 0.5%) 1
Use `ThinVec` in `ast::WhereClause`.
2022-11-22 16:23:25 +11:00
ast-stats-1 - MacCall 32 ( 0.5%) 1
ast: Standardize visiting order Id, attributes, inner nodes in source order if possible, tokens, span. Also always use exhaustive matching in visiting infra, and visit some missing nodes.
2024-06-26 15:25:57 +03:00
ast-stats-1 - Expr 96 ( 1.4%) 3
Add `Span` to `TraitBoundModifier`
2023-11-24 14:32:05 +00:00
ast-stats-1 Block 192 ( 2.9%) 6 32
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
ast-stats-1 FieldDef 208 ( 3.1%) 2 104
Add async bound modifier to enable async Fn bounds
2024-01-26 17:00:28 +00:00
ast-stats-1 Variant 208 ( 3.1%) 2 104
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-1 AssocItem 320 ( 4.8%) 4 80
ast-stats-1 - Fn 160 ( 2.4%) 2
ast-stats-1 - Type 160 ( 2.4%) 2
ast-stats-1 GenericBound 352 ( 5.2%) 4 88
ast-stats-1 - Trait 352 ( 5.2%) 4
ast-stats-1 GenericParam 480 ( 7.1%) 5 96
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
ast-stats-1 Pat 504 ( 7.5%) 7 72
Use `ThinVec` in `ast::PatKind::Struct`.
2023-01-30 14:58:23 +11:00
ast-stats-1 - Struct 72 ( 1.1%) 1
ast-stats-1 - Wild 72 ( 1.1%) 1
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-1 - Ident 360 ( 5.3%) 5
Refactor `where` predicates, and reserve for attributes support
2024-11-25 16:38:35 +08:00
ast-stats-1 Expr 576 ( 8.6%) 8 72
Use `ThinVec` in various AST types. This commit changes the sequence parsers to produce `ThinVec`, which triggers numerous conversions.
2022-11-23 11:55:16 +11:00
ast-stats-1 - Match 72 ( 1.1%) 1
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
ast-stats-1 - Path 72 ( 1.1%) 1
Use `ThinVec` in various AST types. This commit changes the sequence parsers to produce `ThinVec`, which triggers numerous conversions.
2022-11-23 11:55:16 +11:00
ast-stats-1 - Struct 72 ( 1.1%) 1
Implment `#[cfg]` and `#[cfg_attr]` in `where` clauses
2025-02-05 18:58:29 +08:00
ast-stats-1 - Lit 144 ( 2.1%) 2
Implement the unsafe-fields RFC. Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>
2024-10-27 01:35:33 +02:00
ast-stats-1 - Block 216 ( 3.2%) 3
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-1 PathSegment 744 (11.0%) 31 24
ast-stats-1 Ty 896 (13.3%) 14 64
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-1 - Ptr 64 ( 1.0%) 1
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
ast-stats-1 - Ref 64 ( 1.0%) 1
Add async bound modifier to enable async Fn bounds
2024-01-26 17:00:28 +00:00
ast-stats-1 - ImplicitSelf 128 ( 1.9%) 2
Implment `#[cfg]` and `#[cfg_attr]` in `where` clauses
2025-02-05 18:58:29 +08:00
ast-stats-1 - Path 640 ( 9.5%) 10
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-1 Item 1_296 (19.2%) 9 144
ast-stats-1 - Enum 144 ( 2.1%) 1
ast-stats-1 - ForeignMod 144 ( 2.1%) 1
ast-stats-1 - Impl 144 ( 2.1%) 1
ast-stats-1 - Trait 144 ( 2.1%) 1
ast-stats-1 - Fn 288 ( 4.3%) 2
ast-stats-1 - Use 432 ( 6.4%) 3
Add prefix to every line of `-Zhir-stats` output. This is based on `-Zprint-type-sizes` which does the same thing. It makes the output provenance clearer, and helps with post-processing. E.g. if you have `-Zhir-stats` output from numerous compiler invocations you can now easily extract the pre-expansion stats separately from the post-expansion stats.
2022-08-26 13:52:41 +10:00
ast-stats-1 ----------------------------------------------------------------
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-1 Total 6_736 116
Add prefix to every line of `-Zhir-stats` output. This is based on `-Zprint-type-sizes` which does the same thing. It makes the output provenance clearer, and helps with post-processing. E.g. if you have `-Zhir-stats` output from numerous compiler invocations you can now easily extract the pre-expansion stats separately from the post-expansion stats.
2022-08-26 13:52:41 +10:00
ast-stats-1
ast-stats-2 POST EXPANSION AST STATS
ast-stats-2 Name Accumulated Size Count Item Size
ast-stats-2 ----------------------------------------------------------------
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-2 Crate 40 ( 0.5%) 1 40
ast: Standardize visiting order Id, attributes, inner nodes in source order if possible, tokens, span. Also always use exhaustive matching in visiting infra, and visit some missing nodes.
2024-06-26 15:25:57 +03:00
ast-stats-2 GenericArgs 40 ( 0.5%) 1 40
ast-stats-2 - AngleBracketed 40 ( 0.5%) 1
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-2 ExprField 48 ( 0.6%) 1 48
Implment `#[cfg]` and `#[cfg_attr]` in `where` clauses
2025-02-05 18:58:29 +08:00
ast-stats-2 WherePredicate 72 ( 1.0%) 1 72
ast-stats-2 - BoundPredicate 72 ( 1.0%) 1
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-2 ForeignItem 80 ( 1.1%) 1 80
ast-stats-2 - Fn 80 ( 1.1%) 1
Detect more cases of `=` to `:` typo When a `Local` is fully parsed, but not followed by a `;`, keep the `:` span arround and mention it. If the type could continue being parsed as an expression, suggest replacing the `:` with a `=`. ``` error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` --> file.rs:2:32 | 2 | let _: std::env::temp_dir().join("foo"); | - ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=` | | | while parsing the type for `_` | help: use `=` if you meant to assign ``` Fix #119665.
2024-02-27 00:48:32 +00:00
ast-stats-2 Local 80 ( 1.1%) 1 80
Add `Span` to `TraitBoundModifier`
2023-11-24 14:32:05 +00:00
ast-stats-2 Arm 96 ( 1.3%) 2 48
ast: Standardize visiting order Id, attributes, inner nodes in source order if possible, tokens, span. Also always use exhaustive matching in visiting infra, and visit some missing nodes.
2024-06-26 15:25:57 +03:00
ast-stats-2 FnDecl 120 ( 1.6%) 5 24
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-2 InlineAsm 120 ( 1.6%) 1 120
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
ast-stats-2 Attribute 128 ( 1.7%) 4 32
Add `Span` to `TraitBoundModifier`
2023-11-24 14:32:05 +00:00
ast-stats-2 - DocComment 32 ( 0.4%) 1
ast-stats-2 - Normal 96 ( 1.3%) 3
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-2 Param 160 ( 2.2%) 4 40
Add `Span` to `TraitBoundModifier`
2023-11-24 14:32:05 +00:00
ast-stats-2 Stmt 160 ( 2.2%) 5 32
Update `tests/ui/stats/hir-stats.stderr` output
2024-03-14 12:00:46 +01:00
ast-stats-2 - Let 32 ( 0.4%) 1
Add `Span` to `TraitBoundModifier`
2023-11-24 14:32:05 +00:00
ast-stats-2 - Semi 32 ( 0.4%) 1
ast-stats-2 - Expr 96 ( 1.3%) 3
ast: Standardize visiting order Id, attributes, inner nodes in source order if possible, tokens, span. Also always use exhaustive matching in visiting infra, and visit some missing nodes.
2024-06-26 15:25:57 +03:00
ast-stats-2 Block 192 ( 2.6%) 6 32
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
ast-stats-2 FieldDef 208 ( 2.8%) 2 104
Implement the unsafe-fields RFC. Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>
2024-10-27 01:35:33 +02:00
ast-stats-2 Variant 208 ( 2.8%) 2 104
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-2 AssocItem 320 ( 4.3%) 4 80
ast-stats-2 - Fn 160 ( 2.2%) 2
ast-stats-2 - Type 160 ( 2.2%) 2
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-2 GenericBound 352 ( 4.8%) 4 88
ast-stats-2 - Trait 352 ( 4.8%) 4
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
ast-stats-2 GenericParam 480 ( 6.5%) 5 96
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-2 Pat 504 ( 6.8%) 7 72
Use `ThinVec` in `ast::PatKind::Struct`.
2023-01-30 14:58:23 +11:00
ast-stats-2 - Struct 72 ( 1.0%) 1
ast-stats-2 - Wild 72 ( 1.0%) 1
ast: Standardize visiting order Id, attributes, inner nodes in source order if possible, tokens, span. Also always use exhaustive matching in visiting infra, and visit some missing nodes.
2024-06-26 15:25:57 +03:00
ast-stats-2 - Ident 360 ( 4.9%) 5
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
ast-stats-2 Expr 648 ( 8.8%) 9 72
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
ast-stats-2 - InlineAsm 72 ( 1.0%) 1
Use `ThinVec` in various AST types. This commit changes the sequence parsers to produce `ThinVec`, which triggers numerous conversions.
2022-11-23 11:55:16 +11:00
ast-stats-2 - Match 72 ( 1.0%) 1
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
ast-stats-2 - Path 72 ( 1.0%) 1
Use `ThinVec` in various AST types. This commit changes the sequence parsers to produce `ThinVec`, which triggers numerous conversions.
2022-11-23 11:55:16 +11:00
ast-stats-2 - Struct 72 ( 1.0%) 1
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-2 - Lit 144 ( 1.9%) 2
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
ast-stats-2 - Block 216 ( 2.9%) 3
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-2 PathSegment 864 (11.7%) 36 24
ast-stats-2 Ty 896 (12.1%) 14 64
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
ast-stats-2 - Ptr 64 ( 0.9%) 1
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
ast-stats-2 - Ref 64 ( 0.9%) 1
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
ast-stats-2 - ImplicitSelf 128 ( 1.7%) 2
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-2 - Path 640 ( 8.6%) 10
ast-stats-2 Item 1_584 (21.4%) 11 144
ast-stats-2 - Enum 144 ( 1.9%) 1
ast-stats-2 - ExternCrate 144 ( 1.9%) 1
ast-stats-2 - ForeignMod 144 ( 1.9%) 1
ast-stats-2 - Impl 144 ( 1.9%) 1
ast-stats-2 - Trait 144 ( 1.9%) 1
ast-stats-2 - Fn 288 ( 3.9%) 2
ast-stats-2 - Use 576 ( 7.8%) 4
Add prefix to every line of `-Zhir-stats` output. This is based on `-Zprint-type-sizes` which does the same thing. It makes the output provenance clearer, and helps with post-processing. E.g. if you have `-Zhir-stats` output from numerous compiler invocations you can now easily extract the pre-expansion stats separately from the post-expansion stats.
2022-08-26 13:52:41 +10:00
ast-stats-2 ----------------------------------------------------------------
Move `ast::Item::ident` into `ast::ItemKind`. `ast::Item` has an `ident` field. - It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, `Trait`, `TraitAlias`, `MacroDef`, `Delegation`. - It's always empty for these item kinds: `Use`, `ForeignMod`, `GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`. There is a similar story for `AssocItemKind` and `ForeignItemKind`. Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out. The commit is large but it's mostly obvious plumbing work. Some notable things. - `ast::Item` got 8 bytes bigger. This could be avoided by boxing the fields within some of the `ast::ItemKind` variants (specifically: `Struct`, `Union`, `Enum`). I might do that in a follow-up; this commit is big enough already. - For the visitors: `FnKind` no longer needs an `ident` field because the `Fn` within how has one. - In the parser, the `ItemInfo` typedef is no longer needed. It was used in various places to return an `Ident` alongside an `ItemKind`, but now the `Ident` (if present) is within the `ItemKind`. - In a few places I renamed identifier variables called `name` (or `foo_name`) as `ident` (or `foo_ident`), to better match the type, and because `name` is normally used for `Symbol`s. It's confusing to see something like `foo_name.name`.
2025-03-21 09:47:43 +11:00
ast-stats-2 Total 7_400 127
Add prefix to every line of `-Zhir-stats` output. This is based on `-Zprint-type-sizes` which does the same thing. It makes the output provenance clearer, and helps with post-processing. E.g. if you have `-Zhir-stats` output from numerous compiler invocations you can now easily extract the pre-expansion stats separately from the post-expansion stats.
2022-08-26 13:52:41 +10:00
ast-stats-2
hir-stats HIR STATS
hir-stats Name Accumulated Size Count Item Size
hir-stats ----------------------------------------------------------------
Shrink `hir::def::Res`. `Res::SelfTy` currently has two `Option`s. When the second one is `Some` the first one is never consulted. So we can split it into two variants, `Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res` from 24 bytes to 12. This then shrinks `hir::Path` and `hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-16 11:45:33 +10:00
hir-stats ForeignItemRef 24 ( 0.3%) 1 24
Don't use `kw::Empty` in `hir::Lifetime::ident`. `hir::Lifetime::ident` currently sometimes uses `kw::Empty` for elided lifetimes and sometimes uses `kw::UnderscoreLifetime`, and the distinction is used when creating some error suggestions, e.g. in `Lifetime::suggestion` and `ImplicitLifetimeFinder::visit_ty`. I found this *really* confusing, and it took me a while to understand what was going on. This commit replaces all uses of `kw::Empty` in `hir::Lifetime::ident` with `kw::UnderscoreLifetime`. It adds a new field `hir::Lifetime::is_path_anon` that mostly replaces the old empty/underscore distinction and makes things much clearer. Some other notable changes: - Adds a big comment to `Lifetime` talking about permissable field values. - Adds some assertions in `new_named_lifetime` about what ident values are permissible for the different `LifetimeRes` values. - Adds a `Lifetime::new` constructor that does some checking to make sure the `is_elided` and `is_anonymous` states are valid. - `add_static_impl_trait_suggestion` now looks at `Lifetime::res` instead of the ident when creating the suggestion. This is the one case where `is_path_anon` doesn't replace the old empty/underscore distinction. - A couple of minor pretty-printing improvements.
2025-03-25 08:21:28 +11:00
hir-stats Lifetime 28 ( 0.3%) 1 28
rustc_ast_lowering: Stop lowering imports into multiple items Lower them into a single item with multiple resolutions instead. This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
2022-12-01 18:51:20 +03:00
hir-stats Mod 32 ( 0.4%) 1 32
Improve HIR stats collector. Adds and removes some `visit_*` methods accordingly, improving coverage, and avoiding some double counting. Brings it in line with the AST stats collector.
2022-08-29 11:10:56 +10:00
hir-stats ExprField 40 ( 0.4%) 1 40
Use niche-filling optimization even when multiple variants have data. Fixes #46213
2022-03-08 19:07:01 +00:00
hir-stats TraitItemRef 56 ( 0.6%) 2 28
Add `ConstArgKind::Path` and make `ConstArg` its own HIR node This is a very large commit since a lot needs to be changed in order to make the tests pass. The salient changes are: - `ConstArgKind` gets a new `Path` variant, and all const params are now represented using it. Non-param paths still use `ConstArgKind::Anon` to prevent this change from getting too large, but they will soon use the `Path` variant too. - `ConstArg` gets a distinct `hir_id` field and its own variant in `hir::Node`. This affected many parts of the compiler that expected the parent of an `AnonConst` to be the containing context (e.g., an array repeat expression). They have been changed to check the "grandparent" where necessary. - Some `ast::AnonConst`s now have their `DefId`s created in rustc_ast_lowering rather than `DefCollector`. This is because in some cases they will end up becoming a `ConstArgKind::Path` instead, which has no `DefId`. We have to solve this in a hacky way where we guess whether the `AnonConst` could end up as a path const since we can't know for sure until after name resolution (`N` could refer to a free const or a nullary struct). If it has no chance as being a const param, then we create a `DefId` in `DefCollector` -- otherwise we decide during ast_lowering. This will have to be updated once all path consts use `ConstArgKind::Path`. - We explicitly use `ConstArgHasType` for array lengths, rather than implicitly relying on anon const type feeding -- this is due to the addition of `ConstArgKind::Path`. - Some tests have their outputs changed, but the changes are for the most part minor (including removing duplicate or almost-duplicate errors). One test now ICEs, but it is for an incomplete, unstable feature and is now tracked at #127009.
2024-07-16 19:07:36 -07:00
hir-stats GenericArg 64 ( 0.7%) 4 16
hir-stats - Type 16 ( 0.2%) 1
hir-stats - Lifetime 48 ( 0.5%) 3
Arena-allocate `hir::Lifetime`. This shrinks `hir::Ty` from 72 to 48 bytes. `visit_lifetime` is added to the HIR stats collector because these types are now stored in memory on their own, instead of being within other types.
2022-09-01 12:06:48 +10:00
hir-stats Local 64 ( 0.7%) 1 64
hir-stats Param 64 ( 0.7%) 2 32
Make closures carry their own ClosureKind, rather than deducing what it is from movability
2023-12-22 21:29:12 +00:00
hir-stats Body 72 ( 0.8%) 3 24
Shrink `hir::def::Res`. `Res::SelfTy` currently has two `Option`s. When the second one is `Some` the first one is never consulted. So we can split it into two variants, `Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res` from 24 bytes to 12. This then shrinks `hir::Path` and `hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-16 11:45:33 +10:00
hir-stats ImplItemRef 72 ( 0.8%) 2 36
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
hir-stats InlineAsm 72 ( 0.8%) 1 72
Refactor `where` predicates, and reserve for attributes support
2024-11-25 16:38:35 +08:00
hir-stats WherePredicate 72 ( 0.8%) 3 24
hir-stats - BoundPredicate 72 ( 0.8%) 3
Remove `hir::Guard` Use Expr instead. Use `ExprKind::Let` to represent if let guards.
2023-09-21 11:26:50 +00:00
hir-stats Arm 80 ( 0.9%) 2 40
rustc_ast_lowering: Stop lowering imports into multiple items Lower them into a single item with multiple resolutions instead. This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
2022-12-01 18:51:20 +03:00
hir-stats Stmt 96 ( 1.1%) 3 32
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
hir-stats - Expr 32 ( 0.4%) 1
Update `tests/ui/stats/hir-stats.stderr` output
2024-03-14 12:00:46 +01:00
hir-stats - Let 32 ( 0.4%) 1
rustc_ast_lowering: Stop lowering imports into multiple items Lower them into a single item with multiple resolutions instead. This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
2022-12-01 18:51:20 +03:00
hir-stats - Semi 32 ( 0.4%) 1
Shrink `hir::def::Res`. `Res::SelfTy` currently has two `Option`s. When the second one is `Some` the first one is never consulted. So we can split it into two variants, `Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res` from 24 bytes to 12. This then shrinks `hir::Path` and `hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-16 11:45:33 +10:00
hir-stats FnDecl 120 ( 1.3%) 3 40
hir-stats Attribute 128 ( 1.4%) 4 32
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
hir-stats FieldDef 128 ( 1.4%) 2 64
Shrink `hir::def::Res`. `Res::SelfTy` currently has two `Option`s. When the second one is `Some` the first one is never consulted. So we can split it into two variants, `Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res` from 24 bytes to 12. This then shrinks `hir::Path` and `hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-16 11:45:33 +10:00
hir-stats GenericArgs 144 ( 1.6%) 3 48
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
hir-stats Variant 144 ( 1.6%) 2 72
Refactor `where` predicates, and reserve for attributes support
2024-11-25 16:38:35 +08:00
hir-stats GenericBound 256 ( 2.9%) 4 64
hir-stats - Trait 256 ( 2.9%) 4
rustc_ast_lowering: Stop lowering imports into multiple items Lower them into a single item with multiple resolutions instead. This also allows to remove additional `NodId`s and `DefId`s related to those additional items.
2022-12-01 18:51:20 +03:00
hir-stats Block 288 ( 3.2%) 6 48
Make closures carry their own ClosureKind, rather than deducing what it is from movability
2023-12-22 21:29:12 +00:00
hir-stats Pat 360 ( 4.0%) 5 72
Shrink `hir::def::Res`. `Res::SelfTy` currently has two `Option`s. When the second one is `Some` the first one is never consulted. So we can split it into two variants, `Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res` from 24 bytes to 12. This then shrinks `hir::Path` and `hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-16 11:45:33 +10:00
hir-stats - Struct 72 ( 0.8%) 1
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
hir-stats - Wild 72 ( 0.8%) 1
Shrink `hir::def::Res`. `Res::SelfTy` currently has two `Option`s. When the second one is `Some` the first one is never consulted. So we can split it into two variants, `Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res` from 24 bytes to 12. This then shrinks `hir::Path` and `hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-16 11:45:33 +10:00
hir-stats - Binding 216 ( 2.4%) 3
Fix ICE when opaque captures a duplicated/invalid lifetime
2025-01-01 16:55:10 +00:00
hir-stats GenericParam 400 ( 4.5%) 5 80
hir-stats Generics 560 ( 6.2%) 10 56
hir-stats Ty 720 ( 8.0%) 15 48
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
hir-stats - Ptr 48 ( 0.5%) 1
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
hir-stats - Ref 48 ( 0.5%) 1
Don't use `kw::Empty` in `hir::Lifetime::ident`. `hir::Lifetime::ident` currently sometimes uses `kw::Empty` for elided lifetimes and sometimes uses `kw::UnderscoreLifetime`, and the distinction is used when creating some error suggestions, e.g. in `Lifetime::suggestion` and `ImplicitLifetimeFinder::visit_ty`. I found this *really* confusing, and it took me a while to understand what was going on. This commit replaces all uses of `kw::Empty` in `hir::Lifetime::ident` with `kw::UnderscoreLifetime`. It adds a new field `hir::Lifetime::is_path_anon` that mostly replaces the old empty/underscore distinction and makes things much clearer. Some other notable changes: - Adds a big comment to `Lifetime` talking about permissable field values. - Adds some assertions in `new_named_lifetime` about what ident values are permissible for the different `LifetimeRes` values. - Adds a `Lifetime::new` constructor that does some checking to make sure the `is_elided` and `is_anonymous` states are valid. - `add_static_impl_trait_suggestion` now looks at `Lifetime::res` instead of the ident when creating the suggestion. This is the one case where `is_path_anon` doesn't replace the old empty/underscore distinction. - A couple of minor pretty-printing improvements.
2025-03-25 08:21:28 +11:00
hir-stats - Path 624 ( 6.9%) 13
Refactor `where` predicates, and reserve for attributes support
2024-11-25 16:38:35 +08:00
hir-stats Expr 768 ( 8.6%) 12 64
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
hir-stats - InlineAsm 64 ( 0.7%) 1
Arena-allocate `hir::Lifetime`. This shrinks `hir::Ty` from 72 to 48 bytes. `visit_lifetime` is added to the HIR stats collector because these types are now stored in memory on their own, instead of being within other types.
2022-09-01 12:06:48 +10:00
hir-stats - Match 64 ( 0.7%) 1
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
hir-stats - Path 64 ( 0.7%) 1
Stop relying on hashmap iteration for hir stat printing Just because the code says it's OK does not mean that it actually is OK. Nodes with the same total size were not sorted, their order relied on hashmap iteration.
2024-10-17 19:50:59 +02:00
hir-stats - Struct 64 ( 0.7%) 1
Shrink `hir::def::Res`. `Res::SelfTy` currently has two `Option`s. When the second one is `Some` the first one is never consulted. So we can split it into two variants, `Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res` from 24 bytes to 12. This then shrinks `hir::Path` and `hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-16 11:45:33 +10:00
hir-stats - Lit 128 ( 1.4%) 2
Refactor `where` predicates, and reserve for attributes support
2024-11-25 16:38:35 +08:00
hir-stats - Block 384 ( 4.3%) 6
Introduce `default_field_values` feature Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681. Support default fields in enum struct variant Allow default values in an enum struct variant definition: ```rust pub enum Bar { Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Allow using `..` without a base on an enum struct variant ```rust Bar::Foo { .. } ``` `#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants. Support `#[derive(Default)]` on enum struct variants with all defaulted fields ```rust pub enum Bar { #[default] Foo { bar: S = S, baz: i32 = 42 + 3, } } ``` Check for missing fields in typeck instead of mir_build. Expand test with `const` param case (needs `generic_const_exprs` enabled). Properly instantiate MIR const The following works: ```rust struct S<A> { a: Vec<A> = Vec::new(), } S::<i32> { .. } ``` Add lint for default fields that will always fail const-eval We *allow* this to happen for API writers that might want to rely on users' getting a compile error when using the default field, different to the error that they would get when the field isn't default. We could change this to *always* error instead of being a lint, if we wanted. This will *not* catch errors for partially evaluated consts, like when the expression relies on a const parameter. Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`: - Suggest adding a base expression if there are missing fields. - Suggest enabling the feature if all the missing fields have optional values. - Suggest removing `..` if there are no missing fields.
2024-08-24 17:22:48 +00:00
hir-stats Item 968 (10.8%) 11 88
Record asyncness span in HIR
2023-09-14 22:38:07 +00:00
hir-stats - Enum 88 ( 1.0%) 1
hir-stats - ExternCrate 88 ( 1.0%) 1
hir-stats - ForeignMod 88 ( 1.0%) 1
Fix `-Z inputs-stats` ordering. In #129533 the main hash function changed and the order of `-Z input-stats` output changed, which showed that it is dependent on the hash function, even though it is sorted. That's because entries with the same cumulative size are ordered in a way that depends on the hash function. This commit fixes that by using the entry label as the secondary ordering key.
2024-12-17 14:44:35 +11:00
hir-stats - Impl 88 ( 1.0%) 1
hir-stats - Trait 88 ( 1.0%) 1
Refactor `where` predicates, and reserve for attributes support
2024-11-25 16:38:35 +08:00
hir-stats - Fn 176 ( 2.0%) 2
Record asyncness span in HIR
2023-09-14 22:38:07 +00:00
hir-stats - Use 352 ( 3.9%) 4
Fix ICE when opaque captures a duplicated/invalid lifetime
2025-01-01 16:55:10 +00:00
hir-stats Path 1_240 (13.8%) 31 40
hir-stats PathSegment 1_920 (21.4%) 40 48
Add prefix to every line of `-Zhir-stats` output. This is based on `-Zprint-type-sizes` which does the same thing. It makes the output provenance clearer, and helps with post-processing. E.g. if you have `-Zhir-stats` output from numerous compiler invocations you can now easily extract the pre-expansion stats separately from the post-expansion stats.
2022-08-26 13:52:41 +10:00
hir-stats ----------------------------------------------------------------
Don't use `kw::Empty` in `hir::Lifetime::ident`. `hir::Lifetime::ident` currently sometimes uses `kw::Empty` for elided lifetimes and sometimes uses `kw::UnderscoreLifetime`, and the distinction is used when creating some error suggestions, e.g. in `Lifetime::suggestion` and `ImplicitLifetimeFinder::visit_ty`. I found this *really* confusing, and it took me a while to understand what was going on. This commit replaces all uses of `kw::Empty` in `hir::Lifetime::ident` with `kw::UnderscoreLifetime`. It adds a new field `hir::Lifetime::is_path_anon` that mostly replaces the old empty/underscore distinction and makes things much clearer. Some other notable changes: - Adds a big comment to `Lifetime` talking about permissable field values. - Adds some assertions in `new_named_lifetime` about what ident values are permissible for the different `LifetimeRes` values. - Adds a `Lifetime::new` constructor that does some checking to make sure the `is_elided` and `is_anonymous` states are valid. - `add_static_impl_trait_suggestion` now looks at `Lifetime::res` instead of the ident when creating the suggestion. This is the one case where `is_path_anon` doesn't replace the old empty/underscore distinction. - A couple of minor pretty-printing improvements.
2025-03-25 08:21:28 +11:00
hir-stats Total 8_980 180
Add prefix to every line of `-Zhir-stats` output. This is based on `-Zprint-type-sizes` which does the same thing. It makes the output provenance clearer, and helps with post-processing. E.g. if you have `-Zhir-stats` output from numerous compiler invocations you can now easily extract the pre-expansion stats separately from the post-expansion stats.
2022-08-26 13:52:41 +10:00
hir-stats
Reference in New Issue Copy Permalink