Fix span calculation in format strings
This pull request fixes#86085. The ICE described there is due to an error in the span calculation inside format strings, if the format string is the result of a macro invocation:
```rust
fn main() {
format!(concat!("abc}"));
}
```
currently produces:
```
error: invalid format string: unmatched `}` found
--> test.rs:2:17
|
2 | format!(concat!("abc}"));
| ^ unmatched `}` in format string
```
which is obviously incorrect. This happens because the span of the entire `concat!()` is combined with the _relative_ location of the unmatched `` `}` `` in the _result_ of the macro invocation (i.e. 4).
In #86085, this has led to a span that starts or ends in the middle of a multibyte character, but the root cause was the same. This pull request fixes the problem.
Box `thir::ExprKind::Adt` for performance
`Adt` is the biggest variant in the enum and probably isn't used very often compared to the other expr kinds, so boxing it should be beneficial for performance. We need a perf test to be sure.
optimize Eq implementation for paths
Filesystems generally have a tree-ish structure which means paths are more likely to share a prefix than a suffix. Absolute paths are especially prone to share long prefixes.
quick benchmark consisting of a search through through a vec containing the absolute paths of all (1850) files in `compiler/`:
```
# old
test path::tests::bench_path_cmp ... bench: 227,407 ns/iter (+/- 2,162)
# new
test path::tests::bench_path_cmp ... bench: 64,976 ns/iter (+/- 1,142)
```
Refactor vtable codegen
This refactor the codegen of vtables of miri interpreter, llvm, cranelift codegen backends.
This is preparation for the implementation of trait upcasting feature. cc #65991
Note that aside from code reorganization, there's an internal behavior change here that now InstanceDef::Virtual's index now include the three metadata slots, and now the first method is with index 3.
cc `@RalfJung` `@bjorn3`
Rollup of 8 pull requests
Successful merges:
- #85283 (Avoid possible filename collision in coverage tests)
- #86200 (Updates `Clone` docs for `Copy` comparison.)
- #86209 (fix minor wording/typo issues in core::option docs)
- #86242 (rustdoc- dont ICE on `ConstEvaluatable` predicates)
- #86280 (Add a regression test for issue-76510)
- #86293 (Allow to run only a few GUI tests)
- #86327 (Don't mark "safe" intrinsics as unsafe)
- #86345 (Remove some duplicate `char` assoc items on RELEASES.md)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Allow to run only a few GUI tests
It allows to specify only one (or more) GUI tests. Considering the tests are not super fast to run, this is very useful for development.
cc `@Mark-Simulacrum`
r? `@jsha`
rustdoc- dont ICE on `ConstEvaluatable` predicates
Fixes#77647
rustdoc doesn't need to be handling these as you cant write them, they just get added implicitly when you write a where clause containing an expression.
Updates `Clone` docs for `Copy` comparison.
Quite a few people (myself included) have come under the impression that the difference between `Copy` and `Clone` is that `Copy` is cheap and `Clone` is expensive, where the actual difference is that `Copy` constrains the type to bit-wise copying, and `Clone` allows for more expensive operations. The source of this misconception is in the `Clone` docs, where the following line is in the description:
> Differs from `Copy` in that `Copy` is implicit and extremely inexpensive, while `Clone` is always explicit and may or may not be expensive.
The `Clone` documentation page also comes up before the `Copy` page on google when searching for "the difference between `Clone` and `Copy`".
This PR updates the documentation to clarify that "extremely inexpensive" means an "inexpensive bit-wise copy" to hopefully prevent future rust users from falling into this misunderstanding.
Avoid possible filename collision in coverage tests
Previously, coverage tests were writing profiler data to files based on
their pid. As rustdoc spawns each doctest as its own process, it might
be possible in rare cases that a pid is being reused which would cause
a file to be overwritten, leading to incorrect coverage results.
should help with #83262
r? `@tmandry`
Remove `Ipv6Addr::is_unicast_site_local`
Removes the unstable method `Ipv6Addr::is_unicast_site_local`, see also #85604 where I have tried to summarize related discussion so far.
Unicast site-local addresses (`fec0::/10`) were deprecated in [IETF RFC #3879](https://datatracker.ietf.org/doc/html/rfc3879), see also [RFC #4291 Section 2.5.7](https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.7). Any new implementation must no longer support the special behaviour of site-local addresses. This is mentioned in the docs of `is_unicast_site_local` and already implemented in `is_unicast_global`, which considers addresses in `fec0::/10` to have global scope, thus overlapping with `is_unicast_site_local`.
Given that RFC #3879 was published in 2004, long before Rust existed, and it is specified that any new implementation must no longer support the special behaviour of site-local addresses, I don't see how a user would ever have a need for `is_unicast_site_local`. It is also confusing that currently both `is_unicast_site_local` and `is_unicast_global` can be `true` for an address, but an address can actually only have a single scope. The deprecating RFC mentions that Site-Local scope was confusing to work with and that the classification of an address as either Link-Local or Global better matches the mental model of users.
There has been earlier discussion of removing `is_unicast_site_local` (https://github.com/rust-lang/rust/pull/60145#issuecomment-485970669) which decided against it, but that had the incorrect assumption that the method was already stable; it is not. (This confusion arose from the placement of the unstable attribute on the entire module, instead of on individual methods, resolved in #85672)
r? `@joshtriplett` as reviewer of all the related PRs
Currently the same message is used for hard errors and soft errors. This
makes hard errors use a message that indicates the reality of the
situation correctly, since usage of the constant is never allowed when
there was a hard error evaluating it.
Integrate binary search codes of binary_search_by and partition_point
For now partition_point has own binary search code piece.
It is because binary_search_by had called the comparer more times and the author (=me) wanted to avoid it.
However, now binary_search_by uses the comparer minimum times. (#74024)
So it's time to integrate them.
The appearance of the codes are a bit different but both use completely same logic.
Stabilize {std, core}::prelude::rust_*.
This stabilizes the `{core, std}::prelude::{rust_2015, rust_2018, rust_2021}` modules.
The usage of these modules as the prelude in those editions was already stabilized. This just stabilizes the modules themselves, making it possible for a user to explicitly refer to them.
Tracking issue: https://github.com/rust-lang/rust/issues/85684
FCP on the RFC that included this finished here: https://github.com/rust-lang/rfcs/pull/3114#issuecomment-840577395
Remove must_use from ALLOWED_ATTRIBUTES
This is a fairly common attribute on methods, but is not something you need to know when reading the method docs - the purpose of the attribute is for the compiler to tell you about it if you forget to use a value.
Removing reclaims some valuable space in the summary of methods, particularly when the attribute has a long string value.
As discussed in #84309. Partially addresses #81482.
r? ```@Manishearth```
