1. 13 3月, 2022 2 次提交
  2. 11 3月, 2022 1 次提交
    • N
      Improve `AdtDef` interning. · ca5525d5
      Nicholas Nethercote 提交于
      This commit makes `AdtDef` use `Interned`. Much the commit is tedious
      changes to introduce getter functions. The interesting changes are in
      `compiler/rustc_middle/src/ty/adt.rs`.
      ca5525d5
  3. 09 3月, 2022 3 次提交
  4. 08 3月, 2022 6 次提交
  5. 02 3月, 2022 1 次提交
  6. 01 3月, 2022 1 次提交
  7. 25 2月, 2022 2 次提交
  8. 23 2月, 2022 2 次提交
  9. 21 2月, 2022 3 次提交
    • L
      use `List<Ty<'tcx>>` for tuples · 1245131a
      lcnr 提交于
      1245131a
    • M
      Revert "Auto merge of #93800 - b-naber:static-initializers-mir-val, r=oli-obk" · 9f762148
      Mark Rousskov 提交于
      This reverts commit a240ccd8, reversing
      changes made to 393fdc10.
      
      This PR was likely responsible for a relatively large regression in
      dist-x86_64-msvc-alt builder times, from approximately 1.7 to 2.8 hours,
      bringing that builder into the pool of the slowest builders we currently have.
      
      This seems to be limited to the alt builder due to needing parallel-compiler
      enabled, likely leading to slow LLVM compilation for some reason.
      9f762148
    • F
      Improve `unused_unsafe` lint · 8f8689fb
      Frank Steffahn 提交于
      Main motivation: Fixes some issues with the current behavior. This PR is
      more-or-less completely re-implementing the unused_unsafe lint; it’s also only
      done in the MIR-version of the lint, the set of tests for the `-Zthir-unsafeck`
      version no longer succeeds (and is thus disabled, see `lint-unused-unsafe.rs`).
      
      On current nightly,
      ```rs
      unsafe fn unsf() {}
      
      fn inner_ignored() {
          unsafe {
              #[allow(unused_unsafe)]
              unsafe {
                  unsf()
              }
          }
      }
      ```
      
      doesn’t create any warnings. This situation is not unrealistic to come by, the
      inner `unsafe` block could e.g. come from a macro. Actually, this PR even
      includes removal of one unused `unsafe` in the standard library that was missed
      in a similar situation. (The inner `unsafe` coming from an external macro hides
          the warning, too.)
      
      The reason behind this problem is how the check currently works:
      * While generating MIR, it already skips nested unsafe blocks (i.e. unsafe
        nested in other unsafe) so that the inner one is always the one considered
        unused
      * To differentiate the cases of no unsafe operations inside the `unsafe` vs.
        a surrounding `unsafe` block, there’s some ad-hoc magic walking up the HIR to
        look for surrounding used `unsafe` blocks.
      
      There’s a lot of problems with this approach besides the one presented above.
      E.g. the MIR-building uses checks for `unsafe_op_in_unsafe_fn` lint to decide
      early whether or not `unsafe` blocks in an `unsafe fn` are redundant and ought
      to be removed.
      ```rs
      unsafe fn granular_disallow_op_in_unsafe_fn() {
          unsafe {
              #[deny(unsafe_op_in_unsafe_fn)]
              {
                  unsf();
              }
          }
      }
      ```
      ```
      error: call to unsafe function is unsafe and requires unsafe block (error E0133)
        --> src/main.rs:13:13
         |
      13 |             unsf();
         |             ^^^^^^ call to unsafe function
         |
      note: the lint level is defined here
        --> src/main.rs:11:16
         |
      11 |         #[deny(unsafe_op_in_unsafe_fn)]
         |                ^^^^^^^^^^^^^^^^^^^^^^
         = note: consult the function's documentation for information on how to avoid undefined behavior
      
      warning: unnecessary `unsafe` block
        --> src/main.rs:10:5
         |
      9  | unsafe fn granular_disallow_op_in_unsafe_fn() {
         | --------------------------------------------- because it's nested under this `unsafe` fn
      10 |     unsafe {
         |     ^^^^^^ unnecessary `unsafe` block
         |
         = note: `#[warn(unused_unsafe)]` on by default
      
      ```
      Here, the intermediate `unsafe` was ignored, even though it contains a unsafe
      operation that is not allowed to happen in an `unsafe fn` without an additional `unsafe` block.
      
      Also closures were problematic and the workaround/algorithms used on current
      nightly didn’t work properly. (I skipped trying to fully understand what it was
      supposed to do, because this PR uses a completely different approach.)
      ```rs
      fn nested() {
          unsafe {
              unsafe { unsf() }
          }
      }
      ```
      ```
      warning: unnecessary `unsafe` block
        --> src/main.rs:10:9
         |
      9  |     unsafe {
         |     ------ because it's nested under this `unsafe` block
      10 |         unsafe { unsf() }
         |         ^^^^^^ unnecessary `unsafe` block
         |
         = note: `#[warn(unused_unsafe)]` on by default
      ```
      
      vs
      
      ```rs
      fn nested() {
          let _ = || unsafe {
              let _ = || unsafe { unsf() };
          };
      }
      ```
      ```
      warning: unnecessary `unsafe` block
       --> src/main.rs:9:16
        |
      9 |     let _ = || unsafe {
        |                ^^^^^^ unnecessary `unsafe` block
        |
        = note: `#[warn(unused_unsafe)]` on by default
      
      warning: unnecessary `unsafe` block
        --> src/main.rs:10:20
         |
      10 |         let _ = || unsafe { unsf() };
         |                    ^^^^^^ unnecessary `unsafe` block
      ```
      
      *note that this warning kind-of suggests that **both** unsafe blocks are redundant*
      
      --------------------------------------------------------------------------------
      
      I also dislike the fact that it always suggests keeping the outermost `unsafe`.
      E.g. for
      ```rs
      fn granularity() {
          unsafe {
              unsafe { unsf() }
              unsafe { unsf() }
              unsafe { unsf() }
          }
      }
      ```
      I prefer if `rustc` suggests removing the more-course outer-level `unsafe`
      instead of the fine-grained inner `unsafe` blocks, which it currently does on nightly:
      ```
      warning: unnecessary `unsafe` block
        --> src/main.rs:10:9
         |
      9  |     unsafe {
         |     ------ because it's nested under this `unsafe` block
      10 |         unsafe { unsf() }
         |         ^^^^^^ unnecessary `unsafe` block
         |
         = note: `#[warn(unused_unsafe)]` on by default
      
      warning: unnecessary `unsafe` block
        --> src/main.rs:11:9
         |
      9  |     unsafe {
         |     ------ because it's nested under this `unsafe` block
      10 |         unsafe { unsf() }
      11 |         unsafe { unsf() }
         |         ^^^^^^ unnecessary `unsafe` block
      
      warning: unnecessary `unsafe` block
        --> src/main.rs:12:9
         |
      9  |     unsafe {
         |     ------ because it's nested under this `unsafe` block
      ...
      12 |         unsafe { unsf() }
         |         ^^^^^^ unnecessary `unsafe` block
      ```
      
      --------------------------------------------------------------------------------
      
      Needless to say, this PR addresses all these points. For context, as far as my
      understanding goes, the main advantage of skipping inner unsafe blocks was that
      a test case like
      ```rs
      fn top_level_used() {
          unsafe {
              unsf();
              unsafe { unsf() }
              unsafe { unsf() }
              unsafe { unsf() }
          }
      }
      ```
      should generate some warning because there’s redundant nested `unsafe`, however
      every single `unsafe` block _does_ contain some statement that uses it. Of course
      this PR doesn’t aim change the warnings on this kind of code example, because
      the current behavior, warning on all the inner `unsafe` blocks, makes sense in this case.
      
      As mentioned, during MIR building all the unsafe blocks *are* kept now, and usage
      is attributed to them. The way to still generate a warning like
      ```
      warning: unnecessary `unsafe` block
        --> src/main.rs:11:9
         |
      9  |     unsafe {
         |     ------ because it's nested under this `unsafe` block
      10 |         unsf();
      11 |         unsafe { unsf() }
         |         ^^^^^^ unnecessary `unsafe` block
         |
         = note: `#[warn(unused_unsafe)]` on by default
      
      warning: unnecessary `unsafe` block
        --> src/main.rs:12:9
         |
      9  |     unsafe {
         |     ------ because it's nested under this `unsafe` block
      ...
      12 |         unsafe { unsf() }
         |         ^^^^^^ unnecessary `unsafe` block
      
      warning: unnecessary `unsafe` block
        --> src/main.rs:13:9
         |
      9  |     unsafe {
         |     ------ because it's nested under this `unsafe` block
      ...
      13 |         unsafe { unsf() }
         |         ^^^^^^ unnecessary `unsafe` block
      ```
      
      in this case is by emitting a `unused_unsafe` warning for all of the `unsafe`
      blocks that are _within a **used** unsafe block_.
      
      The previous code had a little HIR traversal already anyways to collect a set of
      all the unsafe blocks (in order to afterwards determine which ones are unused
      afterwards). This PR uses such a traversal to do additional things including logic
      like _always_ warn for an `unsafe` block that’s inside of another **used**
      unsafe block. The traversal is expanded to include nested closures in the same go,
      this simplifies a lot of things.
      
      The whole logic around `unsafe_op_in_unsafe_fn` is a little complicated, there’s
      some test cases of corner-cases in this PR. (The implementation involves
      differentiating between whether a used unsafe block was used exclusively by
      operations where `allow(unsafe_op_in_unsafe_fn)` was active.) The main goal was
      to make sure that code should compile successfully if all the `unused_unsafe`-warnings
      are addressed _simultaneously_ (by removing the respective `unsafe` blocks)
      no matter how complicated the patterns of `unsafe_op_in_unsafe_fn` being
      disallowed and allowed throughout the function are.
      
      --------------------------------------------------------------------------------
      
      One noteworthy design decision I took here: An `unsafe` block
      with `allow(unused_unsafe)` **is considered used** for the purposes of
      linting about redundant contained unsafe blocks. So while
      ```rs
      
      fn granularity() {
          unsafe { //~ ERROR: unnecessary `unsafe` block
              unsafe { unsf() }
              unsafe { unsf() }
              unsafe { unsf() }
          }
      }
      ```
      warns for the outer `unsafe` block,
      ```rs
      
      fn top_level_ignored() {
          #[allow(unused_unsafe)]
          unsafe {
              #[deny(unused_unsafe)]
              {
                  unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
                  unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
                  unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
              }
          }
      }
      ```
      warns on the inner ones.
      8f8689fb
  10. 20 2月, 2022 1 次提交
  11. 17 2月, 2022 1 次提交
  12. 16 2月, 2022 2 次提交
  13. 15 2月, 2022 3 次提交
    • N
      Overhaul `Const`. · a95fb8b1
      Nicholas Nethercote 提交于
      Specifically, rename the `Const` struct as `ConstS` and re-introduce `Const` as
      this:
      ```
      pub struct Const<'tcx>(&'tcx Interned<ConstS>);
      ```
      This now matches `Ty` and `Predicate` more closely, including using
      pointer-based `eq` and `hash`.
      
      Notable changes:
      - `mk_const` now takes a `ConstS`.
      - `Const` was copy, despite being 48 bytes. Now `ConstS` is not, so need a
        we need separate arena for it, because we can't use the `Dropless` one any
        more.
      - Many `&'tcx Const<'tcx>`/`&Const<'tcx>` to `Const<'tcx>` changes
      - Many `ct.ty` to `ct.ty()` and `ct.val` to `ct.val()` changes.
      - Lots of tedious sigil fiddling.
      a95fb8b1
    • N
      Overhaul `RegionKind` and `Region`. · 7024dc52
      Nicholas Nethercote 提交于
      Specifically, change `Region` from this:
      ```
      pub type Region<'tcx> = &'tcx RegionKind;
      ```
      to this:
      ```
      pub struct Region<'tcx>(&'tcx Interned<RegionKind>);
      ```
      
      This now matches `Ty` and `Predicate` more closely.
      
      Things to note
      - Regions have always been interned, but we haven't been using pointer-based
        `Eq` and `Hash`. This is now happening.
      - I chose to impl `Deref` for `Region` because it makes pattern matching a lot
        nicer, and `Region` can be viewed as just a smart wrapper for `RegionKind`.
      - Various methods are moved from `RegionKind` to `Region`.
      - There is a lot of tedious sigil changes.
      - A couple of types like `HighlightBuilder`, `RegionHighlightMode` now have a
        `'tcx` lifetime because they hold a `Ty<'tcx>`, so they can call `mk_region`.
      - A couple of test outputs change slightly, I'm not sure why, but the new
        outputs are a little better.
      7024dc52
    • N
      Overhaul `TyS` and `Ty`. · e9a0c429
      Nicholas Nethercote 提交于
      Specifically, change `Ty` from this:
      ```
      pub type Ty<'tcx> = &'tcx TyS<'tcx>;
      ```
      to this
      ```
      pub struct Ty<'tcx>(Interned<'tcx, TyS<'tcx>>);
      ```
      There are two benefits to this.
      - It's now a first class type, so we can define methods on it. This
        means we can move a lot of methods away from `TyS`, leaving `TyS` as a
        barely-used type, which is appropriate given that it's not meant to
        be used directly.
      - The uniqueness requirement is now explicit, via the `Interned` type.
        E.g. the pointer-based `Eq` and `Hash` comes from `Interned`, rather
        than via `TyS`, which wasn't obvious at all.
      
      Much of this commit is boring churn. The interesting changes are in
      these files:
      - compiler/rustc_middle/src/arena.rs
      - compiler/rustc_middle/src/mir/visit.rs
      - compiler/rustc_middle/src/ty/context.rs
      - compiler/rustc_middle/src/ty/mod.rs
      
      Specifically:
      - Most mentions of `TyS` are removed. It's very much a dumb struct now;
        `Ty` has all the smarts.
      - `TyS` now has `crate` visibility instead of `pub`.
      - `TyS::make_for_test` is removed in favour of the static `BOOL_TY`,
        which just works better with the new structure.
      - The `Eq`/`Ord`/`Hash` impls are removed from `TyS`. `Interned`s impls
        of `Eq`/`Hash` now suffice. `Ord` is now partly on `Interned`
        (pointer-based, for the `Equal` case) and partly on `TyS`
        (contents-based, for the other cases).
      - There are many tedious sigil adjustments, i.e. adding or removing `*`
        or `&`. They seem to be unavoidable.
      e9a0c429
  14. 12 2月, 2022 2 次提交
  15. 11 2月, 2022 1 次提交
  16. 10 2月, 2022 1 次提交
  17. 03 2月, 2022 1 次提交
  18. 02 2月, 2022 2 次提交
  19. 01 2月, 2022 1 次提交
  20. 30 1月, 2022 1 次提交
  21. 26 1月, 2022 1 次提交
    • T
      Ignore unwinding edges when checking for unconditional recursion · 10b722cc
      Tomasz Miąsko 提交于
      The unconditional recursion lint determines if all execution paths
      eventually lead to a self-recursive call.
      
      The implementation always follows unwinding edges which limits its
      practical utility. For example, it would not lint function `f` because a
      call to `g` might unwind. It also wouldn't lint function `h` because an
      overflow check preceding the self-recursive call might unwind:
      
      ```rust
      pub fn f() {
          g();
          f();
      }
      
      pub fn g() { /* ... */ }
      
      pub fn h(a: usize) {
        h(a + 1);
      }
      ```
      
      To avoid the issue, assume that terminators that might continue
      execution along non-unwinding edges do so.
      10b722cc
  22. 21 1月, 2022 1 次提交
  23. 19 1月, 2022 1 次提交