In order to output a path that could actually be imported (valid and
visible), we need to handle re-exports correctly.
For example, take `std::os::unix::process::CommandExt`, this trait is
actually defined at `std::sys::unix::ext::process::CommandExt` (at time
of writing).
`std::os::unix` rexports the contents of `std::sys::unix::ext`.
`std::sys` is private so the "true" path to `CommandExt` isn't accessible.
In this case, the visible parent map will look something like this:
(child) -> (parent)
`std::sys::unix::ext::process::CommandExt` -> `std::sys::unix::ext::process`
`std::sys::unix::ext::process` -> `std::sys::unix::ext`
`std::sys::unix::ext` -> `std::os`
This is correct, as the visible parent of `std::sys::unix::ext` is in fact
`std::os`.
When printing the path to `CommandExt` and looking at the current
segment that corresponds to `std::sys::unix::ext`, we would normally
print `ext` and then go to the parent - resulting in a mangled path like
`std::os::ext::process::CommandExt`.
Instead, we must detect that there was a re-export and instead print `unix`
(which is the name `std::sys::unix::ext` was re-exported as in `std::os`).
Also, avoid shadowing of the `ty` variable by giving the `cast_ty` and
`var_ty` variables different names. We want to get the user-provided
type from `cast_ty.hir_id`.
Here we have fixed the case where we were throwing two diagnostic
messages `E0026` and `E0027` for same case like this
Example
error[E0026]: variant `A::A` does not have a field named `fob`
--> src/test/ui/issue-52717.rs:20:12
|
20 | A::A { fob } => { println!("{}", fob); }
| ^^^ variant `A::A` does not have this field
error[E0027]: pattern does not mention field `foo`
--> src/test/ui/issue-52717.rs:20:5
|
20 | A::A { fob } => { println!("{}", fob); }
| ^^^^^^^^^^^^ missing field `foo`
error: aborting due to 2 previous errors
Here above we can see that both `E0026` and `E0027` are depicting
same thing.
So, to fix this issue, we are simply checking element of
`inexistent_fields` is there any value lies in
`unmentioned_fields` using Levenshtein algorithm, if does
then for that case we are simply deleting element from
`unmentioned_fields`. More or less now instead of showing
separate message in `E0027` we are giving extra hint on `E0026`
Address: #52717
The issue of passing around SIMD types as values between functions has
seen [quite a lot] of [discussion], and although we thought [we fixed
it][quite a lot] it [wasn't]! This PR is a change to rustc to, again,
try to fix this issue.
The fundamental problem here remains the same, if a SIMD vector argument
is passed by-value in LLVM's function type, then if the caller and
callee disagree on target features a miscompile happens. We solve this
by never passing SIMD vectors by-value, but LLVM will still thwart us
with its argument promotion pass to promote by-ref SIMD arguments to
by-val SIMD arguments.
This commit is an attempt to thwart LLVM thwarting us. We, just before
codegen, will take yet another look at the LLVM module and demote any
by-value SIMD arguments we see. This is a very manual attempt by us to
ensure the codegen for a module keeps working, and it unfortunately is
likely producing suboptimal code, even in release mode. The saving grace
for this, in theory, is that if SIMD types are passed by-value across
a boundary in release mode it's pretty unlikely to be performance
sensitive (as it's already doing a load/store, and otherwise
perf-sensitive bits should be inlined).
The implementation here is basically a big wad of C++. It was largely
copied from LLVM's own argument promotion pass, only doing the reverse.
In local testing this...
Closes#50154Closes#52636Closes#54583Closes#55059
[quite a lot]: https://github.com/rust-lang/rust/pull/47743
[discussion]: https://github.com/rust-lang/rust/issues/44367
[wasn't]: https://github.com/rust-lang/rust/issues/50154
Add a `copysign` function to f32 and f64
This patch adds a `copysign` function to the float primitive types. It is an exceptionally useful function for writing efficient numeric code, as it often avoids branches, is auto-vectorizable, and there are efficient intrinsics for most platforms.
I think this might work as-is, as the relevant `copysign` intrinsic is already used internally for the implementation of `signum`. It's possible that an implementation might be needed in japaric/libm for portability across all platforms, in which case I'll do that also.
Part of the work towards #55107
Custom E0277 diagnostic for `Path`
r? @nikomatsakis we have a way to target `Path` exclusively, we need to identify the correct text to show to consider #23286 fixed.
NLL lacks various special case handling of closures
Part of #52663.
Firstly, this PR extends existing handling of closures to also support generators.
Second, this PR adds the note found in the AST when a closure is invoked twice and captures a variable by-value:
```text
note: closure cannot be invoked more than once because it moves the variable `dict` out of its environment
--> $DIR/issue-42065.rs:16:29
|
LL | for (key, value) in dict {
| ^^^^
```
r? @nikomatsakis
cc @pnkfelix
