Mark Simulacrum [Sun, 11 Feb 2018 23:27:33 +0000 (16:27 -0700)]
Delete executables if the test ran successfully.
This isn't a perfect heuristic, but since the amount of run-fail tests
is far lower than run-pass tests for now, it should be sufficient to
ensure that we don't run into CI limits. This makes it possible to run
the test binary manually (e.g., under gdb/lldb) if it failed to attempt
to find out why.
bors [Sun, 11 Feb 2018 15:10:46 +0000 (15:10 +0000)]
Auto merge of #47614 - dotdash:x86_64_sysv_ffi, r=eddyb
Fix oversized loads on x86_64 SysV FFI calls
The x86_64 SysV ABI should use exact sizes for small structs passed in
registers, i.e. a struct that occupies 3 bytes should use an i24,
instead of the i32 it currently uses.
bors [Sun, 11 Feb 2018 05:29:20 +0000 (05:29 +0000)]
Auto merge of #47657 - algesten:save-analysis-impls, r=nrc
Emit data::Impl in save-analysis
As discussed on [internals.rust-lang](https://internals.rust-lang.org/t/rustdoc2-rls-analysis-and-the-compiler-help-wanted/6592/5), this PR emits `rls-data::Impl` in the save-analysis.
A number of questions are outstanding:
- [x] A few `???` around row 356. We need to discuss what goes here, if anything.
- [ ] ~~Deriving `id` for impl using hashing. Is this going to clash with rustc defids?~~
- [ ] ~~Deriving `id` for impl using hashing. Is the conversion from 64 bit -> 32 bit problematic?~~
- [x] Need a new rls-data with an `id` field in `Impl` struct.
- [ ] ~~Need a new rls-data which `derive` `Hash` for `ImplKind` enum.~~
kennytm [Sat, 10 Feb 2018 19:39:53 +0000 (03:39 +0800)]
Rollup merge of #47547 - varkor:infinite-iterators-warning-doc, r=frewsxcv
Document the behaviour of infinite iterators on potentially-computable methods
It’s not entirely clear from the current documentation what behaviour
calling a method such as `min` on an infinite iterator like `RangeFrom`
is. One might expect this to terminate, but in fact, for infinite
iterators, `min` is always nonterminating (at least in the standard
library). This adds a quick note about this behaviour for clarification.
kennytm [Sat, 10 Feb 2018 16:51:56 +0000 (00:51 +0800)]
Rollup merge of #48085 - alexcrichton:update-dlmalloc, r=Mark-Simulacrum
Update the dlmalloc submodule
A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
Alex Crichton [Fri, 9 Feb 2018 04:45:45 +0000 (20:45 -0800)]
Update the dlmalloc submodule
A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
kennytm [Sat, 10 Feb 2018 06:26:57 +0000 (14:26 +0800)]
Rollup merge of #48100 - Mark-Simulacrum:fetch-nand, r=alexcrichton
Add fetch_nand to atomics
I think this is all fine but I have little familiarity with the atomic code (or libcore in general) so I may have accidentally done something wrong here...
kennytm [Sat, 10 Feb 2018 06:24:07 +0000 (14:24 +0800)]
Rollup merge of #48098 - alexcrichton:fix-i686-dist-bootstrap, r=Mark-Simulacrum
ci: Actually bootstrap on i686 dist
Right now the `--build` option was accidentally omitted, so we're bootstraping
from `x86_64` to `i686`. In addition to being slower (more compiles) that's not
actually bootstrapping!
kennytm [Sat, 10 Feb 2018 06:24:04 +0000 (14:24 +0800)]
Rollup merge of #48078 - alexcrichton:fix-required-const-and-proc-macro, r=eddyb
Disallow function pointers to #[rustc_args_required_const]
This commit disallows acquiring a function pointer to functions tagged as
`#[rustc_args_required_const]`. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.
Note that the first commit here isn't related specifically to this feature, but was necessary to get this working in stdsimd!
kennytm [Sat, 10 Feb 2018 06:24:02 +0000 (14:24 +0800)]
Rollup merge of #48059 - alexcrichton:sccachebs, r=Mark-Simulacrum
rustbuild: Pass `ccache` to build scripts
Right now the ccache setting is only used for LLVM, but this tweaks it to also
be used for build scripts so C++ builds like `librustc_llvm` can be a bit
speedier.
kennytm [Sat, 10 Feb 2018 06:23:58 +0000 (14:23 +0800)]
Rollup merge of #48047 - etaoins:fix-ice-for-mismatched-args-on-target-without-span, r=estebank
Fix ICE for mismatched args on target without span
Commit 7ed00caacc improved our error reporting by including the target function in our error messages when there is an argument count mismatch. A simple example from the UI tests is:
```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
--> $DIR/closure-arg-count.rs:32:53
|
32 | let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
| ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
| -------- takes 0 arguments
```
However, this assumed the target span was always available. This does not hold true if the target function is in `std` or another crate. A simple example from #48046 is assigning `str::split` to a function type with a different number of arguments.
Fix by omitting all of the labels and suggestions related to the target span when it's not found.
kennytm [Sat, 10 Feb 2018 06:23:56 +0000 (14:23 +0800)]
Rollup merge of #47854 - varkor:create-out-dir, r=pnkfelix
Create a directory for --out-dir if it does not already exist
Currently if `--out-dir` is set to a non-existent directory, the compiler will throw unfriendly messages like `error: could not write output to subdir/example.crate.allocator.rcgu.o: No such file or
directory`, which, while not completely unreadable, isn’t very user-friendly either. This change creates the directory automatically if it does not yet exist.
This also updates the docker container for dist-i686-freebsd as the old 16.04
container is no longer capable of building LLVM. The
compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without
much interesting happening, but the LLVM update here is of particular note.
Unlike previous updates I haven't cherry-picked all existing patches we had on
top of our LLVM branch as we have a [huge amount][patches4] and have at this
point forgotten what most of them are for. Instead I started from the current
`release_60` branch in LLVM and only applied patches that were necessary to get
our tests working and building.
The [current set of custom rustc-specific patches](https://github.com/rust-lang/llvm/compare/f1286127b73c0d81ced8595af62e78ed703ced8b...rust-llvm-release-6-0-0) included in this LLVM update are:
* rust-lang/llvm@1187443 - this is how we actually implement
`cfg(target_feature)` for now and continues to not be upstreamed. While a
hazard for SIMD stabilization this commit is otherwise keeping the status
quo of a small rustc-specific feature.
* rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't
upstreamed, notably teaching LLVM about our allocation-related routines (which
aren't malloc/free). Once we stabilize the global allocator routines we will
likely want to upstream this patch, but for now it seems reasonable to keep it
on our fork.
* rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in
our 32-bit linux container. I'm not really sure why it's necessary but my
guess is that it's because of the absolutely ancient glibc that we're using.
In any case it's only updating pieces we're not actually using in LLVM so I'm
hoping it'll turn out alright. This doesn't seem like something we'll want to
upstream.c
* rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our
i686-freebsd container, I'm not really sure what's going on but we for sure
probably don't want to upstream this and otherwise it seems not too bad for
now at least.
* rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug]
which although diagnosed to a particular revision isn't currently fixed
upstream (and the bug itself doesn't seem too active). This commit is a
partial revert of the suspected cause of this regression (found via a
bisection). I'm sort of hoping that this eventually gets fixed upstream with a
similar fix (which we can replace in our branch), but for now I'm also hoping
it's a relatively harmless change to have.
After applying these patches (plus one [backport] which should be [backported
upstream][llvm-back]) I believe we should have all tests working on all
platforms in our current test suite. I'm like 99% sure that we'll need some more
backports as issues are reported for LLVM 6 when this propagates through
nightlies, but that's sort of just par for the course nowadays!
In any case though some extra scrutiny of the patches here would definitely be
welcome, along with scrutiny of the "missing patches" like a [change to pass
manager order](rust-lang/llvm@2717444), [another change to pass manager
order](rust-lang/llvm@c782feb), some [compile fixes for
sparc](rust-lang/llvm@1a83de6), and some [fixes for
solaris](rust-lang/llvm@c2bfe0a).
The update to LLVM 6 is desirable for a number of reasons, notably:
* This'll allow us to keep up with the upstream wasm backend, picking up new
features as they start landing.
* Upstream LLVM has fixed a number of SIMD-related compilation errors,
especially around AVX-512 and such.
* There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed
in the LLVM 4 branch we're using.
* Overall it's not a great idea to stagnate with our codegen backend!
This update is mostly powered by #47730 which is allowing us to update LLVM
*independent* of the version of LLVM that Emscripten is locked to. This means
that when compiling code for Emscripten we'll still be using the old LLVM 4
backend, but when compiling code for any other target we'll be using the new
LLVM 6 target. Once Emscripten updates we may no longer need this distinction,
but we're not sure when that will happen!
This also updates the docker container for dist-i686-freebsd as the old 16.04
container is no longer capable of building LLVM. The
compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without
much interesting happening, but the LLVM update here is of particular note.
Unlike previous updates I haven't cherry-picked all existing patches we had on
top of our LLVM branch as we have a [huge amount][patches4] and have at this
point forgotten what most of them are for. Instead I started from the current
`release_60` branch in LLVM and only applied patches that were necessary to get
our tests working and building.
The current set of custom rustc-specific patches included in this LLVM update are:
* rust-lang/llvm@1187443 - this is how we actually implement
`cfg(target_feature)` for now and continues to not be upstreamed. While a
hazard for SIMD stabilization this commit is otherwise keeping the status
quo of a small rustc-specific feature.
* rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't
upstreamed, notably teaching LLVM about our allocation-related routines (which
aren't malloc/free). Once we stabilize the global allocator routines we will
likely want to upstream this patch, but for now it seems reasonable to keep it
on our fork.
* rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in
our 32-bit linux container. I'm not really sure why it's necessary but my
guess is that it's because of the absolutely ancient glibc that we're using.
In any case it's only updating pieces we're not actually using in LLVM so I'm
hoping it'll turn out alright. This doesn't seem like something we'll want to
upstream.c
* rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our
i686-freebsd container, I'm not really sure what's going on but we for sure
probably don't want to upstream this and otherwise it seems not too bad for
now at least.
* rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug]
which although diagnosed to a particular revision isn't currently fixed
upstream (and the bug itself doesn't seem too active). This commit is a
partial revert of the suspected cause of this regression (found via a
bisection). I'm sort of hoping that this eventually gets fixed upstream with a
similar fix (which we can replace in our branch), but for now I'm also hoping
it's a relatively harmless change to have.
After applying these patches (plus one [backport] which should be [backported
upstream][llvm-back]) I believe we should have all tests working on all
platforms in our current test suite. I'm like 99% sure that we'll need some more
backports as issues are reported for LLVM 6 when this propagates through
nightlies, but that's sort of just par for the course nowadays!
In any case though some extra scrutiny of the patches here would definitely be
welcome, along with scrutiny of the "missing patches" like a [change to pass
manager order](rust-lang/llvm@27174447533), [another change to pass manager
order](rust-lang/llvm@c782febb7b9), some [compile fixes for
sparc](rust-lang/llvm@1a83de63c42), and some [fixes for
solaris](rust-lang/llvm@c2bfe0abb).
The update to LLVM 6 is desirable for a number of reasons, notably:
* This'll allow us to keep up with the upstream wasm backend, picking up new
features as they start landing.
* Upstream LLVM has fixed a number of SIMD-related compilation errors,
especially around AVX-512 and such.
* There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed
in the LLVM 4 branch we're using.
* Overall it's not a great idea to stagnate with our codegen backend!
This update is mostly powered by #47730 which is allowing us to update LLVM
*independent* of the version of LLVM that Emscripten is locked to. This means
that when compiling code for Emscripten we'll still be using the old LLVM 4
backend, but when compiling code for any other target we'll be using the new
LLVM 6 target. Once Emscripten updates we may no longer need this distinction,
but we're not sure when that will happen!
Alex Crichton [Fri, 9 Feb 2018 18:12:32 +0000 (10:12 -0800)]
ci: Actually bootstrap on i686 dist
Right now the `--build` option was accidentally omitted, so we're bootstraping
from `x86_64` to `i686`. In addition to being slower (more compiles) that's not
actually bootstrapping!
bors [Fri, 9 Feb 2018 13:04:17 +0000 (13:04 +0000)]
Auto merge of #47802 - bobtwinkles:loop_false_edge, r=nikomatsakis
[NLL] Add false edges out of infinite loops
Resolves #46036 by adding a `cleanup` member to the `FalseEdges` terminator kind. There's also a small doc fix to one of the other comments in `into.rs` which I can pull out in to another PR if desired =)
This PR should pass CI but the test suite has been relatively unstable on my system so I'm not 100% sure.
bors [Fri, 9 Feb 2018 02:26:43 +0000 (02:26 +0000)]
Auto merge of #47489 - pnkfelix:limit-2pb-issue-46747, r=nikomatsakis
NLL: Limit two-phase borrows to autoref-introduced borrows
This imposes a restriction on two-phase borrows so that it only applies to autoref-introduced borrows.
The goal is to ensure that our initial deployment of two-phase borrows is very conservative. We want it to still cover the `v.push(v.len());` example, but we do not want it to cover cases like `let imm = &v; let mu = &mut v; mu.push(imm.len());`
(Why do we want it to be conservative? Because when you are not conservative, then the results you get, at least with the current analysis, are tightly coupled to details of the MIR construction that we would rather remain invisible to the end user.)
Fix #46747
I decided, for this PR, to add a debug-flag `-Z two-phase-beyond-autoref`, to re-enable the more general approach. But my intention here is *not* that we would eventually turn on that debugflag by default; the main reason I added it was that I thought it was useful for writing tests to be able to write source that looks like desugared MIR.
Alex Crichton [Wed, 7 Feb 2018 20:56:04 +0000 (12:56 -0800)]
rustbuild: Pass `ccache` to build scripts
Right now the ccache setting is only used for LLVM, but this tweaks it to also
be used for build scripts so C++ builds like `librustc_llvm` can be a bit
speedier.
Alex Crichton [Thu, 8 Feb 2018 21:11:13 +0000 (13:11 -0800)]
Disallow function pointers to #[rustc_args_required_const]
This commit disallows acquiring a function pointer to functions tagged as
`#[rustc_args_required_const]`. This is intended to be used as future-proofing
for the stdsimd crate to avoid taking a function pointer to any intrinsic which
has a hard requirement that one of the arguments is a constant value.
Alex Crichton [Thu, 8 Feb 2018 20:48:25 +0000 (12:48 -0800)]
Add `rustc_args_required_const` to the feature whitelist
Unfortunately left out it means that when the `#![feature(proc_macro)]` flag is
in effect it fails to find `rustc_args_required_const` for expansion. This
version, however, is verified to work with stdsimd's requirements!
Björn Steinbrink [Sat, 20 Jan 2018 16:09:55 +0000 (17:09 +0100)]
Fix oversized loads on x86_64 SysV FFI calls
The x86_64 SysV ABI should use exact sizes for small structs passed in
registers, i.e. a struct that occupies 3 bytes should use an i24,
instead of the i32 it currently uses.
Add `AutoBorrowMutability`; its like `hir::Mutability` but w/ two-phase borrow info too.
Namely, the mutable borrows also carries a flag indicating whether
they should support two-phase borrows.
This allows us to thread down, from the point of the borrow's
introduction, whether the particular adjustment that created it is one
that yields two-phase mutable borrows.
Restrict two-phase borrows to solely borrows introduced via autoref.
Added `-Z two-phase-beyond-autoref` to bring back old behavior (mainly
to allow demonstration of desugared examples).
Updated tests to use aforementioned flag when necessary. (But in each
case where I added the flag, I made sure to also include a revision
without the flag so that one can readily see what the actual behavior
we expect is for the initial deployment of NLL.)
bors [Thu, 8 Feb 2018 06:38:30 +0000 (06:38 +0000)]
Auto merge of #48057 - scottmcm:less-match-more-compare, r=dtolnay
Simplify RangeInclusive::next[_back]
`match`ing on an `Option<Ordering>` seems cause some confusion for LLVM; switching to just using comparison operators removes a few jumps from the simple `for` loops I was trying.
cc https://github.com/rust-lang/rust/issues/45222 https://github.com/rust-lang/rust/issues/28237#issuecomment-363706510
Example:
```rust
#[no_mangle]
pub fn coresum(x: std::ops::RangeInclusive<u64>) -> u64 {
let mut sum = 0;
for i in x {
sum += i ^ (i-1);
}
sum
}
```
Today:
```asm
coresum:
xor r8d, r8d
mov r9, -1
xor eax, eax
jmp .LBB0_1
.LBB0_4:
lea rcx, [rdi - 1]
xor rcx, rdi
add rax, rcx
mov rsi, rdx
mov rdi, r10
.LBB0_1:
cmp rdi, rsi
mov ecx, 1
cmovb rcx, r9
cmove rcx, r8
test rcx, rcx
mov edx, 0
mov r10d, 1
je .LBB0_4 // 1
cmp rcx, -1
jne .LBB0_5 // 2
lea r10, [rdi + 1]
mov rdx, rsi
jmp .LBB0_4 // 3
.LBB0_5:
ret
```
With this PR:
```asm
coresum:
cmp rcx, rdx
jbe .LBB0_2
xor eax, eax
ret
.LBB0_2:
xor r8d, r8d
mov r9d, 1
xor eax, eax
.p2align 4, 0x90
.LBB0_3:
lea r10, [rcx + 1]
cmp rcx, rdx
cmovae rdx, r8
cmovae r10, r9
lea r11, [rcx - 1]
xor r11, rcx
add rax, r11
mov rcx, r10
cmp r10, rdx
jbe .LBB0_3 // Just this
ret
```
<details><summary>Though using internal iteration (`.map(|i| i ^ (i-1)).sum()`) is still shorter to type, and lets the compiler unroll it</summary>
bobtwinkles [Thu, 8 Feb 2018 01:00:54 +0000 (20:00 -0500)]
Fix tests for MIR loop lowering
Fixes the hash test to recognize that MirValidated can change when changing
around labels, and add a new test that makes sure we're lowering loop statements
correctly.
Scott McMurray [Wed, 7 Feb 2018 19:11:54 +0000 (11:11 -0800)]
Simplify RangeInclusive::next[_back]
`match`ing on an `Option<Ordering>` seems cause some confusion for LLVM; switching to just using comparison operators removes a few jumps from the simple `for` loops I was trying.
Rollup merge of #48028 - zackmdavis:and_the_span_of_the_unknown_type, r=estebank
correct E0619 span re method call receivers whose type must be known
Previously, when the type of a method receiver could not be determined,
the error message would, potentially confusingly, highlight the span of
the entire method call.
Rollup merge of #48020 - RalfJung:type-alias-bounds, r=petrochenkov
Warn about more ignored bounds in type aliases
It seems that all bounds in type aliases are entirely ignored, not just type bounds. This extends the warning appropriately.
I assume this should be made a hard error with the next epoch? I can't see any reason to accept these programs. (And suddenly enforcing these type bounds would be a breaking change.)
Rollup merge of #48018 - alexcrichton:require-const-arg, r=eddyb
rustc: Add `#[rustc_args_required_const]`
This commit adds a new unstable attribute to the compiler which requires that
arguments to a function are always provided as constants. The primary use case
for this is SIMD intrinsics where arguments are defined by vendors to be
constant and in LLVM they indeed must be constant as well.
For now this is mostly just a semantic guarantee in rustc that an argument is a
constant when invoked, phases like trans don't actually take advantage of it
yet. This means that we'll be able to use this in stdsimd but we won't be able
to remove the `constify_*` macros just yet. Hopefully soon though!
Rollup merge of #48014 - Manishearth:stealing-chickens-on-the-internet, r=nikomatsakis
Implement RFC 2052 (Epochs)
This adds -Zepochs and uses it for tyvar_behind_raw_pointer (#46906)
When we move this to --epoch=XXX, we'll need to gate the 2018 epoch on nightly, but not the 2015 one. I can make these changes here itself though it's kinda pointless given that the entire flag is nightly-only.
r? @nikomatsakis @aturon
cc #44581 (epoch tracking)
cc #46906 (tyvar_behind_raw_pointer)
Rollup merge of #47944 - oberien:unboundediterator-trustedlen, r=bluss
Implement TrustedLen for Take<Repeat> and Take<RangeFrom>
This will allow optimization of simple `repeat(x).take(n).collect()` iterators, which are currently not vectorized and have capacity checks.
This will only support a few aggregates on `Repeat` and `RangeFrom`, which might be enough for simple cases, but doesn't optimize more complex ones. Namely, Cycle, StepBy, Filter, FilterMap, Peekable, SkipWhile, Skip, FlatMap, Fuse and Inspect are not marked `TrustedLen` when the inner iterator is infinite.
Rollup merge of #47883 - yurydelendik:wasm-map, r=alexcrichton
Export wasm source map when debug information is enabled
We use binaryen's linker to produce a wasm file (via s2wasm). The wasm writer has capabilities to export source maps. The pilot support for source maps is added to Firefox.
The produced source map contains references to the original file, that might require additional source map file processing to include / package original files with it.
Rollup merge of #47631 - SimonSapin:nonnull, r=alexcrichton
Add some APIs to ptr::NonNull and fix `since` attributes
This is a follow-up to its stabilization in https://github.com/rust-lang/rust/pull/46952. Tracking issue: https://github.com/rust-lang/rust/issues/27730.
* These trait impls are insta-stable: `Hash`, `PartialEq`, `Eq`, `PartialOrd` and `Ord`.
* The new `cast<U>() -> NonNull<U>` method is `#[unstable]`. It was proposed in https://github.com/rust-lang/rust/pull/46952#issuecomment-359220010.
Rollup merge of #47613 - estebank:rustc_on_unimplemented, r=nikomatsakis
Add filtering options to `rustc_on_unimplemented`
- Add filtering options to `rustc_on_unimplemented` for local traits, filtering on `Self` and type arguments.
- Add a way to provide custom notes.
- Tweak binops text.
- Add filter to detect wether `Self` is local or belongs to another crate.
- Add filter to `Iterator` diagnostic for `&str`.
Partly addresses #44755 with a different syntax, as a first approach. Fixes #46216, fixes #37522, CC #34297, #46806.
bors [Wed, 7 Feb 2018 14:54:15 +0000 (14:54 +0000)]
Auto merge of #47957 - bobtwinkles:fix_mir_consts, r=nikomatsakis
[NLL] Improve DefiningTy::Const
Fixes #47590 by fixing the way DefiningTy represents constants. Previously, constants were represented using just the type of the variable. However, this will fail to capture early-bound regions as NLL inference vars, resulting in an ICE when we try to compute region VIDs a little bit later in the universal
region resolution process. (ref #47590)
Ryan Cumming [Wed, 7 Feb 2018 07:34:45 +0000 (18:34 +1100)]
Fix ICE for mismatched args on target without span
Commit 7ed00caacc improved our error reporting by including the target
function in our error messages when there is an argument count mismatch.
A simple example from the UI tests is:
```
error[E0593]: function is expected to take a single 2-tuple as argument, but it takes 0 arguments
--> $DIR/closure-arg-count.rs:32:53
|
32 | let _it = vec![1, 2, 3].into_iter().enumerate().map(foo);
| ^^^ expected function that takes a single 2-tuple as argument
...
44 | fn foo() {}
| -------- takes 0 arguments
```
However, this assumed the target span was always available. This does
not hold true if the target function is in `std` or another crate. A
simple example from #48046 is assigning `str::split` to a function type
with a different number of arguments.
Fix by removing all of the labels and suggestions related to the target
span when it's not found.
bobtwinkles [Fri, 2 Feb 2018 03:26:48 +0000 (22:26 -0500)]
mir: Fix DefiningTy::Const
Fixes #47590 by fixing the way DefiningTy represents constants. Previously,
constants were represented using just the type of the variable. However, this
will fail to capture early-bound regions as NLL inference vars, resulting in an
ICE when we try to compute region VIDs a little bit later in the universal
region resolution process.
Fixes #45697. This PR resolves the error duplication. I attempted to replace the existing sets since there were quite a few but only managed to replace two of them.
projects / rust.git / log