Adds an additional hint to failures where we encounter an else keyword
while we're parsing an if-let block.
This is likely that the user has accidentally mixed if-let and let...else
together.
* Changes the class names so that they all start with `setting-`.
That should make it harder to accidentally use a setting class outside
the settings popover, where loading the CSS might accidentally change
the styles of something unrelated.
* Get rid of an unnecessary wrapper DIV around the radio button line.
* Simplify CSS selectors by making the DOM easier and more intuitive
to target.
remove error code from `E0789`, add UI test/docs
`E0789` shouldn't have an error code, it's explicitly internal-only and is tiny in scope. (I wonder if we can tighten the standard for this in the RFC?) I also added a UI test and error docs (done like `E0208`, they are "no longer emitted").
r? `@GuillaumeGomez` (shouldn't need a compiler review, it's pretty minor)
Consider doc(alias) when providing typo suggestions
This means that
```rust
impl Foo {
#[doc(alias = "quux")]
fn bar(&self) {}
}
fn main() {
(Foo {}).quux();
}
```
will suggest `bar`. This currently uses the "there is a method with a similar name" help text, because the point where we choose and emit a suggestion is different from where we gather the suggestions. Changes have mainly been made to the latter.
The selection code will now fall back to aliased candidates, but generally only if there is no candidate that matches based on the existing Levenshtein methodology.
Fixes#83968.
...and remove it from `PointeeInfo`, which isn't meant for this.
There are still various places (marked with FIXMEs) that assume all pointers
have the same size and alignment. Fixing this requires parsing non-default
address spaces in the data layout string, which will be done in a followup.
This means that
```rust
impl Foo {
#[doc(alias = "quux")]
fn bar(&self) {}
}
fn main() {
(Foo {}).quux();
}
```
will suggest `bar`. This currently uses the "there is a method with a
similar name" help text, because the point where we choose and emit a
suggestion is different from where we gather the suggestions. Changes
have mainly been made to the latter.
The selection code will now fall back to aliased candidates, but
generally only if there is no candidate that matches based on the
existing Levenshtein methodology.
Fixes#83968.
Rollup of 8 pull requests
Successful merges:
- #103418 (Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report)
- #106113 (llvm-wrapper: adapt for LLVM API change)
- #106144 (Improve the documentation of `black_box`)
- #106578 (Label closure captures/generator locals that make opaque types recursive)
- #106749 (Update cc to 1.0.77)
- #106935 (Fix `SingleUseLifetime` ICE)
- #107015 (Re-enable building rust-analyzer on riscv64)
- #107029 (Add new bootstrap members to triagebot.toml)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report
See https://github.com/rust-lang/rust/issues/79813 for a discussion of this lint. This has been warn-by-default for over a year, so adding it to the future-incompat report should help to find libraries that haven't yet updated.
Revert "Make PROC_MACRO_DERIVE_RESOLUTION_FALLBACK a hard error"
This reverts commit 7d82cadd97 aka PR #84022
I am doing this to buy us some time with respect to issue #106337 w.r.t. the 1.67 release.
Remap paths in UI tests by default
If you think this needs further discussions / something RFC-like, please let me know the best forum for that.
This PR runs UI tests with a remapped "src base" directory by default.
Why? Because some UI tests currently depend on the length of the absolute path to the `src/test/ui` directory. Remapping makes the tests independent of the absolute path.
The path to the source file (which is absolute on CI) is part of the type name of closures. `rustc` diagnostic output depends on the length of type names (long type names are truncated). So a long absolute path leads to long closure type names, which leads to truncation and changed diagnostics.
(I initially tried just disabling type name truncation, but that made some error messages stupid long (thousands of characters, IIRC)).
Additional changes:
* All boolean `compiletest` directives now support explicit `no-` versions to disable them.
* Adapt existing tests when necessary:
* Disable remapping for individual tests that fail with it enabled (when there's no obvious alternative fix).
* For tests that already check something remapping related switch to the new option unless we gain something significant by keeping the manual remap.
Passed Windows CI in https://github.com/rust-lang/rust/actions/runs/3933100590
Implement some more new solver candidates and fix some bugs
First, fix some bugs:
1. `IndexVec::drain_enumerated(a..b)` does not give us an iterator of index keys + items enumerated from `a..b`, but from `0..(b-a)`... That caused a bug. See first commit for the fix.
2. Implement the `_: Trait` ambiguity hack. I put it in assemble, let me know if it should live elsewhere. This is important, since we otherwise consider `_: Sized` to have no solutions, and nothing passes!
3. Swap `Ambiguity` and `Unimplemented` cases for the new solver. Sorry for accidentally swapping them 😄
4. Check GATs' own predicates during projection confirmation.
Then implement a few builtin traits:
5. Implement `PointerSized`. Pretty independent.
6. Implement `Fn` family of traits for fnptr, fndef, and closures. Closures are currently broken because `FulfillCtxt::relationships` is intentionally left unimplemented. See comment in the test.
r? ```@lcnr```
Change `bindings_with_variant_name` to deny-by-default
Changed the `bindings_with_variant_name` lint to deny-by-default and fixed up the affected tests.
Addresses #103442.
[drop tracking] Visit break expressions
This fixes https://github.com/rust-lang/rust/issues/102383 by remembering to visit the expression in `break expr` when building the drop tracking CFG. Missing this step was causing an off-by-one error which meant after a number of awaits we'd be
looking for dropped values at the wrong point in the code.
Additionally, this changes the order of traversal for assignment expressions to visit the rhs and then the lhs. This matches what is done elsewhere.
Finally, this improves some of the debugging output (for example, the CFG visualizer) to make it easier to figure out these sorts of issues.
Added const-generic ui test case for issue #106419
This PR adds a test case for #106419 which has been fixed in master by #105292
I also ran the test on f769d34291 (the commit before #105292 was merged)
and it did fail there with the following output.
```
--- stderr -------------------------------
error[E0308]: mismatched types
--> /home/patrikk/src/rust/src/test/ui/const-generics/issue-106419-struct-with-multiple-const-params.rs:5:10
|
LL | #[derive(Clone)]
| ^^^^^
| |
| expected `A`, found `B`
| expected `Bar<A, B>` because of return type
|
= note: expected struct `Bar<A, _>`
found struct `Bar<B, _>`
= note: this error originates in the derive macro `Clone` (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
------------------------------------------
```
Recognise double-equals homoglyph
Recognise `⩵` as a homoglyph for `==`.
The first commit switches `char` to `&str`, as all previous homoglyphs corresponded to a single ASCII character, while the second implements the fix.
`@rustbot` label +A-diagnostics +A-parser
Don't treat closures from other crates as local
fixes#104817
r? `@lcnr`
Specialization can prefer an impl for an opaque type over a blanket impls that also matches. If the blanket impl only applies if an auto-trait applies, we look at the hidden type of the opaque type to see if that implements the auto trait. The hidden type can be a closure or generator, and thus we will end up seeing these types in coherence and have to handle them properly.
Don't wf-check non-local RPITs
We were using `ty::is_impl_trait_defn(..).is_none()` to check if we need to add WF obligations for an opaque type.
This is *supposed* to be checking if the type is a TAIT, since RPITs' wfness is implied by wf checking its parent item, but since `is_impl_trait_defn` returns `None` for non-local RPIT and async futures, we unnecessarily consider wf predicates for an RPIT if it is coming from a foreign crate.
Fixes#107036
r? `@oli-obk` but feel free to reassign
even more unify Projection/Opaque handling in region outlives code
edit: This continues ate the same pace as #106829. New changes are described in https://github.com/rust-lang/rust/pull/106910#issuecomment-1383251254.
~This touches `OutlivesBound`, `Component`, `GenericKind` enums.~
r? `@oli-obk` (because of overlap with #95474)
Rollup of 5 pull requests
Successful merges:
- #105977 (Transform async `ResumeTy` in generator transform)
- #106927 (make `CastError::NeedsDeref` create a `MachineApplicable` suggestion)
- #106931 (document + UI test `E0208` and make its output more user-friendly)
- #107027 (Remove extra removal from test path)
- #107037 (Fix Dominators::rank_partial_cmp to match documentation)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
document + UI test `E0208` and make its output more user-friendly
Cleans up `E0208`'s output a lot. It could actually be useful for someone learning about variance now. I also added a UI test for it in `tests/ui/error-codes/` and wrote some docs for it.
r? `@GuillaumeGomez` another error code, can't be bothered to find the issue :P. Obviously there's some compiler stuff, so you'll have to hand it off.
Part of https://github.com/rust-lang/rust/issues/61137.
make `CastError::NeedsDeref` create a `MachineApplicable` suggestion
Fixes#106903
Simple impl for the linked issue. I also made some other small changes:
- `CastError::ErrorGuaranteed` now owns an actual `ErrorGuaranteed`. This better enforces the static guarantees of `ErrorGuaranteed`.
- `CastError::NeedDeref` code simplified a bit, we now just suggest the `*`, instead of the whole expression as well.
Transform async `ResumeTy` in generator transform
- Eliminates all the `get_context` calls that async lowering created.
- Replace all `Local` `ResumeTy` types with `&mut Context<'_>`.
The `Local`s that have their types replaced are:
- The `resume` argument itself.
- The argument to `get_context`.
- The yielded value of a `yield`.
The `ResumeTy` hides a `&mut Context<'_>` behind an unsafe raw pointer, and the `get_context` function is being used to convert that back to a `&mut Context<'_>`.
Ideally the async lowering would not use the `ResumeTy`/`get_context` indirection, but rather directly use `&mut Context<'_>`, however that would currently lead to higher-kinded lifetime errors.
See <https://github.com/rust-lang/rust/issues/105501>.
The async lowering step and the type / lifetime inference / checking are still using the `ResumeTy` indirection for the time being, and that indirection is removed here. After this transform, the generator body only knows about `&mut Context<'_>`.
---
Fixes https://github.com/bjorn3/rustc_codegen_cranelift/issues/1330 CC `@bjorn3`
r? `@compiler-errors`
Implement `alloc::vec::IsZero` for `Option<$NUM>` types
Fixes#106911
Mirrors the `NonZero$NUM` implementations with an additional `assert_zero_valid`.
`None::<i32>` doesn't stricly satisfy `IsZero` but for the purpose of allocating we can produce more efficient codegen.
- Eliminates all the `get_context` calls that async lowering created.
- Replace all `Local` `ResumeTy` types with `&mut Context<'_>`.
The `Local`s that have their types replaced are:
- The `resume` argument itself.
- The argument to `get_context`.
- The yielded value of a `yield`.
The `ResumeTy` hides a `&mut Context<'_>` behind an unsafe raw pointer, and the
`get_context` function is being used to convert that back to a `&mut Context<'_>`.
Ideally the async lowering would not use the `ResumeTy`/`get_context` indirection,
but rather directly use `&mut Context<'_>`, however that would currently
lead to higher-kinded lifetime errors.
See <https://github.com/rust-lang/rust/issues/105501>.
The async lowering step and the type / lifetime inference / checking are
still using the `ResumeTy` indirection for the time being, and that indirection
is removed here. After this transform, the generator body only knows about `&mut Context<'_>`.
Various cleanups around pre-TyCtxt queries and functions
part of #105462
based on https://github.com/rust-lang/rust/pull/106776 (everything starting at [0e2b39f](0e2b39fd1f) is new in this PR)
r? `@petrochenkov`
I think this should be most of the uncontroversial part of #105462.
Rollup of 8 pull requests
Successful merges:
- #105796 (rustdoc: simplify JS search routine by not messing with lev distance)
- #106753 (Make sure that RPITITs are not considered suggestable)
- #106917 (Encode const mir for closures if they're const)
- #107004 (Implement some candidates for the new solver (redux))
- #107023 (Stop using `BREAK` & `CONTINUE` in compiler)
- #107030 (Correct typo)
- #107042 (rustdoc: fix corner cases with "?" JS keyboard command)
- #107045 (rustdoc: remove redundant CSS rule `#settings .setting-line`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: remove redundant CSS rule `#settings .setting-line`
Since the current version of settings.js always nests things below a div with ID `settings`, this rule always overrode the one above.
rustdoc: simplify JS search routine by not messing with lev distance
Since the sorting function accounts for an `index` field, there's not much reason to also be applying changes to the levenshtein distance. Instead, we can just not treat `lev` as a filter if there's already a non-sentinel value for `index`.
<details>
This change gives slightly more weight to the index and path part, as search criteria, than it used to. This changes some of the test cases, but not in any obviously-"worse" way, and, in particular, substring matches are a bigger deal than levenshtein distances (we're assuming that a typo is less likely than someone just not typing the entire name).
The biggest change is the addition of a `path_lev` field to result items. It's always zero if the search query has no parent path part and for type queries, making the check in the `sortResults` function a no-op. When it's present, it is used to implement different precedence for the parent path and the tail.
Consider the query `hashset::insert`, a test case [that already exists and can be found here](5c6a1681a9/src/test/rustdoc-js-std/path-ordering.js). We want the ordering shown in the test case:
```
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_with' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_owned' },
{ 'path': 'std::collections::hash_map::HashMap', 'name': 'insert' },
```
We do not want this ordering, which is the ordering that would occur if substring position took priority over `path_lev`:
```
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'insert' },
{ 'path': 'std::collections::hash_map::HashMap', 'name': 'insert' }, // BAD
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_with' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_owned' },
```
We also do not want `HashSet::iter` to appear before `HashMap::insert`, which is what would happen if `path_lev` took priority over the appearance of any substring match. This is why the `sortResults` function has `path_lev` sandwiched between a `index < 0` check and a `index` comparison check:
```
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_with' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'get_or_insert_owned' },
{ 'path': 'std::collections::hash_set::HashSet', 'name': 'iter' }, // BAD
{ 'path': 'std::collections::hash_map::HashMap', 'name': 'insert' },
```
The old code implemented a similar feature by manipulating the `lev` member based on whether a substring match was found and averaging in the path distance (`item.lev = name_lev + path_lev / 10`), so the path lev wound up acting like a tie breaker, but it gives slightly different results for `Vec::new`, [changing the test case](https://github.com/rust-lang/rust/pull/105796/files#diff-b346e2ef72a407915f438063c8c2c04f7a621df98923d441b41c0312211a5b21) because of the slight changes to ordering priority.
</details>
Based on https://github.com/rust-lang/rust/pull/103710#issuecomment-1296894296
Previews:
* https://notriddle.com/notriddle-rustdoc-demos/rustdoc-search-stop-doing-demerits/std/index.html
* https://notriddle.com/notriddle-rustdoc-demos/rustdoc-search-stop-doing-demerits-compiler/index.html
Revert "Improve heuristics whether `format_args` string is a source literal"
This reverts commit e6c02aad93 (from #106195).
Keeps the code improvements from the PR and the test (as a known-bug).
Works around #106408 while a proper fix is discussed more thoroughly in #106505, as proposed by `@tmandry.`
Reopens#106191
r? compiler-errors
This prevents some strange blur-event-related bugs with the "?" command
by ensuring that the focus remains in the same spot when the settings
area closes.
Do not filter substs in `remap_generic_params_to_declaration_params`.
The relevant filtering should have been performed by borrowck.
Fixes https://github.com/rust-lang/rust/issues/105826
r? types
dont randomly use `_` to print out const generic arguments
const generics seem to get printed out as `_` for no reason a lot of the time, as someone who spends a lot of time with const generics this has gotten ✨ very annoying ✨. Latest example would be #106423 where the ICE messaged formatted a `ty::Const` containing no infer vars, as `_`.
For some reason printing of the const argument on arrays was custom instead of using the existing logic for printing `ty::Const`. Additionally the existing logic for printing `ty::Const` would print out `_` for anon consts that are in a separate crate leading to weird diagnostics (see second commit). There ought to be less cases of consts randomly getting printed as `_` hiding valuable info now.
Add 'static lifetime suggestion when GAT implied 'static requirement from HRTB
Fix for issue #105507
The problem:
When generic associated types (GATs) are from higher-ranked trait bounds (HRTB), they are implied 'static requirement (see
[Implied 'static requirement from higher-ranked trait bounds](https://blog.rust-lang.org/2022/10/28/gats-stabilization.html#implied-static-requirement-from-higher-ranked-trait-bounds) for more details). If the user did not explicitly specify the `'static` lifetime when using the GAT, the current error message will only point out the type `does not live long enough` where the type is used, but not where the GAT is specified and how to fix the problem.
The solution:
Add notes at the span where the problematic GATs are specified and suggestions of how to fix the problem by adding `'static` lifetime at the right spans.
Rollup of 7 pull requests
Successful merges:
- #104505 (Remove double spaces after dots in comments)
- #106784 (prevent E0512 from emitting [type error] by checking the references_error)
- #106834 (new trait solver: only consider goal changed if response is not identity)
- #106889 (Mention the lack of `windows_mut` in `windows`)
- #106963 (Use `scope_expr_id` from `ProbeCtxt`)
- #106970 (Switch to `EarlyBinder` for `item_bounds` query)
- #106980 (Hide `_use_mk_alias_ty_instead` in `<AliasTy as Debug>::fmt`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Put `noundef` on all scalars that don't allow uninit
Previously, it was only put on scalars with range validity invariants like bool, was uninit was obviously invalid for those.
Since then, we have normatively declared all uninit primitives to be undefined behavior and can therefore put `noundef` on them.
The remaining concern was the `mem::uninitialized` function, which cause quite a lot of UB in the older parts of the ecosystem. After #99182, this function now doesn't return uninit values anymore, making users of it safe from this change.
The only real sources of UB where people could encounter uninit primitives are `MaybeUninit::uninit().assume_init()`, which has always be clear in the docs about being UB and from heap allocations (like reading from the spare capacity of a vec). This is hopefully rare enough to not break anything.
cc `@nagisa` `@scottmcm` `@nikic`
Constify `TypeId` ordering impls
Tracking issue: #101871
Adding const ordering to `TypeId` allows rtti crates to optimize some casting scenarios (without transmuting to `u64`). This would also prevent these crates from breaking if the underlying type is changed from `u64` to something different.
Feature gate: `#![feature(const_cmp_type_id)]`
fix: don't emit `E0711` if `staged_api` not enabled
Fixes#106589
Simple fix, added UI test.
As an aside, it seems a lot of features are susceptible to this, `E0711` stands out to me because it's perma-unstable and we are effectively exposing an implementation detail.
Previously, it was only put on scalars with range validity invariants
like bool, was uninit was obviously invalid for those.
Since then, we have normatively declared all uninit primitives to be
undefined behavior and can therefore put `noundef` on them.
The remaining concern was the `mem::uninitialized` function, which cause
quite a lot of UB in the older parts of the ecosystem. This function now
doesn't return uninit values anymore, making users of it safe from this
change.
The only real sources of UB where people could encounter uninit
primitives are `MaybeUninit::uninit().assume_init()`, which has always
be clear in the docs about being UB and from heap allocations (like
reading from the spare capacity of a vec. This is hopefully rare enough
to not break anything.
rustdoc: remove redundant item kind class from `.item-decl > pre`
This class originated in the very first commit of `rustdoc_ng`, and was used to add a color border around the item decl based on its kind.
4fd061c426/src/rustdoc_ng/html/static/main.css (L102-L106)
The item decl no longer has a border, and there aren't any kind-specific styles in modern rustdoc's rendering of this UI item.
Most of this PR is updating test cases so that they use `item-decl` to find the `<pre>` tag instead of relying on the fact that the class name had `rust {kind}` in it while other `<pre>` tags only had class `rust`.
make error emitted on `impl &Trait` nicer
Fixes#106694
Turned out to be simpler than I thought, also added UI test.
Before: ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9bda53271ef3a8886793cf427b8cea91))
```text
error: expected one of `:`, ``@`,` or `|`, found `)`
--> src/main.rs:2:22
|
2 | fn foo(_: impl &Trait) {}
| ^ expected one of `:`, ``@`,` or `|`
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a parameter name, give it a type
|
2 | fn foo(_: impl Trait: &TypeName) {}
| ~~~~~~~~~~~~~~~~
help: if this is a type, explicitly ignore the parameter name
|
2 | fn foo(_: impl _: &Trait) {}
| ++
error: expected one of `!`, `(`, `)`, `,`, `?`, `for`, `~`, lifetime, or path, found `&`
--> src/main.rs:2:16
|
2 | fn foo(_: impl &Trait) {}
| -^ expected one of 9 possible tokens
| |
| help: missing `,`
error: expected one of `!`, `(`, `,`, `=`, `>`, `?`, `for`, `~`, lifetime, or path, found `&`
--> src/main.rs:3:11
|
3 | fn bar<T: &Trait>(_: T) {}
| ^ expected one of 10 possible tokens
```
After:
```text
error: expected a trait, found type
--> <anon>:2:16
|
2 | fn foo(_: impl &Trait) {}
| -^^^^^
| |
| help: consider removing the indirection
error: expected a trait, found type
--> <anon>:3:11
|
3 | fn bar<T: &Trait>(_: T) {}
| -^^^^^
| |
| help: consider removing the indirection
```
suggestion for attempted integer identifier in patterns
Fixes#106552
Implemented a suggestion on `E0005` that occurs when no bindings are present and the pattern is a literal integer.
Heuristically undo path prefix mappings.
Because the compiler produces better diagnostics if it can find the source of (potentially remapped) dependencies.
The new test fails without the other changes in this PR. Let me know if you have better suggestions for the test directory. I moved the existing remapping test to be in the same location as the new one.
Some more context: I'm exploring running UI tests with remapped paths by default in https://github.com/rust-lang/rust/pull/105924 and this was one of the issues discovered.
This may also be useful in the context of https://github.com/rust-lang/rfcs/pull/3127 ("New rustc and Cargo options to allow path sanitisation by default").
Emit only one nbsp error per file
Fixes#106101.
See https://github.com/rust-lang/rust/issues/106098 for an explanation of how someone would end up with a large number of these nbsp characters in their source code, which is why I think rustc needs to handle this specific case in a friendlier way.
Rollup of 5 pull requests
Successful merges:
- #106888 (Add tidy check to ensure that rustdoc GUI tests start with a small description)
- #106896 (suggest `is_empty` for collections when casting to `bool`)
- #106900 (Fix regression in `unused_braces` with macros)
- #106906 (remove redundant clones)
- #106909 (Only suggest adding type param if path being resolved was a type)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
suggest `is_empty` for collections when casting to `bool`
Fixes#106883
Matches on slices, `String` and `str`. It would be nice to do this with something like `Deref<Target=str>` as well, but AFAIK it's not possible in this part of the compiler.
Add tidy check to ensure that rustdoc GUI tests start with a small description
The first commit comes from https://github.com/rust-lang/rust/pull/106865 to prevent CI to fail.
This PR adds a tidy check to enforce having a small description at the top of the GUI test. Although the format is made to be as easy as possible to read, it's not always obvious what a test is actually checking. I think enforcing this will make it easier for us to come back on these tests if needed.
r? `@notriddle`
Simplify manual ptr arithmetic in slice::Iter with ptr_sub
The old code was introduced in #61885, which predates the ptr_sub method and underlying intrinsic. The codegen test still passes.
r? `@scottmcm`
The optimization that removes artifacts when building libraries is correct
from the compiler's perspective but not from a debugger's perspective.
Unpacked split debuginfo is referred to by filename and debuggers need
the artifact that contains debuginfo to continue to exist at that path.
Ironically the test expects the correct behavior but it was not running.
Consolidate two almost duplicated fn info extraction routines
Moves `extract_callable_info` up to trait selection, because it was being (almost) duplicated fully there for similar diagnostic purposes. This also generalizes the diagnostics we can give slightly (see UI test).
Suggestion for type mismatch when we need a u8 but the programmer wrote a char literal
Today Rust just points out that we have a char and we need a u8, but if I wrote 'A' then I could fix this by just writing b'A' instead. This code should detect the case where we're about to report a type mismatch of this kind, and the programmer wrote a char literal, and the char they wrote is ASCII, so therefore just prefixing b to make a byte literal will do what they meant.
I have definitely written this mistake more than once, it's not difficult to figure out what to do, but the compiler might as well tell us anyway.
I provided a test with two simple examples where the suggestion is appropriate, and one where it is not because the char literal is not ASCII, showing that the suggestion is only triggered in the former cases.
I have contributed only a small typo doc fix before, so this is my first substantive rustc change.
This class originated in the very first commit of `rustdoc_ng`, and was used
to add a color border around the item decl based on its kind.
4fd061c426/src/rustdoc_ng/html/static/main.css (L102-L106)
The item decl no longer has a border, and there aren't any
kind-specific styles in modern rustdoc's rendering of this UI item.
Most of this commit is updating test cases so that they use `item-decl` to
find the `<pre>` tag instead of relying on the fact that the class name
had `rust {kind}` in it while other `<pre>` tags only had class `rust`.
rustdoc: remove `docblock` class from notable trait popover
This commit builds on b72de9be74, which removes the `docblock` class from the All Items page, and 9457380ac9, which removes the `docblock` class from the item decl.
Fixes#92974
