1. 09 9月, 2021 1 次提交
  2. 03 9月, 2021 1 次提交
  3. 30 8月, 2021 1 次提交
  4. 26 8月, 2021 1 次提交
  5. 22 8月, 2021 1 次提交
  6. 20 8月, 2021 1 次提交
  7. 13 8月, 2021 1 次提交
  8. 09 8月, 2021 1 次提交
  9. 04 8月, 2021 1 次提交
  10. 03 8月, 2021 1 次提交
  11. 28 7月, 2021 1 次提交
  12. 20 7月, 2021 1 次提交
    • A
      Support HIR wf checking for function signatures · db0324eb
      Aaron Hill 提交于
      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).
      db0324eb
  13. 17 7月, 2021 1 次提交
    • A
      Add initial implementation of HIR-based WF checking for diagnostics · a7653337
      Aaron Hill 提交于
      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).
      a7653337
  14. 19 6月, 2021 5 次提交
  15. 16 6月, 2021 1 次提交
  16. 04 6月, 2021 1 次提交
  17. 12 5月, 2021 1 次提交
  18. 19 4月, 2021 2 次提交
  19. 27 3月, 2021 1 次提交
  20. 17 3月, 2021 2 次提交
  21. 03 3月, 2021 1 次提交
  22. 02 3月, 2021 1 次提交
  23. 16 2月, 2021 1 次提交
  24. 14 2月, 2021 1 次提交
  25. 11 2月, 2021 1 次提交
  26. 04 2月, 2021 1 次提交
  27. 02 2月, 2021 1 次提交
  28. 18 1月, 2021 1 次提交
  29. 17 1月, 2021 1 次提交
  30. 15 1月, 2021 1 次提交
  31. 11 1月, 2021 1 次提交
  32. 03 1月, 2021 2 次提交
  33. 24 12月, 2020 1 次提交