Force appropriate extension when converting from int to ptr #43291Fixes#43291.
Looking for feedback if I've missed something and/or need to add more tests.
@eddyb @retep998 @nagisa @oli-obk
Reword reason for move note
On move errors, when encountering an enum variant, be more ambiguous and do not refer to the type on the cause note, to avoid referring to `(maybe as std::prelude::v1::Some).0`, and instead refer to `the value`.
Sidesteps part of the problem with #41962:
```
error[E0382]: use of partially moved value: `maybe`
--> file.rs:5:30
|
5 | if let Some(thing) = maybe {
| ----- ^^^^^ value used here after move
| |
| value moved here
= note: move occurs because the value has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
error[E0382]: use of moved value: `(maybe as std::prelude::v1::Some).0`
--> file.rs:5:21
|
5 | if let Some(thing) = maybe {
| ^^^^^ value moved here in previous iteration of loop
= note: move occurs because the value has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
error: aborting due to 2 previous errors
```
Previous discussion: #44360
r? @arielb1
NLL fixes
First, introduce pre-statement effects to dataflow to fix#46875. Edge dataflow effects might make that redundant, but I'm not sure of the best way to integrate them with liveness etc., and if this is a hack, this is one of the cleanest hacks I've seen.
And I want a small fix to avoid the torrent of bug reports.
Second, fix linking of projections to fix#46974
r? @pnkfelix
First cut at getting some part of the test suite working for CloudABI
I am currently working on creating a Docker container for automated CI for CloudABI. Here are some of the trivial changes that need to land to make tests pass.
Mention SliceConcatExt's stability in its docs
Just saw someone in IRC mention there being no stable way to join string slices! It isn't entirely clear from the rust documentation that `SliceConcatExt` is usable. While this is mentioned in https://doc.rust-lang.org/std/prelude/, the trait has nothing to indicate that it's currently usable if found via a documentation search.
The wording on this could probably be improved, but I'm hoping its better than nothing.
Minor cleanup for slice::Chunks and ChunksMut
This only renames the `size` field to `chunk_size` in one of them for consistency, and changes an assertion to check for != 0 instead of > 0.
Proc macro spans serve two mostly unrelated purposes: controlling name
resolution and controlling error messages. It can be useful to mix the
name resolution behavior of one span with the line/column error message
locations of a different span.
In particular, consider the case of a trait brought into scope within
the def_site of a custom derive. I want to invoke trait methods on the
fields of the user's struct. If the field type does not implement the
right trait, I want the error message to underline the corresponding
struct field.
Generating the method call with the def_site span is not ideal -- it
compiles and runs but error messages sadly always point to the derive
attribute like we saw with Macros 1.1.
```
|
4 | #[derive(HeapSize)]
| ^^^^^^^^
```
Generating the method call with the same span as the struct field's
ident or type is not correct -- it shows the right underlines but fails
to resolve to the trait in scope at the def_site.
```
|
7 | bad: std:🧵:Thread,
| ^^^^^^^^^^^^^^^^^^^^^^^^
```
The correct span for the method call is one that combines the def_site's
name resolution with the struct field's line/column.
```
field.span.resolved_at(Span::def_site())
// equivalently
Span::def_site().located_at(field.span)
```
Adding both because which one is more natural will depend on context.
Move static code outside of unciode.py.
This script in libstd_unicode is a mess and also contains code that shouldn't be output by a script, and instead just put in modules. So, this change does that.
