rust/src/test/ui/resolve/issue-42944.stderr

error[E0423]: cannot initialize a tuple struct which contains private fields
  --> $DIR/issue-42944.rs:9:9
   |
LL |         Bx(());
   |         ^^
   |
note: constructor is not visible here due to private fields
  --> $DIR/issue-42944.rs:2:19
   |
LL |     pub struct Bx(());
   |                   ^^ private field

error[E0425]: cannot find function, tuple struct or tuple variant `Bx` in this scope
  --> $DIR/issue-42944.rs:16:9
   |
LL |         Bx(());
   |         ^^ not found in this scope
   |
   = note: this tuple struct exists but is inaccessible:
           foo::Bx

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0423, E0425.
For more information about an error, try `rustc --explain E0423`.
resolve: private fields in tuple struct ctor diag This commit improves the diagnostic emitted when a tuple struct is being constructed which has private fields so that private fields are labelled and the message is improved. Signed-off-by: David Wood <david@davidtw.co> 2020-10-26 09:36:48 -05:00			`error[E0423]: cannot initialize a tuple struct which contains private fields`
Only suggest imports if not imported. This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases, we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant. 2019-02-11 12:29:10 -06:00			`--> $DIR/issue-42944.rs:9:9`
			`\|`
Prefer accessible paths in 'use' suggestions This fixes an issue with the following sample: mod foo { mod inaccessible { pub struct X; } pub mod avail { pub struct X; } } fn main() { X; } Instead of suggesting both `use crate::foo::inaccessible::X;` and `use crate::foo::avail::X;`, it should only suggest the latter. It is done by trimming the list of suggestions from inaccessible paths if accessible paths are present. Visibility is checked with `is_accessible_from` now instead of being hard-coded. - Some tests fixes are trivial, and others require a bit more explaining, here are my comments: src/test/ui/issues/issue-35675.stderr: Only needs to make the enum public to have the suggestion make sense. src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't help because its constructor is not visible, so the attempted constructor does not work. In that case, it's better not to suggest it. The case where the constructor is public is covered in `issue-26545.rs`. 2020-06-13 12:58:46 -05:00			`LL \| Bx(());`
resolve: private fields in tuple struct ctor diag This commit improves the diagnostic emitted when a tuple struct is being constructed which has private fields so that private fields are labelled and the message is improved. Signed-off-by: David Wood <david@davidtw.co> 2020-10-26 09:36:48 -05:00			`\| ^^`
			`\|`
			`note: constructor is not visible here due to private fields`
			`--> $DIR/issue-42944.rs:2:19`
			`\|`
			`LL \| pub struct Bx(());`
			`\| ^^ private field`
Only suggest imports if not imported. This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases, we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant. 2019-02-11 12:29:10 -06:00
Prefer accessible paths in 'use' suggestions This fixes an issue with the following sample: mod foo { mod inaccessible { pub struct X; } pub mod avail { pub struct X; } } fn main() { X; } Instead of suggesting both `use crate::foo::inaccessible::X;` and `use crate::foo::avail::X;`, it should only suggest the latter. It is done by trimming the list of suggestions from inaccessible paths if accessible paths are present. Visibility is checked with `is_accessible_from` now instead of being hard-coded. - Some tests fixes are trivial, and others require a bit more explaining, here are my comments: src/test/ui/issues/issue-35675.stderr: Only needs to make the enum public to have the suggestion make sense. src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't help because its constructor is not visible, so the attempted constructor does not work. In that case, it's better not to suggest it. The case where the constructor is public is covered in `issue-26545.rs`. 2020-06-13 12:58:46 -05:00			error[E0425]: cannot find function, tuple struct or tuple variant `Bx` in this scope
Point at local similarly named element and tweak references to variants Point at the span for the definition of ADTs internal to the current crate. Look at the leading char of the ident to determine whether we're expecting a likely fn or any of a fn, a tuple struct or a tuple variant. Turn fn `add_typo_suggestion` into a `Resolver` method. 2019-10-14 19:20:50 -05:00			`--> $DIR/issue-42944.rs:16:9`
Only suggest imports if not imported. This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases, we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant. 2019-02-11 12:29:10 -06:00			`\|`
Prefer accessible paths in 'use' suggestions This fixes an issue with the following sample: mod foo { mod inaccessible { pub struct X; } pub mod avail { pub struct X; } } fn main() { X; } Instead of suggesting both `use crate::foo::inaccessible::X;` and `use crate::foo::avail::X;`, it should only suggest the latter. It is done by trimming the list of suggestions from inaccessible paths if accessible paths are present. Visibility is checked with `is_accessible_from` now instead of being hard-coded. - Some tests fixes are trivial, and others require a bit more explaining, here are my comments: src/test/ui/issues/issue-35675.stderr: Only needs to make the enum public to have the suggestion make sense. src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't help because its constructor is not visible, so the attempted constructor does not work. In that case, it's better not to suggest it. The case where the constructor is public is covered in `issue-26545.rs`. 2020-06-13 12:58:46 -05:00			`LL \| Bx(());`
			`\| ^^ not found in this scope`
Increase spacing for suggestions in diagnostics Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages. 2019-10-24 00:20:58 -05:00			`\|`
Do not suggest importing inaccessible items 2021-09-10 18:15:40 -05:00			`= note: this tuple struct exists but is inaccessible:`
			`foo::Bx`
Only suggest imports if not imported. This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases, we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant. 2019-02-11 12:29:10 -06:00
			`error: aborting due to 2 previous errors`

hide `--explain` hint if error has no extended info 2019-04-17 12:26:38 -05:00			`Some errors have detailed explanations: E0423, E0425.`
Only suggest imports if not imported. This commit modifies name resolution error reporting so that if a name is in scope and has been imported then we do not suggest importing it. This can occur when we add a label about constructors not being visible due to private fields. In these cases, we know that the struct/variant has been imported and we should silence any suggestions to import the struct/variant. 2019-02-11 12:29:10 -06:00			For more information about an error, try `rustc --explain E0423`.