Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not show ::{{constructor}} on tuple struct diagnostics #41433

Merged
merged 1 commit into from
Apr 27, 2017

Conversation

estebank
Copy link
Contributor

Fix #41313.

@estebank estebank changed the title Do not show ::constructor on tuple struct diagnostics Do not show ::{{constructor}} on tuple struct diagnostics Apr 21, 2017
@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@shepmaster
Copy link
Member

Thank you, @estebank! We'll check in every so often to make sure that @nikomatsakis or another reviewer gets back to you soon!

@shepmaster shepmaster added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 21, 2017
@@ -186,6 +185,10 @@ impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> {
self.push_item_path(buffer, parent_def_id);
buffer.push(&data.as_interned_str());
}
DefPathData::StructCtor => { // present `X` instead of `X::{{constructor}}`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, wait, actually -- this same code is also used for generating symbol names and the like. @michaelwoerister can you think of any complications that might arise from changing this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be fine. Symbol names are fully distinguished by the hash value at the end.

@michaelwoerister
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Apr 24, 2017

📌 Commit cd60307 has been approved by michaelwoerister

@bors
Copy link
Contributor

bors commented Apr 24, 2017

⌛ Testing commit cd60307 with merge bbe4dc2...

@petrochenkov
Copy link
Contributor

This PR is masking a deeper problem - why is a constructor DefId used in context where struct's DefId is supposed to be used? How many other contexts are affected in the same way?

I think the underlying problem need to be fixed and ::{{constructor}} should be kept for actual constructors.
@bors r-

@bors
Copy link
Contributor

bors commented Apr 24, 2017

💔 Test failed - status-appveyor

@Mark-Simulacrum
Copy link
Member

Just noting that the appveyor build here failed with #40546, but not retrying because of the r- above.

@arielb1 arielb1 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 25, 2017
@nikomatsakis
Copy link
Contributor

@petrochenkov perhaps so. We do sometimes use the constructor def-id for tuple structs, I think? But it's been a while since I looked at this code. Worth investigating.

@estebank is it easy for you to get a RUST_BACKTRACE=1 where the error occurs? (You may find -Ztreat-err-as-bug helpful.) That would help pinpoint where the error is being reported.

@estebank
Copy link
Contributor Author

@nikomatsakis @petrochenkov I believe this is caused because of these lines in collect.rs:

        ItemStruct(ref def, _) => {
            // Use separate constructor id for unit/tuple structs and reuse did for braced structs.
            let ctor_id = if !def.is_struct() {
                Some(tcx.hir.local_def_id(def.id()))
            } else {
                None
            };
            (AdtKind::Struct, vec![
                convert_struct_variant(tcx, ctor_id.unwrap_or(def_id), item.name,
                                       ty::VariantDiscr::Relative(0), def)
            ])
        }

I'm intrigued by the comment as it says what it's doing, but it doesn't state why. It was originally incorporated in 2cdd9f1, I need to further read that commit to understand why.

@petrochenkov
Copy link
Contributor

petrochenkov commented Apr 26, 2017

@estebank
I recall this now.
The situation with constructor DefIds is a bit of mess, and quite large refactoring is required to fix it. Structs and their constructors have different DefIds while variants have the same DefId for both variants themselves and constructors. Variants historically keep constructor ids if constructor exists and struct ids otherwise.
See #28816 (including "outdated" hidden comments) and #36814 (comment) for some background.

It was originally incorporated in 2cdd9f1

That commit only adds the comment, the DefId-assigning logic was pre-existing.

In the meantime, local fix can make diagnostics better:

diff --git a/src/librustc_typeck/check/_match.rs b/src/librustc_typeck/check/_match.rs
index 1086773041..450b0f95fc 100644
--- a/src/librustc_typeck/check/_match.rs
+++ b/src/librustc_typeck/check/_match.rs
@@ -660,8 +660,14 @@ impl<'a, 'gcx, 'tcx> FnCtxt<'a, 'gcx, 'tcx> {
                                etc: bool) {
         let tcx = self.tcx;

+        let mut diagn_did = variant.did;
         let (substs, kind_name) = match adt_ty.sty {
-            ty::TyAdt(adt, substs) => (substs, adt.variant_descr()),
+            ty::TyAdt(adt, substs) => {
+                if !adt.is_enum() && variant.ctor_kind != CtorKind::Fictive {
+                    diagn_did = tcx.parent_def_id(variant.did).expect("no struct def id");
+                }
+                (substs, adt.variant_descr())
+            }
             _ => span_bug!(span, "struct pattern is not an ADT")
         };

@@ -700,12 +706,12 @@ impl<'a, 'gcx, 'tcx> FnCtxt<'a, 'gcx, 'tcx> {
                             struct_span_err!(tcx.sess, span, E0026,
                                              "{} `{}` does not have a field named `{}`",
                                              kind_name,
-                                             tcx.item_path_str(variant.did),
+                                             tcx.item_path_str(diagn_did),
                                              field.name)
                                 .span_label(span,
                                             &format!("{} `{}` does not have field `{}`",
                                                      kind_name,
-                                                     tcx.item_path_str(variant.did),
+                                                     tcx.item_path_str(diagn_did),
                                                      field.name))
                                 .emit();

@petrochenkov
Copy link
Contributor

Actually, doesn't matter.
@bors r=michaelwoerister

@bors
Copy link
Contributor

bors commented Apr 26, 2017

📌 Commit cd60307 has been approved by michaelwoerister

@arielb1
Copy link
Contributor

arielb1 commented Apr 27, 2017

@bors retry

@bors
Copy link
Contributor

bors commented Apr 27, 2017

⌛ Testing commit cd60307 with merge 79b05fe...

bors added a commit that referenced this pull request Apr 27, 2017
Do not show `::{{constructor}}` on tuple struct diagnostics

Fix #41313.
@bors
Copy link
Contributor

bors commented Apr 27, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing 79b05fe to master...

@bors bors merged commit cd60307 into rust-lang:master Apr 27, 2017
@estebank estebank deleted the constructor branch November 9, 2023 05:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants