about summary refs log tree commit diff
path: root/compiler/rustc_query_impl/src/keys.rs
AgeCommit message (Collapse)AuthorLines
2021-10-07Turn tcx.vtable_allocation() into a query.Michael Woerister-0/+11
2021-09-18Querify `fn_abi_of_{fn_ptr,instance}`.Eduard-Mihai Burtescu-0/+22
2021-09-05Add query `own_existential_vtable_entries`Gary Guo-0/+10
2021-09-01Auto merge of #88121 - camelid:better-recursive-alias-error, r=estebankbors-0/+17
Improve errors for recursive type aliases Fixes #17539.
2021-08-27Note that trait aliases cannot be recursiveNoah Lev-0/+4
2021-08-27Note that type aliases cannot be recursiveNoah Lev-0/+13
2021-08-26shrink `ty::PredicateKind` againlcnr-1/+1
2021-08-26use `ty::Unevaluated` instead of def substs pairlcnr-8/+3
2021-08-18Fold `vtable_trait_upcasting_coercion_new_vptr_slot` logic into obligation ↵Charles Lew-0/+10
processing.
2021-08-03Implement pointer casting.Charles Lew-0/+10
2021-07-20Support HIR wf checking for function signaturesAaron Hill-2/+2
During function type-checking, we normalize any associated types in the function signature (argument types + return type), and then create WF obligations for each of the normalized types. The HIR wf code does not currently support this case, so any errors that we get have imprecise spans. This commit extends `ObligationCauseCode::WellFormed` to support recording a function parameter, allowing us to get the corresponding HIR type if an error occurs. Function typechecking is modified to pass this information during signature normalization and WF checking. The resulting code is fairly verbose, due to the fact that we can no longer normalize the entire signature with a single function call. As part of the refactoring, we now perform HIR-based WF checking for several other 'typed items' (statics, consts, and inherent impls). As a result, WF and projection errors in a function signature now have a precise span, which points directly at the responsible type. If a function signature is constructed via a macro, this will allow the error message to point at the code 'most responsible' for the error (e.g. a user-supplied macro argument).
2021-07-16Add initial implementation of HIR-based WF checking for diagnosticsAaron Hill-0/+12
During well-formed checking, we walk through all types 'nested' in generic arguments. For example, WF-checking `Option<MyStruct<u8>>` will cause us to check `MyStruct<u8>` and `u8`. However, this is done on a `rustc_middle::ty::Ty`, which has no span information. As a result, any errors that occur will have a very general span (e.g. the definintion of an associated item). This becomes a problem when macros are involved. In general, an associated type like `type MyType = Option<MyStruct<u8>>;` may have completely different spans for each nested type in the HIR. Using the span of the entire associated item might end up pointing to a macro invocation, even though a user-provided span is available in one of the nested types. This PR adds a framework for HIR-based well formed checking. This check is only run during error reporting, and is used to obtain a more precise span for an existing error. This is accomplished by individually checking each 'nested' type in the HIR for the type, allowing us to find the most-specific type (and span) that produces a given error. The majority of the changes are to the error-reporting code. However, some of the general trait code is modified to pass through more information. Since this has no soundness implications, I've implemented a minimal version to begin with, which can be extended over time. In particular, this only works for HIR items with a corresponding `DefId` (e.g. it will not work for WF-checking performed within function bodies).
2021-05-30Only test if key is local.Camille GILLOT-73/+109
2021-05-12Use () in dependency_formats.Camille GILLOT-0/+10
2021-03-31Add a new normalization query just for mir constantsOli Scherer-0/+9
2021-03-12Implement valtreeOli Scherer-0/+9
valtree is a version of constants that is inherently safe to be used within types. This is in contrast to ty::Const which can have different representations of the same value. These representation differences can show up in hashing or equality comparisons, breaking type equality of otherwise equal types. valtrees do not have this problem.
2021-02-19Move the query system to rustc_query_impl.Camille GILLOT-0/+333