Do not show ::{{constructor}} on tuple struct diagnostics#41433
Do not show ::{{constructor}} on tuple struct diagnostics#41433bors merged 1 commit intorust-lang:masterfrom
::{{constructor}} on tuple struct diagnostics#41433Conversation
::constructor on tuple struct diagnostics::{{constructor}} on tuple struct diagnostics
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
Thank you, @estebank! We'll check in every so often to make sure that @nikomatsakis or another reviewer gets back to you soon! |
| self.push_item_path(buffer, parent_def_id); | ||
| buffer.push(&data.as_interned_str()); | ||
| } | ||
| DefPathData::StructCtor => { // present `X` instead of `X::{{constructor}}` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
This should be fine. Symbol names are fully distinguished by the hash value at the end.
|
@bors r+ |
|
📌 Commit cd60307 has been approved by |
|
⌛ Testing commit cd60307 with merge bbe4dc2... |
|
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 |
|
💔 Test failed - status-appveyor |
|
Just noting that the appveyor build here failed with #40546, but not retrying because of the r- above. |
|
@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 |
|
@nikomatsakis @petrochenkov I believe this is caused because of these lines in 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. |
|
@estebank
That commit only adds the comment, the 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(); |
|
Actually, doesn't matter. |
|
📌 Commit cd60307 has been approved by |
|
@bors retry |
Do not show `::{{constructor}}` on tuple struct diagnostics
Fix #41313.
|
☀️ Test successful - status-appveyor, status-travis |
Fix #41313.