1. 13 1月, 2018 2 次提交
  2. 12 1月, 2018 1 次提交
    • B
      Auto merge of #46551 - jseyfried:improve_legacy_modern_macro_interaction, r=nrc · 0b90e4e8
      bors 提交于
      macros: improve 1.0/2.0 interaction
      
      This PR supports using unhygienic macros from hygienic macros without breaking the latter's hygiene.
      ```rust
      // crate A:
      #[macro_export]
      macro_rules! m1 { () => {
          f(); // unhygienic: this macro needs `f` in its environment
          fn g() {} // (1) unhygienic: `g` is usable outside the macro definition
      } }
      
      // crate B:
      #![feature(decl_macro)]
      extern crate A;
      use A::m1;
      
      macro m2() {
          fn f() {} // (2)
          m1!(); // After this PR, `f()` in the expansion resolves to (2), not (3)
          g(); // After this PR, this resolves to `fn g() {}` from the above expansion.
               // Today, it is a resolution error.
      }
      
      fn test() {
          fn f() {} // (3)
          m2!(); // Today, `m2!()` can see (3) even though it should be hygienic.
          fn g() {} // Today, this conflicts with `fn g() {}` from the expansion, even though it should be hygienic.
      }
      ```
      
      Once this PR lands, you can make an existing unhygienic macro hygienic by wrapping it in a hygienic macro. There is an [example](https://github.com/rust-lang/rust/pull/46551/commits/b766fa887dc0e4b923a38751fe4d570e35a75710) of this in the tests.
      
      r? @nrc
      0b90e4e8
  3. 11 1月, 2018 3 次提交
    • B
      Auto merge of #47180 - varkor:range-iterator-overrides, r=alexcrichton · 73ac5d6a
      bors 提交于
      Add iterator method specialisations to Range*
      
      Add specialised implementations of `max` for `Range`, and `last`, `min` and `max` for `RangeInclusive`, all of which lead to significant advantages in the generated assembly on x86.
      
      Note that adding specialisations of `min` and `last` for `Range` led to no benefit, and adding `sum` for `Range` and `RangeInclusive` led to type inference issues (though this is possibly still worthwhile considering the performance gain).
      
      This addresses some of the concerns in #39975.
      73ac5d6a
    • B
      Auto merge of #47087 - Zoxc:incr_no_in_ignore, r=michaelwoerister · 619ced05
      bors 提交于
      Replace uses of DepGraph.in_ignore with DepGraph.with_ignore
      
      I currently plan to track tasks in thread local storage. Ignoring things in a closure ensures that the ignore tasks do not overlap the beginning or end of any other task. The TLS API will also use a closure to change a TLS value, so having the ignore task be a closure also helps there.
      
      It also adds `assert_ignored` which is used before a `TyCtxt` is created. Instead of adding a new ignore task this simply ensures that we are in a context where reads are ignored.
      
      r? @michaelwoerister
      619ced05
    • B
      Auto merge of #47243 - wesleywiser:incr_fingerprint_encoding, r=michaelwoerister · c9c29807
      bors 提交于
      [incremental] Specialize encoding and decoding of Fingerprints
      
      This saves the storage space used by about 32 bits per `Fingerprint`.
      On average, this reduces the size of the `/target/{mode}/incremental`
      folder by roughly 5% [Full details here](https://gist.github.com/wesleywiser/264076314794fbd6a4c110d7c1adc43e).
      
      Fixes #45875
      
      r? @michaelwoerister
      c9c29807
  4. 10 1月, 2018 16 次提交
  5. 09 1月, 2018 15 次提交
  6. 08 1月, 2018 3 次提交