Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 8 pull requests #47993

Closed
wants to merge 20 commits into from
Closed

Rollup of 8 pull requests #47993

wants to merge 20 commits into from

Commits on Jan 30, 2018

  1. update trpl

    steveklabnik committed Jan 30, 2018
    Configuration menu
    Copy the full SHA
    112feb9 View commit details
    Browse the repository at this point in the history
  2. update reference

    steveklabnik committed Jan 30, 2018
    Configuration menu
    Copy the full SHA
    c83566e View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    b9f7564 View commit details
    Browse the repository at this point in the history
  4. Configuration menu
    Copy the full SHA
    a99b5db View commit details
    Browse the repository at this point in the history

Commits on Jan 31, 2018

  1. wherein the parens lint keeps its own counsel re args in nested macros

    In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the
    unused-parens lint was made to check function and method arguments,
    which it previously did not (seemingly due to oversight rather than
    willful design). However, in rust-lang#47775 and discussion thereon,
    user–developers of Geal/nom and graphql-rust/juniper reported that the
    lint was seemingly erroneously triggering on certain complex macros in
    those projects. While this doesn't seem like a bug in the lint in the
    particular strict sense that the expanded code would, in fact, contain
    unncecessary parentheses, it also doesn't seem like the sort of thing
    macro authors should have to think about: the spirit of the
    unused-parens lint is to prevent needless clutter in code, not to give
    macro authors extra heartache in the handling of token trees.
    
    We propose the expediency of declining to lint unused parentheses in
    function or method args inside of nested expansions: we believe that
    this should eliminate the petty, troublesome lint warnings reported
    in the issue, without forgoing the benefits of the lint in simpler
    macros.
    
    It seemed like too much duplicated code for the `Call` and `MethodCall`
    match arms to duplicate the nested-macro check in addition to each
    having their own `for` loop, so this occasioned a slight refactor so
    that the function and method cases could share code—hopefully the
    overall intent is at least no less clear to the gentle reader.
    
    This is concerning rust-lang#47775.
    zackmdavis committed Jan 31, 2018
    Configuration menu
    Copy the full SHA
    5985b0b View commit details
    Browse the repository at this point in the history
  2. update mdbook to 0.1.2

    and improve printing of errors
    steveklabnik committed Jan 31, 2018
    Configuration menu
    Copy the full SHA
    6284b20 View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    e2de8de View commit details
    Browse the repository at this point in the history
  4. Use a range to identify SIGSEGV in stack guards

    Previously, the `guard::init()` and `guard::current()` functions were
    returning a `usize` address representing the top of the stack guard,
    respectively for the main thread and for spawned threads.  The `SIGSEGV`
    handler on `unix` targets checked if a fault was within one page below
    that address, if so reporting it as a stack overflow.
    
    Now `unix` targets report a `Range<usize>` representing the guard
    memory, so it can cover arbitrary guard sizes.  Non-`unix` targets which
    always return `None` for guards now do so with `Option<!>`, so they
    don't pay any overhead.
    
    For `linux-gnu` in particular, the previous guard upper-bound was
    `stackaddr + guardsize`, as the protected memory was *inside* the stack.
    This was a glibc bug, and starting from 2.27 they are moving the guard
    *past* the end of the stack.  However, there's no simple way for us to
    know where the guard page actually lies, so now we declare it as the
    whole range of `stackaddr ± guardsize`, and any fault therein will be
    called a stack overflow.  This fixes rust-lang#47863.
    cuviper committed Jan 31, 2018
    Configuration menu
    Copy the full SHA
    55b54a9 View commit details
    Browse the repository at this point in the history

Commits on Feb 3, 2018

  1. Configuration menu
    Copy the full SHA
    cc68afb View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    6b35d81 View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    abb162c View commit details
    Browse the repository at this point in the history
  4. Configuration menu
    Copy the full SHA
    d597da3 View commit details
    Browse the repository at this point in the history

Commits on Feb 4, 2018

  1. Rollup merge of rust-lang#47753 - steveklabnik:update-book, r=alexcri…

    …chton
    
    Update book
    
    This PR does two things:
    
    1. update the book to include rust-lang/book#1088
    2. update to mdbook 0.1
    
    Both of these things are big changes, so I want to land them now, well before the next branch, so we can kick the tires.
    
    ------------------------------
    
    Locally, I'm seeing some weirdness around the reference and this:
    
    ![image](https://user-images.githubusercontent.com/27786/35411917-8dcbb31a-01e8-11e8-8c30-0bd280d93b9d.png)
    
    Putting this PR up so others can try and build and see if it reproduces for them.
    kennytm authored Feb 4, 2018
    Configuration menu
    Copy the full SHA
    53a459a View commit details
    Browse the repository at this point in the history
  2. Rollup merge of rust-lang#47862 - GuillaumeGomez:const-evaluation-ice…

    …, r=eddyb
    
    Fix const evaluation ICE in rustdoc
    
    Fixes rust-lang#47860.
    
    r? @eddyb
    kennytm authored Feb 4, 2018
    Configuration menu
    Copy the full SHA
    db07acf View commit details
    Browse the repository at this point in the history
  3. Rollup merge of rust-lang#47877 - spastorino:lifetime-bounds-in-copy,…

    … r=nikomatsakis
    
    Do not ignore lifetime bounds in Copy impls
    
    cc rust-lang#29149
    
    r? @nikomatsakis
    kennytm authored Feb 4, 2018
    Configuration menu
    Copy the full SHA
    dd25825 View commit details
    Browse the repository at this point in the history
  4. Rollup merge of rust-lang#47896 - zackmdavis:and_the_case_of_the_nece…

    …ssary_unnecessary_parens, r=nikomatsakis
    
    decline to lint technically-unnecessary parens in function or method arguments inside of nested macros
    
    In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the
    unused-parens lint was made to check function and method arguments,
    which it previously did not (seemingly due to oversight rather than
    willful design). However, in rust-lang#47775 and discussion thereon,
    user–developers of Geal/nom and graphql-rust/juniper reported that the
    lint was seemingly erroneously triggering on certain complex macros in
    those projects. While this doesn't seem like a bug in the lint in the
    particular strict sense that the expanded code would, in fact, contain
    unncecessary parentheses, it also doesn't seem like the sort of thing
    macro authors should have to think about: the spirit of the
    unused-parens lint is to prevent needless clutter in code, not to give
    macro authors extra heartache in the handling of token trees.
    
    We propose the expediency of declining to lint unused parentheses in
    function or method args inside of nested expansions: we believe that
    this should eliminate the petty, troublesome lint warnings reported
    in the issue, without forgoing the benefits of the lint in simpler
    macros.
    
    It seemed like too much duplicated code for the `Call` and `MethodCall`
    match arms to duplicate the nested-macro check in addition to each
    having their own `for` loop, so this occasioned a slight refactor so
    that the function and method cases could share code—hopefully the
    overall intent is at least no less clear to the gentle reader.
    
    This is concerning rust-lang#47775.
    kennytm authored Feb 4, 2018
    Configuration menu
    Copy the full SHA
    724ac28 View commit details
    Browse the repository at this point in the history
  5. Rollup merge of rust-lang#47912 - cuviper:glibc-stack-guard, r=alexcr…

    …ichton
    
    Use a range to identify SIGSEGV in stack guards
    
    Previously, the `guard::init()` and `guard::current()` functions were
    returning a `usize` address representing the top of the stack guard,
    respectively for the main thread and for spawned threads.  The `SIGSEGV`
    handler on `unix` targets checked if a fault was within one page below that
    address, if so reporting it as a stack overflow.
    
    Now `unix` targets report a `Range<usize>` representing the guard memory,
    so it can cover arbitrary guard sizes.  Non-`unix` targets which always
    return `None` for guards now do so with `Option<!>`, so they don't pay any
    overhead.
    
    For `linux-gnu` in particular, the previous guard upper-bound was
    `stackaddr + guardsize`, as the protected memory was *inside* the stack.
    This was a glibc bug, and starting from 2.27 they are moving the guard
    *past* the end of the stack.  However, there's no simple way for us to know
    where the guard page actually lies, so now we declare it as the whole range
    of `stackaddr ± guardsize`, and any fault therein will be called a stack
    overflow.  This fixes rust-lang#47863.
    kennytm authored Feb 4, 2018
    Configuration menu
    Copy the full SHA
    e19c1f1 View commit details
    Browse the repository at this point in the history
  6. Rollup merge of rust-lang#47947 - goodmanjonathan:stabilize_match_beg…

    …inning_vert, r=petrochenkov
    
    Stabilize feature(match_beginning_vert)
    
    With this feature stabilized, match expressions can optionally have a `|` at the beginning of each arm.
    
    Reference PR: rust-lang/reference#231
    
    Closes rust-lang#44101
    kennytm authored Feb 4, 2018
    Configuration menu
    Copy the full SHA
    7af33a4 View commit details
    Browse the repository at this point in the history
  7. Rollup merge of rust-lang#47958 - frewsxcv:frewsxcv-try-clone, r=aidanhs

    Clarify shared file handler behavior of File::try_clone.
    
    Fixes rust-lang#46578.
    kennytm authored Feb 4, 2018
    Configuration menu
    Copy the full SHA
    4e37a8f View commit details
    Browse the repository at this point in the history
  8. Rollup merge of rust-lang#47978 - eddyb:iu, r=kennytm

    ui tests: diff from old (expected) to new (actual) instead of backwards.
    
    Previously `actual` was "old" and `expected` was "new" which resulted in `+` before `-`.
    AFAIK all diff tools put `-` before `+`, which made the previous behavior *very confusing*.
    
    r? @nikomatsakis
    kennytm authored Feb 4, 2018
    Configuration menu
    Copy the full SHA
    cdb05b5 View commit details
    Browse the repository at this point in the history