rustdoc: stop preloading Source Serif 4 Bold
According to #91170, italic fonts are not preloaded because they're rarely used, but bold fonts are. This seems to be true of bold Source Code Pro and bold Fira Sans, but bold and italic Source Serif Pro seem to be equally heavily used.
This is, I assume, the result of using Fira Sans Bold and Source Code Bold headings, so you only get bold Serif text when the doc author uses strong `**` emphasis (or within certain kinds of tooltip, which shouldn't be preloaded because they only show up long after the page is loaded).
To check this, run these two commands in the browser console to measure how much they're used. The measurement is extremely rough, but it gets the idea across: the two styles are about equally popular.
// count bold elements
Array.prototype.slice.call(document.querySelectorAll("*")).filter(x => { const y = document.defaultView.getComputedStyle(x); return y.fontFamily.indexOf("Source Serif 4") !== -1 && y.fontWeight > 400 }).length
// count italic elements
Array.prototype.slice.call(document.querySelectorAll("*")).filter(x => { const y = document.defaultView.getComputedStyle(x); return y.fontFamily.indexOf("Source Serif 4") !== -1 && y.fontStyle == "italic" }).length
| URL | Bold | Italic |
|--------------|-----:|-------:|
| [std] | 2 | 9 |
| [Vec] | 8 | 89 |
| [regex] | 33 | 17 |
| [test_suite] | 0 | 0 |
[std]: https://doc.rust-lang.org/nightly/std/index.html
[Vec]: https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html
[regex]: https://docs.rs/regex/1.9.5/regex/index.html
[test_suite]: https://docs.rs/test-suite/3.2.9/test_suite/
Give a better diagnostic for missing parens in Fn* bounds
Fixes#108109
It would be nice to try and recover here, but I'm not sure it's worth the effort, especially as the bounds on the recovered function would be incorrect.
Thir unsafeck fixes
- Recognise thread local statics in THIR unsafeck
- Add suggestion for unsafe_op_in_unsafe_fn
- Fix unsafe checking of let expressions
Only instantiate binder during dyn's built-in trait candidate probe once
See UI test for demonstration of the issue.
This was "caused" by #117131, but only because we're using the `normalize_param_env` (which has been augmented with a projection clause used to normalize GATs) which features non-lifetime bound vars in it.
Fixes#117602 technically, though that's also fixed by #117542.
r? types
Build a better MIR body when errors are encountered
Doesn't really have much of an effect on its own, but it does lead to a less confusing phony MIR body being generated when an error is detected during THIR/MIR/match building. This was quite confusing when I hacked `-Zunpretty=mir` to emit `mir_built` rather than `instance_mir`.
This coincidentually also fixes#117413, but not as generally as #117416.
cc `@Nadrieril`
When not finding assoc fn on type, look for builder fn
When we have a resolution error when looking at a fully qualified path on a type, look for all associated functions on inherent impls that return `Self` and mention them to the user.
```
error[E0599]: no function or associated item named `new` found for struct `TcpStream` in the current scope
--> tests/ui/resolve/fn-new-doesnt-exist.rs:4:28
|
4 | let stream = TcpStream::new();
| ^^^ function or associated item not found in `TcpStream`
|
note: if you're trying to build a new `TcpStream` consider using one of the following associated functions:
TcpStream::connect
TcpStream::connect_timeout
--> /home/gh-estebank/rust/library/std/src/net/tcp.rs:156:5
|
156 | pub fn connect<A: ToSocketAddrs>(addr: A) -> io::Result<TcpStream> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
172 | pub fn connect_timeout(addr: &SocketAddr, timeout: Duration) -> io::Result<TcpStream> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Fix#69512.
When we have a resolution error when looking at a fully qualified path
on a type, look for all associated functions on inherent impls that
return `Self` and mention them to the user.
Fix#69512.
Emit explanatory note for move errors in packed struct derives
Derive expansions for packed structs with non-`Copy` fields cause move errors because they prefer copying over borrowing since borrowing the fields of a packed struct can result in unaligned access.
This underlying cause of the errors, however, is not apparent to the user. This PR adds a diagnostic note to make it clear to the user (the new note is on the second last line):
```
tests/ui/derives/deriving-with-repr-packed-move-errors.rs:13:16
|
12 | #[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash, Clone, Default)]
| ----- in this derive macro expansion
13 | struct StructA(String);
| ^^^^^^ move occurs because `self.0` has type `String`, which does not implement the `Copy` trait
|
= note: `#[derive(Debug)]` triggers a move because taking references to the fields of a packed struct is undefined behaviour
= note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Fixes#117406
Partially addresses #110777
Rollup of 4 pull requests
Successful merges:
- #117190 (add test for #113381)
- #117516 (add test for #113375)
- #117631 (Documentation cleanup for core::error::Request.)
- #117637 (Check binders with bound vars for global bounds that don't hold)
r? `@ghost`
`@rustbot` modify labels: rollup
Documentation cleanup for core::error::Request.
This part of the documentation currently render like this:
The new version renders like this:
Fixes:
* Add missing closing back tick.
* Remove spurious double back ticks.
* Add missing newline to render bullet point correctly.
* Fix grammar "there are methods calledrequest_ref and request_value are available" -> "there are methods calledrequest_ref and request_value".
* Change "methods" to "functions", which seems more appropriate for free functions.
Detect misparsed binop caused by missing semi
When encountering
```rust
foo()
*bar = baz;
```
We currently emit potentially two errors, one for the return type of
`foo` not being multiplicative by the type of `bar`, and another for
`foo() * bar` not being assignable.
We now check for this case and suggest adding a semicolon in the right
place and emit only a single error.
Fix#80446.
Make the randomize feature of rustc_abi additive
The goal here is to make rust-analyzer able to build with the `rustc_private` versions of the rustc crates it depends on. See #116847
document that the null pointer has the 0 address
Fixes https://github.com/rust-lang/rust/issues/116895
Will need t-lang FCP, but I think this is fairly uncontroversial -- there's probably already tons of code out there that relies on this.
Rollup of 3 pull requests
Successful merges:
- #117592 (Use the correct span when emitting the `env!` result)
- #117613 (Remove from vacation and compiler review group)
- #117615 (Couple of small changes)
r? `@ghost`
`@rustbot` modify labels: rollup
Couple of small changes
These are unrelated to each other, but they are each small enough that opening separate PR's doesn't make sense to me either.
* Remove a place where the parse driver query is stolen.
* Update an outdated doc comment
* Use correct crate name in `-Zprint-vtable-sizes` when using `#![crate_name = "..."]`.
Remove from vacation and compiler review group
Staying on the types review rotation, but staying off the general review queue is good for me right now.
Also move ``@compiler-errors`` since he's a full member now.
Use the correct span when emitting the `env!` result
The span used for the `env!` resut changed in 1.73, due to 75df62d4a2 (from https://github.com/rust-lang/rust/pull/114014).
This prevents [a lint in `plrustc`](https://github.com/tcdi/plrust/blob/main/plrustc/plrustc/src/lints/builtin_macros.rs#L54-L60)[^1] from working well, because the resulting span is not inside the region where the lint is `#[deny()]`ed.
[^1]: Perhaps worth noting that the `env_macro` diagnostic item comes from [the std fork used with PL/Rust](https://github.com/tcdi/postgrestd/blob/rust-1.73.0/library/core/src/macros/mod.rs#L944).
Unfortunately, I have no idea how to write a test for this since I don't think we can have a custom lint in a test. A suggestion was made to use a custom proc macro for it, but that seems pretty involved (frankly, I might not have time to do it).
r? ``@davidtwco`` (since they're the author of the PR with the regression)
P.S. We generally try to avoid bothering upstream about PL/Rust-specific stuff (we don't want to nag), but this seems like an actual bug, since the other similar macros, such as `option_env` use the other span (and are lintable as a result).
Derive `TyEncodable`/`TyDecodable` in `rustc_type_ir`
when `derive(TyEncodable)` or `derive(TyDecodable)` sees an `I` type parameter on a struct that has no `'tcx`, then parameterize the `TyEncoder`/`TyDecoder`'s interner over that variable rather than `TyCtxt<'tcx>`.
Also, emit where clauses for fields rather than generics.
enable parallel rustc front end in nightly builds
Refers to the [MCP](https://github.com/rust-lang/compiler-team/issues/681), this pr does:
1. Enable the parallel front end in nightly builds, and keep the default number of threads as 1. Then users can use the parallel rustc front end via -Z threads=n option.
2. Set it up to serial front end for beta/stable builds via bootstrap.
3. Switch over the alt builders from parallel rustc to serial, so we have artifacts without parallel to test against the artifacts with parallel.
r? `@oli-obk`
cc `@cjgillot` `@nnethercote` `@bjorn3` `@Kobzol`
Override `Waker::clone_from` to avoid cloning `Waker`s unnecessarily
This would be very useful for futures — I think it’s pretty much always what they want to do instead of `*waker = cx.waker().clone()`.
Tracking issue: https://github.com/rust-lang/rust/issues/98287
r? rust-lang/libs-api `@rustbot` label +T-libs-api -T-libs
Avoid unnecessary comparison in partition_equal
The branchy Hoare partition `partition_equal` as part of `slice::sort_unstable` has a bug that makes it perform a comparison of the last element twice.
Measuring inputs with a Zipfian distribution with characterizing exponent s == 1.0, yields a ~0.05% reduction in the total number of comparisons performed.
improve compiler&tool documenting and re-enable cranelift on CI
First commit addresses the linking issue with compiler crates. Second one ensures that compiler crates are linked correctly (with later commits we added this check for tools as well), allowing us to detect these hard-to-catch bugs on CI. Following three commits cherry-picked from #117328 to re-enable the Cranelift backend on CI.
More info: https://github.com/rust-lang/rust/issues/117430
cc `@bjorn3` `@RalfJung`
Rollup of 4 pull requests
Successful merges:
- #116017 (Don't pass `-stdlib=libc++` when building C files on macOS)
- #117524 (bootstrap/setup: create hooks directory if non-existing)
- #117588 (Remove unused LoadResult::DecodeIncrCache variant)
- #117596 (Add diagnostic items for a few of core's builtin macros)
r? `@ghost`
`@rustbot` modify labels: rollup
