These methods work very similarly to `Option`'s methods `as_ref` and
`as_mut`. They are useful in several situation, particularly when
calling other array methods (like `map`) on the result. Unfortunately,
we can't easily call them `as_ref` and `as_mut` as that would shadow
those methods on slices, thus being a breaking change (that is likely
to affect a lot of code).
Rollup of 6 pull requests
Successful merges:
- #80809 (Use standard formatting for "rust-call" ABI message)
- #80872 (Fix typo in source-based-code-coverage.md)
- #80878 (Add ABI argument to `find_mir_or_eval_fn`)
- #80881 ( Fix intra-doc links to `Self` and `crate` )
- #80887 (log-color: Detect TTY based on stderr, not stdout)
- #80892 (rustdoc: Remove `*` intra-doc alias for `pointer`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Remove `*` intra-doc alias for `pointer`
It's not valid Rust code and it can easily be confused with a wildcard
glob pattern or something else. People can always use `pointer` instead,
so it's just removing an alias.
It hasn't hit stable yet (I think it's still on nightly), so it's okay
to remove it. (We can always add it back later if we change our mind
too.)
r? `@jyn514`
cc https://github.com/rust-lang/rust/pull/80885#discussion_r554622737
log-color: Detect TTY based on stderr, not stdout
Fixes#78435 (again).
Logging goes to stderr, not stdout, so we should base our automated
detection on stderr instead of stdout.
Thanks to Ralf Jung for noticing and reporting the bug!
r? `@oli-obk`
cc `@RalfJung`
Add ABI argument to `find_mir_or_eval_fn`
Add ABI argument for called function in `find_mir_or_eval_fn` and
`call_extra_fn`. Useful for comparing with expected ABI in interpreters.
Related to [miri/1631](https://github.com/rust-lang/miri/issues/1631)
r? `@RalfJung`
Use standard formatting for "rust-call" ABI message
Nearly all error messages start with a lowercase letter and don't use
articles - instead they refer to the plural case.
Don't build in-tree llvm-libunwind if system-llvm-libunwind is enable
When "system-llvm-libunwind" is enabled, some target eg. musl still build in-tree llvm-libunwind which is useless.
It's not valid Rust code and it can easily be confused with a wildcard
glob pattern or something else. People can always use `pointer` instead,
so it's just removing an alias.
It hasn't hit stable yet (I think it's still on nightly), so it's okay
to remove it. (We can always add it back later if we change our mind
too.)
resolve: Scope visiting doesn't need an `Ident`
Resolution scope visitor (`fn visit_scopes`) currently takes an `Ident` parameter, but it doesn't need a full identifier, or even its span, it only needs the `SyntaxContext` part.
The `SyntaxContext` part is necessary because scope visitor has to jump to macro definition sites, so it has to be directed by macro expansion information somehow.
I think it's clearer to pass only the necessary part.
Yes, usually visiting happens as a part of an identifier resolution, but in cases like collecting traits in scope (#80765) or collecting typo suggestions that's not the case.
r? `@matthewjasper`
Logging goes to stderr, not stdout, so we should base our automated
detection on stderr instead of stdout.
Thanks to Ralf Jung for noticing and reporting the bug!
People almost always are referring to `&str`, not `str`, so this will
save a manual link resolve in many cases.
Note that we already accept `&` (resolves to `reference`) in intra-doc
links, so this shouldn't cause breakage.
Add ABI argument for called function in `find_mir_or_eval_fn` and
`call_extra_fn`. Useful for comparing with expected ABI in interpreters.
Related to [miri/1631](https://github.com/rust-lang/miri/issues/1631)
BTreeMap: tougher checking on most uses of copy_nonoverlapping
Miri checks pointer provenance and destination, but we can check it in debug builds already.
Also, we can let Miri confirm we don't mistake imprints of moved keys and values as genuine.
r? `@Mark-Simulacrum`
Allow #[rustc_builtin_macro = "name"]
This adds the option of specifying the name of a builtin macro in the `#[rustc_builtin_macro]` attribute: `#[rustc_builtin_macro = "name"]`.
This makes it possible to have both `std::panic!` and `core::panic!` as a builtin macro, by using different builtin macro names for each. This is needed to implement the edition-specific behaviour of the panic macros of RFC 3007.
Also removes `SyntaxExtension::is_derive_copy`, as the macro name (e.g. `sym::Copy`) is now tracked and provides that information directly.
r? ``@petrochenkov``
Remove under-used ImplPolarity enum
It doesn't make much sense to have an enum with only two possible values and to store it inside an `Option` in my opinion when you can do all the same with a simple boolean. I don't expect any chances, performance or RSS usage wise.
r? ``@jyn514``
Support `download-ci-llvm` on NixOS
In particular, the CI built `libLLVM-*.so` needs to have `libz.so`
RPATHed so that binaries like `llvm-config` work at all.
Use correct span for structured suggestion
On structured suggestion for `let` -> `const` and `const` -> `let`, use
a proper `Span` and update tests to check the correct application.
Follow up to #80012.
Fix safety comment
The size assertion in the comment was inverted compared to the code. After fixing that the implication that `(new_size >= old_size) => new_size != 0` still doesn't hold so explain why `old_size != 0` at this point.
Improve core::ptr::drop_in_place debuginfo
* Use span of the dropped type as function span when possible.
* Rename symbol from `core::ptr::drop_in_place::$hash` to `{{drop}}::<$TYPE>::$hash`.
Fixes#77465
(I haven't yet updated the tests)
Implement From<char> for u64 and u128.
With this PR you can write
```
let u = u64::from('👤');
let u = u128::from('👤');
```
Previously, you could already write `as` conversions ([Playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cee18febe28e69024357d099f07ca081)):
```
// Lossless conversions
dbg!('👤' as u32); // Prints 128100
dbg!('👤' as u64); // Prints 128100
dbg!('👤' as u128); // Prints 128100
// truncates, thus no `From` impls.
dbg!('👤' as u8); // Prints 100
dbg!('👤' as u16); // Prints 62564
// These `From` impls already exist.
dbg!(u32::from('👤')); // Prints 128100
dbg!(u64::from(u32::from('👤'))); // Prints 128100
```
The idea is from ``@gendx`` who opened [this Internals thread](https://internals.rust-lang.org/t/implement-from-char-for-u64/13454), and ``@withoutboats`` responded that someone should open a PR for it.
Some people mentioned `From<char>` impls for `f32` and `f64`, but that doesn't seem correct to me, so I didn't include them here.
I don't know what the feature should be named. Must it be registered somewhere, like unstable features?
r? ``@withoutboats``
Rustdoc: Fix macros 2.0 and built-in derives being shown at the wrong path
Fixes#74355
- ~~waiting on author + draft PR since my code ought to be cleaned up _w.r.t._ the way I avoid the `.unwrap()`s:~~
- ~~dummy items may avoid the first `?`,~~
- ~~but within the module traversal some tests did fail (hence the second `?`), meaning the crate did not possess the exact path of the containing module (`extern` / `impl` blocks maybe? I'll look into that).~~
r? `@jyn514`
