Fix codeblocks overflow
Fixes#87043.
Instead of completely relying on `pulldown-cmark` (and its potential changes), I decided to move the generation of codeblocks HTML directly in rustdoc so we can unify the DOM and the CSS classes.
r? `@Nemo157`
expand: Support helper attributes for built-in derive macros
This is needed for https://github.com/rust-lang/rust/pull/86735 (derive macro `Default` should have a helper attribute `default`).
With this PR we can specify helper attributes for built-in derives using syntax `#[rustc_builtin_macro(MacroName, attributes(attr1, attr2, ...))]` which mirrors equivalent syntax for proc macros `#[proc_macro_derive(MacroName, attributes(attr1, attr2, ...))]`.
Otherwise expansion infra was already ready for this.
The attribute parsing code is shared between proc macro derives and built-in macros (`fn parse_macro_name_and_helper_attrs`).
This resolves all the problems we had around "normalizing" the representation of a Scalar in case it carries a Pointer value: we can just use Pointer if we want to have a value taht we are sure is already normalized.
Handle non-integer const generic parameters in debuginfo type names.
This PR fixes an ICE introduced by https://github.com/rust-lang/rust/pull/85269 which started emitting const generic arguments for debuginfo names but did not cover the case where such an argument could not be evaluated to a flat string of bits.
The fix implemented in this PR is very basic: If `try_eval_bits()` fails for the constant in question, we fall back to generating a stable hash of the constant and emit that instead. This way we get a (virtually) unique name and side step the problem of generating a string representation of a potentially complex value.
The downside is that the generated name will be rather opaque. E.g. the regression test adds a function `const_generic_fn_non_int<()>` which is then rendered as `const_generic_fn_non_int<{CONST#fe3cfa0214ac55c7}>`. I think it's an open question how to deal with this more gracefully.
I'd be interested in ideas on how to do this better.
r? `@wesleywiser`
cc `@dpaoliello` (do you see any problems with this approach?)
cc `@Mark-Simulacrum` & `@nagisa` (who I've seen comment on debuginfo issues recently -- anyone else?)
Fixes https://github.com/rust-lang/rust/issues/86893
Rollup of 6 pull requests
Successful merges:
- #87085 (Search result colors)
- #87090 (Make BTreeSet::split_off name elements like other set methods do)
- #87098 (Unignore some pretty printing tests)
- #87099 (Upgrade `cc` crate to 1.0.69)
- #87101 (Suggest a path separator if a stray colon is found in a match arm)
- #87102 (Add GUI test for "go to first" feature)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
When building with profile-generate request that metadata is kept
during the gc_sections call, as this can sometimes strip out profile
data.
This missing information in the prof files can then result in missing
functions when using the profile information.
fix 5707
changelog: ``[`redundant_clone`]``, fix#5707
# Root problem of #5707 :
```
&2:&mut HashMap = &mut _4;
&3:&str = & _5;
_1 = HashMap::insert(move _2,move _3, _);
```
generate PossibleBorrower(_2,_1) and PossibleBorrower(_3,_1).
However, it misses PossibleBorrower(_3,_2).
# My solution to #5707 :
When meet a function call, we should:
1. build PossibleBorrower between borrow parameters and return value (currently)
2. build PossibleBorrower between immutable borrow parameters and mutable borrow parameters (*add*)
3. build PossibleBorrower inside mutable borrow parameters (*add*)
For example:
```
_2: &mut _22;
_3: &mut _;
_4: & _;
_5: & _;
_1 = call(move _2, move _3, move _4, move _5);
```
we need to build
1. return value with parameter(current implementataion)
PossibleBorrower(_2,_1)
PossibleBorrower(_3,_1)
PossibleBorrower(_4,_1)
PossibleBorrower(_5,_1)
2. between mutable borrow and immutable borrow
PossibleBorrower(_4,_2)
PossibleBorrower(_5,_2)
PossibleBorrower(_4,_3)
PossibleBorrower(_5,_3)
3. between mutable borrow and mutable borrow
PossibleBorrower(_3,_2)
PossibleBorrower(_2,_3)
But that's not enough.
Modification to _2 actually apply to _22.
So I write a `PossibleBorrowed` visitor, which tracks (borrower => possible borrowed) relation.
For example (_2 => _22).
However, a lot of problems exist here.
## Known Problems:
1. not sure all `&mut`'s origin are collected.
I'm not sure how to deal with `&mut` when meet a function call, so I didn't do it currently.
Also, my implement is not flow sensitive, so it's not accurate.
```
foo(_2:&mut _, _3: &_)
```
This pr doesn't count _3 as origin of _2.
2. introduce false negative
`foo(_2, _3)` will emit PossibleBorrower(_3,_2) in this pr, but _3 and _2 may not have relation.
Clippy may feel that _3 is still in use because of _2, but actually, _3 is on longer needed and can be moved.
## Insight
The key problem is determine where every `&mut` come from accurately.
I think Polonius is an elegant solution to it. Polonius is flow sensitive and accurate.
But I'm uncertain about whether we can import Polonius in rust-clippy currently.
This pr actually is part of Polonius' functionality, I think.
# TODO
1. `cargo test` can't pass yet due to similar variable name
create method overview docs for core::option and core::result
The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include "truth tables" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source, but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks, for example.
This is based on #86209, but those are small changes and unlikely to conflict.
Avoid cloning ExpnData to access Span edition
ExpnData is a fairly hefty structure to clone; cloning it may not be cheap. In
some cases this may get optimized out, but it's not clear that will always be
the case. Try to avoid that cost.
r? `@ghost` -- opening for a perf run to start with
Add GUI test for "go to first" feature
It adds a test for #85876 to ensure the feature is working as expected and prevent potential regression.
cc ```@jeanlucthumm```
r? ```@Manishearth```
Search result colors
Part of #87072 (fixes the first and fourth regressions and add tests to prevent it from happening again).
cc ````@Nemo157````
r? ````@camelid````
