Initial implementation of dyn*
This PR adds extremely basic and incomplete support for [dyn*](https://smallcultfollowing.com/babysteps//blog/2022/03/29/dyn-can-we-make-dyn-sized/). The goal is to get something in tree behind a flag to make collaboration easier, and also to make sure the implementation so far is not unreasonable. This PR does quite a few things:
* Introduce `dyn_star` feature flag
* Adds parsing for `dyn* Trait` types
* Defines `dyn* Trait` as a sized type
* Adds support for explicit casts, like `42usize as dyn* Debug`
* Including const evaluation of such casts
* Adds codegen for drop glue so things are cleaned up properly when a `dyn* Trait` object goes out of scope
* Adds codegen for method calls, at least for methods that take `&self`
Quite a bit is still missing, but this gives us a starting point. Note that this is never intended to become stable surface syntax for Rust, but rather `dyn*` is planned to be used as an implementation detail for async functions in dyn traits.
Joint work with `@nikomatsakis` and `@compiler-errors.`
r? `@bjorn3`
This commit allows it to stop manually specifying pixel heights for the tabs
on search result pages. There's less messing with manual breakpoints and
less complex CSS selectors.
Migrate write.rs to a late pass
changelog: Migrates write.rs from a pre expansion pass to a late pass
changelog: [`positional_named_format_parameters`] is renamed in favour of the rustc lint `named_arguments_used_positionally`
- Macros are now identified by diagnostic items, so will no longer lint user defined macros named, e.g. a custom `print!`
- `print_literal`/`write_literal` no longer lint no longer lint literals that come from macro expansions, e.g. `env!("FOO")`
- `print_with_newline`/`write_with_newline` no longer lint strings with any internal `\r` or `\n`s
~~A false negative, `print_literal`/`write_literal` don't lint format strings that produce `FormatSpec`s, e.g. ones containing pretty print/width/align specifiers~~
Suggestion changes:
- ~~`print_literal`/`write_literal` no longer have suggestions, as the spans for the `{}`s were not easily obtainable~~
- `print_with_newline`/`write_with_newline` has a better suggestion for a sole literal newline, but no longer has suggestions for len > 1 strings that end in a literal newline
- ~~`use_debug` spans are less precise, now point to the whole format string~~
The diff for write.rs is pretty unwieldy, other than for the `declare_clippy_lint!`s I think you'd be better off viewing it as a brand new file rather than looking at the diff, as it's mostly written from scratch
cc #6610, fixes#5721, fixes#7195, fixes#8615
Fix `unused_peekable` closure and `f(&mut peekable)` false positives
changelog: Fix [`unused_peekable`] false positive when peeked in a closure or called as `f(&mut peekable)`
The `return`/`break` changes aren't part of the fix, they allow an earlier return in some cases. `break` is replaced with `return` for style purposes as they do the same thing in this case
Fixes#9456Fixes#9462
Update test output for drop tracking
#97334 has a lot of updates to test outputs that makes the PR larger than it needs to be. This PR pulls those changes out so we can keep the other one as simple as possible.
r? `@jyn514`
rustdoc: remove outdated CSS `.content table` etc
# Screenshot before
# Screenshot after
# Description
The `.content table` / `.content td` / `.content tr` family of selectors date back to 4fd061c426902b0904c65e64a3780b21f9ab3afb, when module indexes and other parts of rustdoc used `<table>` tags for layout and content presentation. The `.content td h1, .content td h2` has only been changed since then to tweak the font size in dd5ff428edbc7cd4fa600b81f27bbec28589704f.
4fd061c426/src/rustdoc_ng/html/static/main.css (L155-L162)
This CSS would have affected:
* search result tables, which were removed in b615c0c85469c94041a5e68b9d8b68dcf799f9f1
* module item tables, which were removed in 6020c79ddeafe8d9760b27c14c39da81bac9b4a6
* docblock tables from markdown, which still exist
It may also have affected a few other tables over the last decade, but they've been gradually replaced with grid layouts and flexbox to make layouts that work better on narrow viewports. For example, 34bd2b845b3acd84c5a9bddae3ff8081c19ec5e9.
These rules have no affect on the appearance of docblock tables
---------------------------------------------------------------
.content table {
border-spacing: 0 5px;
}
According to MDN, [border-spacing] only has an effect when `border-collapse` is `separate`. However, `border-collapse: collapse` is set globally for all tables, so this rule does nothing.
[border-spacing]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-spacing
.content td p:first-child { margin-top: 0; }
Tables with paragraphs in them are impossible without dropping down to raw HTML. Also, the rustdoc stylesheet sets paragraphs to have no top margin anyway, so this rule is a no-op.
.content td h1, .content td h2 { margin-left: 0; font-size: 1.125rem; }
Tables with headers in them are impossible without dropping down to raw HTML. This is considered unlikely, especially since it looks weird right now (`.docblock h2` has an underline that is redundant with the table cell's own border).
.content tr:first-child td { border-top: 0; }
This has no effect because of border collapsing.
This rule is removed, because tables look fine without it
---------------------------------------------------------
.content td:first-child { padding-right: 20px; }
By removing this rule, the first cell in each row has the same padding as all other cells in the row.
This rule is kept, and converted to directly target `.docblock`
---------------------------------------------------------------
.content td { vertical-align: top; }
Removing this rule would cause it to be aligned to the middle instead.
rustdoc: remove redundant CSS `.out-of-band > span.since { position }`
At the time this CSS was added, it was just `span.since`, because the version info could be rendered in two different ways:
1. `<div class='since'>` was used for associated items like methods. It was absolutely positioned, and the selector in rustdoc.css that targetted it was just `.since`.
a5a2f2b951/src/librustdoc/html/static/rustdoc.css (L522-L529)
2. `<span class='since'>` was introduced in a5a2f2b951ea982a666eaf52b1874d8f1b17290b for page-global version info, so that it could be laid out alongside the `[-]`/`[+]` button. This CSS rule was added to override the absolute position introduced in (1).
a5a2f2b951/src/librustdoc/html/static/rustdoc.css (L637-L641)
The selector was changed in 8fc6e420d16dc882f2047e6ec1b981cac5ef0d14 so that everything could use a `<span>` tag, but the dichotomy of the absolutely-positioned version info for associated items and the static positioned item version info remained.
The absolutely positioned `.since` was changed to one nested below a `<div class="rightside">` container in 5de1391b88007a1d4f7b1517657a86aae352af1e, so the version information is now always statically-positioned, and, as described in the commit message, "their DOM representation is consistent."
Emit a note that static bounds from HRTBs are a bug
This note isn't perfect, but opening this to either 1) land as is or 2) get some feedback on how to improve it
Let r? `@compiler-errors` and cc. `@nikomatsakis`
