Rollup merge of #61908 - matklad:overflow, r=petrochenkov
don't ICE on large files
This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.
For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.
Rollup merge of #61893 - chpio:weak_ptr_eq_methods, r=rkruppe
make `Weak::ptr_eq`s into methods
This makes the `Weak::ptr_eq`s associated function into methods. There's no reason for methods on `Weak`s to be associated functions, as there is no `Dered` thus no possibility of a collision. Also: methods can be called using the associated function syntax.
follow up on https://github.com/rust-lang/rust/pull/55987
[Tracking issue for weak_ptr_eq](https://github.com/rust-lang/rust/issues/55981)
Rollup merge of #61836 - ljedrz:i_still_hate_node_ids, r=ljedrz
Replace some uses of NodeId with HirId
We are still using `NodeId` in some spots where we could use `HirId` instead; this PR targets some of these spots and removes some of the associated `hir::map` functions.
Rollup merge of #61702 - RalfJung:const-enum-cast, r=oli-obk
test more variants of enum-int-casting
As I learned in https://github.com/rust-lang/rust/pull/61673#issuecomment-500213506, there is a code path we are not testing yet. Looks like enum-int-casting with and without an intermediate let-binding is totally different.
EDIT: The reason for this is to get rid of the cycle in definitions such as:
```rust
enum Foo {
A = 0,
B = Foo::A as isize + 2,
}
```
This has historically been supported, so a hack adding special treatment to `Enum::Variant as _` was added to keep supporting it.
Aleksey Kladov [Mon, 17 Jun 2019 08:35:26 +0000 (11:35 +0300)]
don't ICE on large files
This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.
For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.
Changes:
````
Fix wrong lifetime of TyCtxt
Use replace_region_in_file for creating the lint list
Restructure rename tests
Register rename to the LintStore.
Rename REDUNDANT_STATIC_LIFETIME to REDUNDANT_STATIC_LIFETIMES.
Remove pub from RedundantStaticLifetime.visit_type function.
Rename const_static_lifetime to redundant_static_lifetime.
Merge StaticConst and StaticStatic lints into StaticConst.
Use RedundantStaticLifetime in StaticStatic.
Move type-checking logic in StaticConst to RedundantStaticLifetime.
Add lint for statics with explicit static lifetime.
minor fix
make it pass dogfood
run rustfmt
fix padding and put clippy someplaces
show default lint levels
group printing
prelim arg parse
move Lint static def into its own module
switch to sorted usable lints
Update clippy_dev/src/main.rs
initial commit for help improvements on clippy-driver
````
bors [Sun, 16 Jun 2019 23:25:12 +0000 (23:25 +0000)]
Auto merge of #61892 - rijenkii:master, r=Centril
weird-exprs: if if if if
The `if` keyword can be chained as long as there are enough `{...} else {...}` following, and they all return a `bool` (not required for the last one).
`if` expression can be also put inside a `match` arm guard, thus making the whole thing a little bit more confusing.
Discovered this clusterfunk while reading the reference because I have nothing better to do.
bors [Sun, 16 Jun 2019 17:48:24 +0000 (17:48 +0000)]
Auto merge of #61881 - glaubitz:sparc64-ffi-abi, r=petrochenkov
librustc_codegen_llvm: Use repr(transparent) for bitflags over repr(C…
…) (#61306)
In order to make sure that Rust's bitflags types are passed the same way in the Rust ABI as they are in the C ABI, we need to use the attribute repr(transparent) over the repr(C) attribute for the single-field bitflags structs in in order to prevent ABI mismatches. Thanks to Michael Karcher for finding this bug.
bors [Sun, 16 Jun 2019 14:58:05 +0000 (14:58 +0000)]
Auto merge of #61754 - nikomatsakis:trait-caching-perf-3, r=pnkfelix
create a "provisional cache" to restore performance in the case of cycles
Introduce a "provisional cache" that caches the results of auto trait resolutions but keeps them from entering the *main* cache until everything is ready. This turned out a bit more complex than I hoped, but I don't see another short term fix -- happy to take suggestions! In the meantime, it's very clear we need to rework the trait solver. This resolves the extreme performance slowdown experienced in #60846 -- I plan to add a perf.rust-lang.org regression test to track this.
Changes:
````
Fix wrong lifetime of TyCtxt
Use replace_region_in_file for creating the lint list
Restructure rename tests
Register rename to the LintStore.
Rename REDUNDANT_STATIC_LIFETIME to REDUNDANT_STATIC_LIFETIMES.
Remove pub from RedundantStaticLifetime.visit_type function.
Rename const_static_lifetime to redundant_static_lifetime.
Merge StaticConst and StaticStatic lints into StaticConst.
Use RedundantStaticLifetime in StaticStatic.
Move type-checking logic in StaticConst to RedundantStaticLifetime.
Add lint for statics with explicit static lifetime.
minor fix
make it pass dogfood
run rustfmt
fix padding and put clippy someplaces
show default lint levels
group printing
prelim arg parse
move Lint static def into its own module
switch to sorted usable lints
Update clippy_dev/src/main.rs
initial commit for help improvements on clippy-driver
````
Rollup merge of #61704 - petrhosek:llvm-linker-flags, r=alexcrichton
Pass LLVM linker flags to librustc_llvm build
Some -L and -l flags may be needed even when building librustc_llvm,
for example when using static libc++ on Linux we may need to manually
specify the library search path and -ldl -lpthread as additional link
dependencies. We pass LLVM linker flags from config to librustc_llvm
build to make sure these cases are handled.
Rollup merge of #61447 - scottmcm:vec-vecdeque, r=sfackler
Add some Vec <-> VecDeque documentation
These are more than just `.into_iter().collect()`, so talk about some of their nuances.
For VecDeque -> Vec I'm trying to intentionally not write a guarantee for people making their own `Vec`s, since the rules are more complicated than I think we want to commit to forever.
The "Vec -> VecDeque doesn't reallocate" guarantee seems reasonable, though. (And I'm intentionally ambiguous about when it's O(1) instead of O(n).)
librustc_codegen_llvm: Use repr(transparent) for bitflags over repr(C) (#61306)
In order to make sure that Rust's bitflags types are passed the same
way in the Rust ABI as they are in the C ABI, we need to use the attribute
repr(transparent) over the repr(C) attribute for the single-field bitflags
structs in in order to prevent ABI mismatches. Thanks to Michael Karcher
for finding this bug.
bors [Sat, 15 Jun 2019 21:15:28 +0000 (21:15 +0000)]
Auto merge of #61828 - RalfJung:cfg-if, r=alexcrichton
make sure we use cfg-if as a std dependency
xargo currently fails to build libstd because this feature is missing. My guess is that it works in rustc because the feature is enabled elsewhere, but that does not help for a libstd-only build.
Miri is currently in a state where it is shipped but broken, which makes CI fail for projects that are tested in Miri. So this is kind of urgent.
Cc @alexcrichton https://github.com/rust-lang/rust/pull/61720
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
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`!
projects / rust.git / log