rustdoc: Show the correct source filename in page titles, without `.html`
Previously the title would be
lib.rs.html -- source
if `lib.rs` was the actual source filename. Now the title is
lib.rs - source
Improve wording of "cannot multiply" type error
For example, if you had this code:
fn foo(x: i32, y: f32) -> f32 {
x * y
}
You would get this error:
error[E0277]: cannot multiply `f32` to `i32`
--> src/lib.rs:2:7
|
2 | x * y
| ^ no implementation for `i32 * f32`
|
= help: the trait `Mul<f32>` is not implemented for `i32`
However, that's not usually how people describe multiplication. People
usually describe multiplication like how the division error words it:
error[E0277]: cannot divide `i32` by `f32`
--> src/lib.rs:2:7
|
2 | x / y
| ^ no implementation for `i32 / f32`
|
= help: the trait `Div<f32>` is not implemented for `i32`
So that's what this change does. It changes this:
error[E0277]: cannot multiply `f32` to `i32`
--> src/lib.rs:2:7
|
2 | x * y
| ^ no implementation for `i32 * f32`
|
= help: the trait `Mul<f32>` is not implemented for `i32`
To this:
error[E0277]: cannot multiply `i32` by `f32`
--> src/lib.rs:2:7
|
2 | x * y
| ^ no implementation for `i32 * f32`
|
= help: the trait `Mul<f32>` is not implemented for `i32`
Add Pin::static_ref, static_mut.
This adds `Pin::static_ref` and `Pin::static_mut`, which convert a static reference to a pinned static reference.
Static references are effectively already pinned, as what they refer to has to live forever and can never be moved.
---
Context: I want to update the `sys` and `sys_common` mutexes/rwlocks/condvars to use `Pin<&self>` in their functions, instead of only warning in the unsafety comments that they may not be moved. That should make them a little bit less dangerous to use. Putting such an object in a `static` (e.g. through `sys_common::StaticMutex`) fulfills the requirements about never moving it, but right now there's no safe way to get a `Pin<&T>` to a `static`. This solves that.
Rollup of 9 pull requests
Successful merges:
- #78046 (Add codegen test for issue #73827)
- #78061 (Optimize const value interning for ZST types)
- #78070 (we can test std and core panic macros together)
- #78076 (Move orphan module-name/mod.rs files into module-name.rs files)
- #78129 (Wrapping intrinsics doc links update.)
- #78133 (Add some MIR-related regression tests)
- #78144 (Don't update `entries` in `TypedArena` if T does not need drop)
- #78145 (Drop unneeded `mut`)
- #78157 (Remove unused type from librustdoc)
Failed merges:
r? `@ghost`
Drop unneeded `mut`
These parameters don't get modified.
Note that `trailing_comment` is pub and gets exported from `rustc_ast_pretty`. Is that considered to be a stable API? If yes, and you want to reserve the right to modify `self` in `trailing_comment` in the future, that hunk would need to be dropped.
Don't update `entries` in `TypedArena` if T does not need drop
As far as I can tell, `entries` is only used when dropping `TypedArenaChunk`s and their contents. It is already ignored there, if T is not `mem::needs_drop`, this PR just skips updating it's value.
You can see `TypedArenaChunk` ignoring the entry count in L71. The reasoning is similar to what you can find in `DroplessArena`.
r? @oli-obk
Wrapping intrinsics doc links update.
The links in the wrapping intrinsics docs now refer to the `wrapping_*` functions, not the `checked_*` functions.
Since having enabled the download-ci-llvm option,
and having rebased on top of f05b47ccdfa63f8b4b9fb47a9aa92381801d3ff1,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.
This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.
An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.
Disable MatchBranchSimplification
This optimization can result in unsoundness, because it introduces
additional uses of a place holding the discriminant value without
ensuring that it is valid to do so.
Found by validation from #77369 / #78147.
Improve `skip_binder` usage during FlagComputation
It looks like there was previously a bug around `ExistentialPredicate::Projection` here, don't know how to best trigger that one to add a regression test though.
Rollup of 10 pull requests
Successful merges:
- #77612 (BTreeMap: test invariants more thoroughly and more readably)
- #77761 (Assert that pthread mutex initialization succeeded)
- #77778 ([x.py setup] Allow setting up git hooks from other worktrees)
- #77838 (const keyword: brief paragraph on 'const fn')
- #77923 ([net] apply clippy lints)
- #77931 (Fix false positive for `unused_parens` lint)
- #77959 (Tweak ui-tests structure)
- #78105 (change name in .mailmap)
- #78111 (Trait predicate ambiguities are not always in `Self`)
- #78121 (Do not ICE on pattern that uses a binding multiple times in generator)
Failed merges:
r? `@ghost`
Trait predicate ambiguities are not always in `Self`
When reporting ambiguities in trait predicates, the compiler incorrectly assumed the ambiguity was always in the type the trait should be implemented on, and never the generic parameters of the trait. This caused silly suggestions for predicates like `<KnownType as Trait<_>>`, such as giving explicit types to completely unrelated variables that happened to be of type `KnownType`.
This also reverts #73027, which worked around this issue in some cases and does not appear to be necessary any more.
fixes#77982fixes#78055
