1. 03 8月, 2023 1 次提交
    • N
      Add `internal_features` lint · 5830ca21
      Nilstrieb 提交于
      It lints against features that are inteded to be internal to the
      compiler and standard library. Implements MCP #596.
      
      We allow `internal_features` in the standard library and compiler as those
      use many features and this _is_ the standard library from the "internal to the compiler and
      standard library" after all.
      
      Marking some features as internal wasn't exactly the most scientific approach, I just marked some
      mostly obvious features. While there is a categorization in the macro,
      it's not very well upheld (should probably be fixed in another PR).
      
      We always pass `-Ainternal_features` in the testsuite
      About 400 UI tests and several other tests use internal features.
      Instead of throwing the attribute on each one, just always allow them.
      There's nothing wrong with testing internal features^^
      5830ca21
  2. 31 7月, 2023 1 次提交
  3. 23 7月, 2023 1 次提交
  4. 22 7月, 2023 1 次提交
  5. 18 7月, 2023 1 次提交
  6. 15 7月, 2023 2 次提交
  7. 12 7月, 2023 1 次提交
  8. 08 7月, 2023 1 次提交
  9. 03 7月, 2023 1 次提交
  10. 02 7月, 2023 1 次提交
  11. 01 7月, 2023 1 次提交
  12. 30 6月, 2023 1 次提交
  13. 28 6月, 2023 1 次提交
  14. 25 6月, 2023 2 次提交
  15. 24 6月, 2023 2 次提交
  16. 23 6月, 2023 1 次提交
  17. 21 6月, 2023 1 次提交
  18. 20 6月, 2023 1 次提交
  19. 17 6月, 2023 1 次提交
  20. 15 6月, 2023 1 次提交
  21. 14 6月, 2023 3 次提交
  22. 11 6月, 2023 1 次提交
  23. 10 6月, 2023 1 次提交
  24. 07 6月, 2023 1 次提交
  25. 04 6月, 2023 1 次提交
  26. 03 6月, 2023 3 次提交
  27. 31 5月, 2023 1 次提交
  28. 29 5月, 2023 2 次提交
  29. 25 5月, 2023 1 次提交
  30. 24 5月, 2023 3 次提交
    • G
      0a7293ff
    • M
      b9302d72
    • M
      rustdoc: add interaction delays for tooltip popovers · c1d72de0
      Michael Howell 提交于
      Designing a good hover microinteraction is a matter of guessing
      user intent from what are, literally, vague gestures. In this case,
      guessing if hovering in our out of the tooltip base is intentional
      or not.
      
      To figure this out, a few different techniques are used:
      
      * When the mouse pointer enters a tooltip anchor point, its hitbox
        is grown on the bottom, where the popover is/will appear. This was
        already there before this commit: search "hover tunnel" in
        rustdoc.css for the implementation.
      
      * This commit adds a delay when the mouse pointer enters the base
        anchor, in case the mouse pointer was just passing through and the
        user didn't want to open it.
      
      * This commit also adds a delay when the mouse pointer exits the
        tooltip's base anchor or its popover, before hiding it.
      
      * A fade-out animation is layered onto the pointer exit delay to
        immediately inform the user that they successfully dismissed the
        popover, while still providing a way for them to cancel it if
        it was a mistake and they still wanted to interact with it.
      
      * No animation is used for revealing it, because we don't want
        people to try to interact with an element while it's in the
        middle of fading in: either they're allowed to interact with
        it while it's fading in, meaning it can't serve as mistake-
        proofing for opening the popover, or they can't, but they
        might try and be frustrated.
      
      See also:
      
      * https://www.nngroup.com/articles/timing-exposing-content/
      * https://www.nngroup.com/articles/tooltip-guidelines/
      * https://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown
      c1d72de0