rustdoc: Collect traits in scope for lang items
Inherent impls on primitive types are not included in the list of all inherent impls in the crate (`inherent_impls_in_crate_untracked`), they are taken from the list of lang items instead, but such impls can also be inlined by rustdoc, e.g. if something derefs to a primitive type.
r? `@camelid`
Fixes https://github.com/rust-lang/rust/issues/93698
Fix documentation for is_X_feature_detected!
These are now properly documented for all architectures and the
stability attributes in the docs are now correctly displayed.
This addresses this comment by `@ehuss:` https://github.com/rust-lang/rust/pull/90271#issuecomment-1038400916
cc `@adamgemmell`
Clippy: Don't lint `needless_borrow` in method receiver positions
r? `@Manishearth`
cc `@camsteffen` `@Jarcho`
cc rust-lang/rust-clippy#8441
Let's get this fix in before the beta branching tomorrow.
Fix ICE when using Box<T, A> with pointer sized A
Fixes#78459
Note that using `Box<T, A>` with a more than pointer sized `A` or using a pointer sized `A` with a Box of a DST will produce a different ICE (#92054) which is not fixed by this PR.
Add a `try_collect()` helper method to `Iterator`
Implement `Iterator::try_collect()` as a helper around `Iterator::collect()` as discussed [here](https://internals.rust-lang.org/t/idea-fallible-iterator-mapping-with-try-map/15715/5?u=a.lafrance).
First time contributor so definitely open to any feedback about my implementation! Specifically wondering if I should open a tracking issue for the unstable feature I introduced.
As the main participant in the internals discussion: r? `@scottmcm`
Add MAIN_SEPARATOR_STR
Currently, if someone needs access to the path separator as a str, they need to go through this mess:
```rust
unsafe {
std::str::from_utf8_unchecked(slice::from_ref(&(MAIN_SEPARATOR as u8)))
}
```
This PR just re-exports an existing path separator str API.
Improve comments about type folding/visiting.
I have found this code confusing for years. I've always roughly
understood it, but never exactly. I just made my fourth(?) attempt and
finally cracked it.
This commit improves the comments. In particular, it explicitly
describes how you can't do a custom fold/visit of any type; there are
actually a handful of "types of interest" (e.g. `Ty`, `Predicate`,
`Region`, `Const`) that can be custom folded/visted, and all other types
just get a generic traversal. I think this was the part that eluded me
on all my prior attempts at understanding.
The commit also updates comments to account for some newer changes such
as the fallible/infallible folding distinction, does some minor
reorderings, and moves one `impl` to a better place.
r? `@BoxyUwU`
Update tracking issue numbers for inline assembly sub-features
The main tracking issue for inline assembly is [closed](https://github.com/rust-lang/rust/issues/72016#issuecomment-1022332954), further tracking of the remaining sub-features has been moved to separate tracking issues.
I have found this code confusing for years. I've always roughly
understood it, but never exactly. I just made my fourth(?) attempt and
finally cracked it.
This commit improves the comments. In particular, it explicitly
describes how you can't do a custom fold/visit of any type; there are
actually a handful of "types of interest" (e.g. `Ty`, `Predicate`,
`Region`, `Const`) that can be custom folded/visted, and all other types
just get a generic traversal. I think this was the part that eluded me
on all my prior attempts at understanding.
The commit also updates comments to account for some newer changes such
as the fallible/infallible folding distinction, does some minor
reorderings, and moves one `impl` to a better place.
Rollup of 8 pull requests
Successful merges:
- #89869 (Add documentation to more `From::from` implementations.)
- #93479 (Use `optflag` for `--report-time`)
- #93693 (Suggest deriving required supertraits)
- #93981 (Fix suggestion to slice if scurtinee is a reference to `Result` or `Option`)
- #93996 (Do not suggest "is a function" for free variables)
- #94030 (Correctly mark the span of captured arguments in `format_args!()`)
- #94031 ([diagnostics] Add mentions to `Copy` types being valid for `union` fields)
- #94064 (Update dist-x86_64-musl to Ubuntu 20.04)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update dist-x86_64-musl to Ubuntu 20.04
This updates the dist-x86_64-musl image to use Ubuntu 20.04. The current Ubuntu 16.04 based image only works due to the Docker cache, it's not possible anymore to run it locally because of the usual certificate expiration issue.
I believe updating the OS here is relatively safe because this targets musl, so there are no concerns about raising the glibc baseline. There is some risk here in that it updates the compiler toolchain used to produce artifacts, though I'm not aware of any specific issues that could cause.
r? ``@Mark-Simulacrum``
[diagnostics] Add mentions to `Copy` types being valid for `union` fields
This came up from some user on Discord which was using a `T : PrimitiveInt` generic type, and they wanted to use in a `union`. Rather than adding a `Copy` bound, they started pondering about the `ManuallyDrop<T>` road, and how to correctly use `unsafe` to perform the drops.
<img width="648" alt="Screen Shot 2022-02-15 at 22 28 34" src="https://user-images.githubusercontent.com/9920355/154152496-8f9be74b-ad59-4724-8f9e-48b446774e06.png">
- [Discord link](https://discord.com/channels/442252698964721669/443150878111694848/943092778534072320)
So, it seemed like the error message for types with potential drop glue on `union` fields could be improved to also mention the `Copy` alternative, since in many cases where `union`s are concerned, people are dealing with PODs / `Copy` types anyways 🙂
___
``@rustbot`` modify labels: +A-diagnostics +D-terse
Correctly mark the span of captured arguments in `format_args!()`
It should not include the braces, or misspelling suggestions will be wrong.
Fixes#94010.
Suggest deriving required supertraits
closes https://github.com/rust-lang/rust/issues/91550
I chose to just hardcode handling for PartialOrd and PartialEq because that should be robust enough and I dont know how to go about doing it generically
r? rust-lang/diagnostics
Use `optflag` for `--report-time`
Essentially, what is described here:
https://github.com/rust-lang/rust/issues/64888#issuecomment-1008047228
There is one difference. The comment proposes to add a
`--report-time-color` option. This change instead uses libtest's
existing `--color` option for that purpose.
Add documentation to more `From::from` implementations.
For users looking at documentation through IDE popups, this gives them relevant information rather than the generic trait documentation wording “Performs the conversion”. For users reading the documentation for a specific type for any reason, this informs them when the conversion may allocate or copy significant memory versus when it is always a move or cheap copy.
Notes on specific cases:
* The new documentation for `From<T> for T` explains that it is not a conversion at all.
* Also documented `impl<T, U> Into<U> for T where U: From<T>`, the other central blanket implementation of conversion.
* The new documentation for construction of maps and sets from arrays of keys mentions the handling of duplicates. Future work could be to do this for *all* code paths that convert an iterable to a map or set.
* I did not add documentation to conversions of a specific error type to a more general error type.
* I did not add documentation to unstable code.
This change was prepared by searching for the text "From<... for" and so may have missed some cases that for whatever reason did not match. I also looked for `Into` impls but did not find any worth documenting by the above criteria.
Destabilize cfg(target_has_atomic_load_store = ...)
This was not intended to be stabilized yet.
This keeps the cfg_target_has_atomic feature gate name since compiler-builtins otherwise depends on it and I'd rather not try to manage a bump across a crates.io published repository given the time-sensitivity here (we need to land this quickly to avoid a beta backport).
Closes https://github.com/rust-lang/rust/issues/32976
r? `@Amanieu`
Maintain broken symlink behaviour for the Windows exe resolver
When the resolver was updated to remove the current directory from the search path (see #87704), care was take to avoid unintentional changes that hadn't been discussed. However, I missed the broken symlink behaviour. This PR fixes that.
**Edit** This turned out to be more important than I first realised. There are some types of application stubs that will redirect to the actual process when run using `CreateProcessW`, but due to the way they're implemented they cannot be opened normally using a `File::open` that follows reparse points. So this doesn't work with our current `exists` and `try_exists` methods.
Fixes#91177
