Some would argue that this 40-character method name is ludicrously
unwieldy (even ironic), but it's the unique continuation of the
precedent set by the other suggestion methods. (And there is some hope
that someday we'll just fold `Applicability` into the signature of the
"basic" method `span_suggestion`.)
bors [Sun, 20 May 2018 08:55:50 +0000 (08:55 +0000)]
Auto merge of #50855 - nnethercote:fewer-macro_parser-allocs, r=petrochenkov
Speed up the macro parser
These three commits reduce the number of allocations done by the macro parser, in some cases dramatically. For example, for a clean check builds of html5ever, the number of allocations is reduced by 40%.
Here are the rustc-benchmarks that are sped up by at least 1%.
```
html5ever-check
avg: -6.6% min: -10.3% max: -4.1%
html5ever
avg: -5.2% min: -9.5% max: -2.8%
html5ever-opt
avg: -4.3% min: -9.3% max: -1.6%
crates.io-check
avg: -1.8% min: -2.9% max: -0.6%
crates.io-opt
avg: -1.0% min: -2.2% max: -0.1%
crates.io
avg: -1.1% min: -2.2% max: -0.2%
```
bors [Sun, 20 May 2018 05:57:41 +0000 (05:57 +0000)]
Auto merge of #50820 - alexcrichton:no-modules, r=petrochenkov
rustc: Disallow modules and macros in expansions
This commit feature gates generating modules and macro definitions in procedural
macro expansions. Custom derive is exempt from this check as it would be a large
retroactive breaking change (#50587). It's hoped that we can hopefully stem the
bleeding to figure out a better solution here before opening up the floodgates.
The restriction here is specifically targeted at surprising hygiene results [1]
that result in non-"copy/paste" behavior. Hygiene and procedural macros is
intended to be avoided as much as possible for Macros 1.2 by saying everything
is "as if you copy/pasted the code", but modules and macros are sort of weird
exceptions to this rule that aren't fully fleshed out.
bors [Sat, 19 May 2018 22:33:57 +0000 (22:33 +0000)]
Auto merge of #50893 - kennytm:rollup, r=kennytm
Rollup of 8 pull requests
Successful merges:
- #50531 (Cleanup uses of TypeIdHasher and replace them with StableHasher)
- #50819 (Fix potential divide by zero)
- #50827 (Update LLVM to 56c931901cfb85cd6f7ed44c7d7520a8de1edf97)
- #50829 (CheckLoopVisitor: also visit break expressions)
- #50854 (in which the unused shorthand field pattern debacle/saga continues)
- #50858 (Reorder description for snippets in rustdoc documentation)
- #50883 (Fix warning when building stage0 libcore)
- #50889 (Update clippy)
kennytm [Sat, 19 May 2018 20:17:41 +0000 (04:17 +0800)]
Rollup merge of #50819 - cjkenn:cjkenn/div-by-zero, r=kennytm
Fix potential divide by zero
This should fix #50761
I had trouble reproducing with the provided code, but looking at the stack trace would indicate that this code is the likely cause. I made a number of assumptions here, because I don't have enough context on how the register size is set:
1. I assumed `rest.unit.size.bytes()` can be 0, and it's ok if it's set to 0 before this function is called
2. I assumed that if `rest.unit.size.bytes()` is 0, that we want `rest_count` to also be 0.
kennytm [Sat, 19 May 2018 15:41:04 +0000 (23:41 +0800)]
Rollup merge of #50858 - robinkrahl:rustdoc-fix-order, r=steveklabnik
Reorder description for snippets in rustdoc documentation
The example code snippets for the `no_run` and `compile_fail` attributes in the rustdoc documentation were followed by the description for the wrong attribute. This patch reorders the descriptions to match the code snippets.
kennytm [Sat, 19 May 2018 15:41:03 +0000 (23:41 +0800)]
Rollup merge of #50854 - zackmdavis:and_the_case_of_the_unused_field_pattern_3_straight_to_video, r=estebank
in which the unused shorthand field pattern debacle/saga continues
In e4b1a79 (#47922), we corrected erroneous suggestions for unused
shorthand field pattern bindings, suggesting `field: _` where the
previous suggestion of `_field` wouldn't even have compiled
(#47390). Soon, it was revealed that this was insufficient (#50303), and
the fix was extended to references, slices, &c. (#50327) But even this
proved inadequate, as the erroneous suggestions were still being issued
for patterns in local (`let`) bindings (#50804). Here, we yank the
shorthand-detection and variable/node registration code into a new
common function that can be called while visiting both match arms and
`let` bindings.
bors [Sat, 19 May 2018 14:52:30 +0000 (14:52 +0000)]
Auto merge of #50763 - KyleStach1678:unused-loop-label, r=petrochenkov
Add lint checks for unused loop labels
Previously no warning was generated when a loop label was written out but never used (i.e. in a `break` or `continue` statement):
```rust
fn main() {
'unused_label: loop {}
}
```
would compile without complaint.
This fix introduces `-W unused_loop_label`, which generates the following warning message for the above snippet:
```
warning: unused loop label
--> main.rs:2:5
|
2 | 'unused_label: loop {}
| ^^^^^^^^^^^^^
|
= note: #[warn(unused_loop_label)] on by default
```
The lint was introduced in Dec 2016, then made deny-by-default in Jun 2017 when crater run found 0 regressions caused by it.
This lint requires some not entirely trivial amount of import resolution logic that (surprisingly or not) interacts with `feature(use_extern_macros)` (https://github.com/rust-lang/rust/issues/35896), so it would be desirable to remove it before stabilizing `use_extern_macros`.
In particular, this PR fixes the failing example in https://github.com/rust-lang/rust/issues/50725 (but not the whole issue, `use std::panic::{self}` still can cause other undesirable errors when `use_extern_macros` is enabled).
bors [Sat, 19 May 2018 07:42:03 +0000 (07:42 +0000)]
Auto merge of #50744 - nikic:mutable-noalias, r=alexcrichton
Emit noalias on &mut parameters by default
This used to be disabled due to LLVM bugs in the handling of
noalias information in conjunction with unwinding. However,
according to #31681 all known LLVM bugs have been fixed by
LLVM 6.0, so it's probably time to reenable this optimization.
-Z no-mutable-noalias is left as an escape-hatch to debug problems
suspected to stem from this change.
bors [Sat, 19 May 2018 03:10:53 +0000 (03:10 +0000)]
Auto merge of #50709 - alexcrichton:revert-musl, r=sfackler
Revert #50105 until regression is fixed
Discovered at https://github.com/rust-lang/rust/pull/50105#issuecomment-388630750 it looks like this caused a regression with i686 musl, so let's revert in the meantime while a fix is worked out
bors [Fri, 18 May 2018 21:49:38 +0000 (21:49 +0000)]
Auto merge of #50319 - nagisa:align_to, r=alexcrichton
Implement [T]::align_to
Note that this PR deviates from what is accepted by RFC slightly by making `align_offset` to return an offset in elements, rather than bytes. This is necessary to sanely support `[T]::align_to` and also simply makes more sense™. The caveat is that trying to align a pointer of ZST is now an equivalent to `is_aligned` check, rather than anything else (as no number of ZST elements will align a misaligned ZST pointer).
It also implements the `align_to` slightly differently than proposed in the RFC to properly handle cases where size of T and U aren’t co-prime.
Furthermore, a promise is made that the slice containing `U`s will be as large as possible (contrary to the RFC) – otherwise the function is quite useless.
The implementation uses quite a few underhanded tricks and takes advantage of the fact that alignment is a power-of-two quite heavily to optimise the machine code down to something that results in as few known-expensive instructions as possible. Currently calling `ptr.align_offset` with an unknown-at-compile-time `align` results in code that has just a single "expensive" modulo operation; the rest is "cheap" arithmetic and bitwise ops.
cc https://github.com/rust-lang/rust/issues/44488 @oli-obk
As mentioned in the commit message for align_offset, many thanks go to Chris McDonald.
Alex Crichton [Wed, 9 May 2018 22:03:02 +0000 (15:03 -0700)]
rustc: Disallow modules and macros in expansions
This commit feature gates generating modules and macro definitions in procedural
macro expansions. Custom derive is exempt from this check as it would be a large
retroactive breaking change (#50587). It's hoped that we can hopefully stem the
bleeding to figure out a better solution here before opening up the floodgates.
The restriction here is specifically targeted at surprising hygiene results [1]
that result in non-"copy/paste" behavior. Hygiene and procedural macros is
intended to be avoided as much as possible for Macros 1.2 by saying everything
is "as if you copy/pasted the code", but modules and macros are sort of weird
exceptions to this rule that aren't fully fleshed out.
bors [Fri, 18 May 2018 17:17:35 +0000 (17:17 +0000)]
Auto merge of #50653 - oli-obk:bad_const, r=cramertj
Make the `const_err` lint `deny`-by-default
At best these things are runtime panics (debug mode) or overflows (release mode). More likely they are public constants that are unused in the crate declaring them.
This is not a breaking change, as dependencies won't break and root crates can `#![warn(const_err)]`, though I don't know why anyone would do that.
Robin Krahl [Fri, 18 May 2018 12:09:15 +0000 (14:09 +0200)]
Reorder description for snippets in rustdoc documentation
The example code snippets for the `no_run` and `compile_fail` attributes
in the rustdoc documentation were followed by the description for the
wrong attribute. This patch reorders the descriptions to match the code
snippets.
Zack M. Davis [Fri, 18 May 2018 07:07:31 +0000 (00:07 -0700)]
in which the unused shorthand field pattern debacle/saga continues
In e4b1a79 (#47922), we corrected erroneous suggestions for unused
shorthand field pattern bindings, suggesting `field: _` where the
previous suggestion of `_field` wouldn't even have compiled
(#47390). Soon, it was revealed that this was insufficient (#50303), and
the fix was extended to references, slices, &c. (#50327) But even this
proved inadequate, as the erroneous suggestions were still being issued
for patterns in local (`let`) bindings (#50804). Here, we yank the
shorthand-detection and variable/node registration code into a new
common function that can be called while visiting both match arms and
`let` bindings.
bors [Thu, 17 May 2018 21:36:43 +0000 (21:36 +0000)]
Auto merge of #50593 - nikomatsakis:nll-no-location, r=nikomatsakis
stop considering location when computing outlives relationships
This doesn't (yet?) use SEME regions, but it does ignore the location for outlives constraints. This makes (I believe) NLL significantly faster -- but we should do some benchmarks. It regresses the "get-default" family of use cases for NLL, which is a shame, but keeps the other benefits, and thus represents a decent step forward.
iancormac84 [Tue, 8 May 2018 11:52:01 +0000 (07:52 -0400)]
Removed use of TypeIdHasher in debuginfo and replaced it with StableHasher. Also corrected erroneous mention of TypeIdHasher in implementation of HashStable trait.
Nikita Popov [Mon, 14 May 2018 13:20:51 +0000 (15:20 +0200)]
Emit noalias on &mut parameters by default
This used to be disabled due to LLVM bugs in the handling of
noalias information in conjunction with unwinding. However,
according to #31681 all known LLVM bugs have been fixed by
LLVM 6.0, so it's probably time to reenable this optimization.
Noalias annotations will not be emitted by default if either
-C panic=abort (as previously) or LLVM >= 6.0 (new).
-Z mutable-noalias=no is left as an escape-hatch to allow
debugging problems suspected to stem from this change.
Keep only the language item. This removes some indirection and makes
codegen worse for debug builds, but simplifies code significantly, which
is a good tradeoff to make, in my opinion.
Besides, the codegen can be improved even further with some constant
evaluation improvements that we expect to happen in the future.