bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

Rollup merge of #81496 - guswynn:expected_async_block, r=oli-obk

Browse source 
name async generators something more human friendly in type error diagnostic

fixes #81457

Some details:

1. I opted to load the generator kind from the hir in TyCategory. I also use 1 impl in the hir for the descr
2. I named both the source of the future, in addition to the general type (`future`), not sure what is preferred
3. I am not sure what is required to make sure "generator" is not referred to anywhere. A brief `rg "\"generator\"" showed me that most diagnostics correctly distinguish from generators and async generator, but the `descr` of `DefKind` is pretty general (not sure how thats used)
4. should the descr impl of AsyncGeneratorKind use its display impl instead of copying the string?
This commit is contained in:
Dylan DPC 2021-02-19 02:49:00 +01:00 • committed by GitHub
commit f468fd1d23
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
8 changed files with 104 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

4
compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
View file

@ -1368,8 +1368,8 @@ impl<'a, 'tcx> InferCtxtPrivExt<'tcx> for InferCtxt<'a, 'tcx> {
Some(t) => Some(t),
None => {
let ty = parent_trait_ref.skip_binder().self_ty();
let span =
TyCategory::from_ty(ty).map(|(_, def_id)| self.tcx.def_span(def_id));
let span = TyCategory::from_ty(self.tcx, ty)
.map(|(_, def_id)| self.tcx.def_span(def_id));
Some((ty.to_string(), span))
}
}