bors [Sat, 15 Jun 2019 18:24:18 +0000 (18:24 +0000)]
Auto merge of #61868 - Centril:rollup-gglsecp, r=Centril
Rollup of 6 pull requests
Successful merges:
- #61785 (note some safety concerns of raw-ptr-to-ref casts)
- #61805 (typeck: Fix ICE for blocks in repeat expr count.)
- #61813 (Remove some unnecessary symbol interner ops)
- #61824 (in which we decline to lint single-use lifetimes in `derive`d impls)
- #61844 (Change `...` to `..=` where applicable)
- #61854 (Minor cosmetic improvements to accompany PR 61825)
Rollup merge of #61844 - AaronKutch:master, r=Centril
Change `...` to `..=` where applicable
This is mainly to fix #61816, but I decided to manually check a few thousand `...` throughout the code base to check for any other cases. I think I found a documentation bug in `src\libsyntax\ast.rs` where both `1..` and `1...` where mentioned. If there is internal support for both `1..` and `1..=` (that can exist before error handling gets to it), then I can add that back.
There were some other cases that look like `// struct Closure<'l0...'li, T0...Tj, CK, CS, U0...Uk> {`, `// <P0 as Trait<P1...Pn>>::Foo: 'a`, and `assert!(min <= max, "discriminant range is {}...{}", min, max);`, but I am not sure if I should change those.
There are a bunch of cases in the `/test/` directory that could be changed, but I presume I should just leave those be.
Rollup merge of #61813 - matthewjasper:remove-unnecessary-symbol-ops, r=petrochenkov
Remove some unnecessary symbol interner ops
* Don't gensym symbols that don't need to worry about colliding with other symbols
* Use symbol constants instead of interning string literals in a few places.
* Don't generate a module in `__register_diagnostic`
Rollup merge of #61805 - davidtwco:ice-const-generic-repeat-expr-count-sequel, r=varkor
typeck: Fix ICE for blocks in repeat expr count.
Fixes #61336 (again). This PR fixes an ICE that occured when a block expression resolving to a const generic was used for the count of an array repeat expression.
bors [Sat, 15 Jun 2019 03:47:55 +0000 (03:47 +0000)]
Auto merge of #61825 - Centril:tauv-infer-fix, r=petrochenkov
type_alias_enum_variants: fix #61801; allow a path pattern to infer
Fix #61801.
Given a type-relative path pattern referring to an enum variant through a type alias, allow inferring the generic argument applied in the expectation set by the scrutinee of a `match` expression.
Similar issues may exist for `let` statements but I don't know how to test for that since `PhantomData<T>` is necessary...)
The gist of the problem here was that `resolve_ty_and_res_ufcs` was called twice which is apparently no good... It is possible that this PR is papering over some deeper problem, but that is beyond my knowledge of the compiler.
r? @petrochenkov
cc @eddyb @alexreg
cc https://github.com/rust-lang/rust/pull/61682
cc https://github.com/rust-lang/rust/issues/49683
Alex Crichton [Fri, 14 Jun 2019 16:53:59 +0000 (09:53 -0700)]
Turn down the myriad-closures test
This tests takes nearly 5 minutes to compile on CI where the CPUs we
have aren't exactly the fastest. This test does actually require all
closures to exist to exhibit the original bug, but it seems a little
excessive to test a single bug on CI on all platforms which simply pegs
a single CPU for 5 minutes with no parallelism opportunities, so this
turns down the test to still exercise it somewhat at least.
bors [Fri, 14 Jun 2019 16:20:35 +0000 (16:20 +0000)]
Auto merge of #61817 - eddyb:begone-gcx-attempt-2, r=oli-obk
Unify all uses of 'gcx and 'tcx.
This is made possible by @Zoxc landing #57214 (see https://github.com/rust-lang/rust/pull/57214#issuecomment-465036053 for the decision).
A bit of context for the approach: just like #61722, this is *not* how I originally intended to go about this, but @Zoxc and my own experimentation independently resulted in the same conclusion:
The interim alias `type TyCx<'tcx> = TyCtxt<'tcx, 'tcx>;` attempt required more work (adding `use`s), even only for handling the `TyCtxt<'tcx, 'tcx>` case and not the general `TyCtxt<'gcx, 'tcx>` one.
What this PR is based on is the realization that `'gcx` is a special-enough name that it can be replaced, without caring for context, with `'tcx`, and then repetitions of the name `'tcx` be compacted away.
After that, only a small number of error categories remained, each category easily dealt with with either more mass replacements (e.g. `TyCtxt<'tcx, '_>` -> `TyCtxt<'tcx>`) or by hand.
For the `rustfmt` commit, I used https://github.com/rust-lang/rustfmt/issues/1324#issuecomment-482109952, and manually filtered out some noise, like in #61735 and #61722, and like the latter, there was also a weird bug to work around.
It should be reviewed separately, and dropped if unwanted (in this PR it's pretty significant).
bors [Fri, 14 Jun 2019 12:37:28 +0000 (12:37 +0000)]
Auto merge of #61421 - vorner:string-in-rc-into-raw-docs, r=RalfJung
docs: Use String in Rc::into_raw examples
It is unclear if accessing an integer after `drop_in_place` has been
called on it is undefined behaviour or not, as demonstrated by the
discussion in
https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222.
Avoid these uncertainties by using String which frees memory in its
`drop_in_place` to make sure this is undefined behaviour. The message in
the docs should be to watch out and not access the data after that, not
discussing when one maybe could get away with it O:-).
Felix S Klock II [Fri, 14 Jun 2019 10:19:26 +0000 (12:19 +0200)]
put back the workarounds for #60846
based on https://github.com/rust-lang/rust/pull/61754#issuecomment-501743750 I am adding `bootstrap` to the cfg-preconditions for the two manual `unsafe impls`'s of `Send` and `Sync` for `TokenTree`.
bors [Fri, 14 Jun 2019 09:39:17 +0000 (09:39 +0000)]
Auto merge of #61679 - zackmdavis:maybe_dont_indicate_the_anonymous_lifetime, r=oli-obk
in which we decline to suggest the anonymous lifetime in declarations
The elided-lifetimes-in-path lint (part of our suite of Rust 2018 idiom lints which we are hoping to promote to Warn status) was firing with an illegal suggestion to write an anonymous lifetime in a
struct/item declaration (where we don't allow it). The linting code was already deciding whether to act on the basis of a `ParamMode` enum, indicating whether the present path-segment was part of an
expression, or anywhere else. The present case seemed to be part of the "anywhere else", and yet meriting different rules as far as the lint was concerned, so it seemed expedient to introduce a new enum member. We yank out `TyKind::Path` arm into its own method so that we can call it with our new `ParamMode` specifically when lowering struct fields—one would have hoped to think of something more elegant than this, but it definitely beats changing the signature of `lower_ty` to take a `ParamMode`!
Zack M. Davis [Sun, 9 Jun 2019 04:35:02 +0000 (21:35 -0700)]
in which we decline to suggest the anonymous lifetime in declarations
The elided-lifetimes-in-path lint (part of our suite of Rust 2018
idiom lints which we are hoping to promote to Warn status) was firing
with an illegal suggestion to write an anonymous lifetime in a
struct/item declaration (where we don't allow it). The linting code
was already deciding whether to act on the basis of a `ParamMode`
enum, indicating whether the present path-segment was part of an
expression, or anywhere else. The present case seemed to be part of
the "anywhere else", and yet meriting different rules as far as the
lint was concerned, so it seemed expedient to introduce a new enum
member. We yank out a `TyKind::Path` arm into its own method so that
we can call it with our new `ParamMode` specifically when lowering
struct fields. (The alternative strategy of changing the signature of
`lower_ty` to take a `ParamMode` would be inelegant given that most of
the `TyKind` match arm bodies therein don't concern themselves with
`ParamMode`.)
David Wood [Thu, 13 Jun 2019 16:19:50 +0000 (17:19 +0100)]
typeck: Fix ICE for blocks in repeat expr count.
This commit extends the work in #61698 to get the `DefId` of const
parameters from block that resolve to a const parameter (as well as
const parameters directly, as it was previously).
Matthew Jasper [Sat, 25 May 2019 16:11:27 +0000 (17:11 +0100)]
Generate MIR thats easier for llvm for str matches
LLVM appears to prefer (spend less time optimizing) long if chains if
it receives them in approzimately source order.
This fixes a ~10% regression for optimized builds of the encoding benchmark
on perf.rlo due to the changes to decision tree construction.
bors [Thu, 13 Jun 2019 15:44:58 +0000 (15:44 +0000)]
Auto merge of #61772 - alexcrichton:pr-and-master-builds, r=pietroalbini
ci: Enable toolstate tracking on Azure
Currently just run it through its paces but don't actually push to
official locations. Instead let's just push to a separate fork (mine) as
well as open issues in a separate fork (mine). Make sure that people
aren't pinged for these issues as well!
This should hopefully ensure that everything is working on Azure and
give us a chance to work through any issues that come up.
Mark Rousskov [Fri, 7 Jun 2019 17:15:45 +0000 (11:15 -0600)]
Inline prepare_tool_cmd
Removing the tool argument in the previous commit means it's no longer
restricted to just bootstrap tools despite being written as such.
Inlining it prevents accidental use.
Alex Crichton [Wed, 12 Jun 2019 14:59:20 +0000 (07:59 -0700)]
ci: Enable toolstate tracking on Azure
Currently just run it through its paces but don't actually push to
official locations. Instead let's just push to a separate fork (mine) as
well as open issues in a separate fork (mine). Make sure that people
aren't pinged for these issues as well!
This should hopefully ensure that everything is working on Azure and
give us a chance to work through any issues that come up.
bors [Thu, 13 Jun 2019 12:52:29 +0000 (12:52 +0000)]
Auto merge of #61799 - Centril:rollup-vpm5uxr, r=Centril
Rollup of 5 pull requests
Successful merges:
- #61598 (Handle index out of bound errors during const eval without panic)
- #61720 (std: Remove internal definitions of `cfg_if!` macro)
- #61757 (Deprecate ONCE_INIT in future 1.38 release)
- #61766 (submodules: update clippy from c0dbd34b to bd33a97c)
- #61791 (Small cleanup in `check_pat_path`)
Changes:
````
Fix implicit_return docs
rustup https://github.com/rust-lang/rust/pull/61758/files
Remove wrong lifetime from LintContext
Workaround for rust-lang/rustfmt#3615
Fixing eta with respect to lazy evaluation.
````
r? @oli-obk
Rollup merge of #61720 - alexcrichton:libstd-cfg-if-dep, r=sfackler
std: Remove internal definitions of `cfg_if!` macro
This is duplicated in a few locations throughout the sysroot to work
around issues with not exporting a macro in libstd but still wanting it
available to sysroot crates to define blocks. Nowadays though we can
simply depend on the `cfg-if` crate on crates.io, allowing us to use it
from there!
It is unclear if accessing an integer after `drop_in_place` has been
called on it is undefined behaviour or not, as demonstrated by the
discussion in
https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222.
Avoid these uncertainties by using String which frees memory in its
`drop_in_place` to make sure this is undefined behaviour. The message in
the docs should be to watch out and not access the data after that, not
discussing when one maybe could get away with it O:-).
Changes:
````
Fix wrong lifetime of TyCtxt
travis: Wait at most 30 minutes for base test
Typos and minor grammar corrections
Adds lint for integer division
redundant_closure_for_method_calls fixes: lint does not trigger when there is a difference in mutability lint does not trigger when the method belongs to a trait which is not implemebted directly (Deref)
Fix implicit_return docs
rustup https://github.com/rust-lang/rust/pull/61758/files
Remove wrong lifetime from LintContext
Workaround for rust-lang/rustfmt#3615
Fixing eta with respect to lazy evaluation.
````
Rollup merge of #61763 - pietroalbini:azure-fix-condition, r=alexcrichton
ci: fix ci stats upload condition
The condition I suggested in #61632 was not correct and it errors out while evaluating. This fixes the condition. [Example of a failure](https://dev.azure.com/rust-lang/rust/_build/results?buildId=543).