| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Adds --remap-path-prefix as an unstable option. This is implemented to
mimic the behavior of rustc's --remap-path-prefix but with minor
adjustments.
This flag similarly takes in two paths, a prefix to replace and a
replacement string.
|
|
Silence follow-up errors directly based on error types and regions
During type_of, we used to just return an error type if there were any errors encountered. This is problematic, because it means a struct declared as `struct Foo<'static>` will end up not finding any inherent or trait impls because those impl blocks' `Self` type will be `{type error}` instead of `Foo<'re_error>`. Now it's the latter, silencing nonsensical follow-up errors about `Foo` not having any methods.
Unfortunately that now allows for new follow-up errors, because borrowck treats `'re_error` as `'static`, causing nonsensical errors about non-error lifetimes not outliving `'static`. So what I also did was to just strip all outlives bounds that borrowck found, thus never letting it check them. There are probably more nuanced ways to do this, but I worried there would be other nonsensical errors if some outlives bounds were missing. Also from the test changes, it looked like an improvement everywhere.
|
|
r=GuillaumeGomez
rustdoc: add a regression test for a former blanket impl synthesis ICE
Fixes #119792 (also passes in #125907 in case you were wondering).
r? rustdoc
|
|
|
|
GuillaumeGomez:stabilize-custom_code_classes_in_docs, r=rustdoc
Stabilize `custom_code_classes_in_docs` feature
Fixes #79483.
This feature has been around for quite some time now, I think it's fine to stabilize it now.
## Summary
## What is the feature about?
In short, this PR changes two things, both related to codeblocks in doc comments in Rust documentation:
* Allow to disable generation of `language-*` CSS classes with the `custom` attribute.
* Add your own CSS classes to a code block so that you can use other tools to highlight them.
#### The `custom` attribute
Let's start with the new `custom` attribute: it will disable the generation of the `language-*` CSS class on the generated HTML code block. For example:
```rust
/// ```custom,c
/// int main(void) {
/// return 0;
/// }
/// ```
```
The generated HTML code block will not have `class="language-c"` because the `custom` attribute has been set. The `custom` attribute becomes especially useful with the other thing added by this feature: adding your own CSS classes.
#### Adding your own CSS classes
The second part of this feature is to allow users to add CSS classes themselves so that they can then add a JS library which will do it (like `highlight.js` or `prism.js`), allowing to support highlighting for other languages than Rust without increasing burden on rustdoc. To disable the automatic `language-*` CSS class generation, you need to use the `custom` attribute as well.
This allow users to write the following:
```rust
/// Some code block with `{class=language-c}` as the language string.
///
/// ```custom,{class=language-c}
/// int main(void) {
/// return 0;
/// }
/// ```
fn main() {}
```
This will notably produce the following HTML:
```html
<pre class="language-c">
int main(void) {
return 0;
}</pre>
```
Instead of:
```html
<pre class="rust rust-example-rendered">
<span class="ident">int</span> <span class="ident">main</span>(<span class="ident">void</span>) {
<span class="kw">return</span> <span class="number">0</span>;
}
</pre>
```
To be noted, we could have written `{.language-c}` to achieve the same result. `.` and `class=` have the same effect.
One last syntax point: content between parens (`(like this)`) is now considered as comment and is not taken into account at all.
In addition to this, I added an `unknown` field into `LangString` (the parsed code block "attribute") because of cases like this:
```rust
/// ```custom,class:language-c
/// main;
/// ```
pub fn foo() {}
```
Without this `unknown` field, it would generate in the DOM: `<pre class="language-class:language-c language-c">`, which is quite bad. So instead, it now stores all unknown tags into the `unknown` field and use the first one as "language". So in this case, since there is no unknown tag, it'll simply generate `<pre class="language-c">`. I added tests to cover this.
EDIT(camelid): This description is out-of-date. Using `custom,class:language-c` will generate the output `<pre class="language-class:language-c">` as would be expected; it treats `class:language-c` as just the name of a language (similar to the langstring `c` or `js` or what have you) since it does not use the designed class syntax.
Finally, I added a parser for the codeblock attributes to make it much easier to maintain. It'll be pretty easy to extend.
As to why this syntax for adding attributes was picked: it's [Pandoc's syntax](https://pandoc.org/MANUAL.html#extension-fenced_code_attributes). Even if it seems clunkier in some cases, it's extensible, and most third-party Markdown renderers are smart enough to ignore Pandoc's brace-delimited attributes (from [this comment](https://github.com/rust-lang/rust/pull/110800#issuecomment-1522044456)).
r? `@notriddle`
|
|
r=compiler-errors
Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup
Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.
Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.
---
Old terminology (HIR, rustdoc):
```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
├── `Ty`: (associated) type binding
└── `Const`: associated const equality (constraint)
```
Old terminology (AST, abbrev.):
```
`AssocConstraint`
├── `Bound`
└── `Equality`
├── `Ty`
└── `Const`
```
New terminology (AST, HIR, rustdoc):
```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
├── `Ty`: associated type equality constraint OR associated type binding (for short)
└── `Const`: associated const equality constraint OR associated const binding (for short)
```
r? compiler-errors
|
|
|
|
|
|
- Remove wrong exception text for non-local macro_rules!
- Simplify anonymous const exception note
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Suggest using type args directly instead of equality constraint
When type arguments are written erroneously using an equality constraint we suggest specifying them directly without the equality constraint.
Fixes #122162
Changes the diagnostic in the issue from:
```rust
error[E0229]: associated type bindings are not allowed here
9 | impl std::cmp::PartialEq<Rhs = T> for S {
| ^^^^^^^ associated type not allowed here
|
```
to
```rust
error[E0229]: associated type bindings are not allowed here
9 | impl std::cmp::PartialEq<Rhs = T> for S {
| ^^^^^^^ associated type not allowed here
|
help: to use `T` as a generic argument specify it directly
|
| impl std::cmp::PartialEq<T> for S {
| ~
```
|
|
Stabilize checking of cfgs at compile-time: `--check-cfg` option
This PR stabilize the `--check-cfg` CLI option of `rustc` (and `rustdoc`) :tada:.
In particular this PR does two things:
1. it makes the `--check-cfg` option stable
2. and it moves the documentation to the stable books
FCP: https://github.com/rust-lang/rust/issues/82450#issuecomment-1965328542
Resolves #82450
``@rustbot`` labels +S-blocked +F-check-cfg
r? ``@petrochenkov``
|
|
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 6)
Follow up
* https://github.com/rust-lang/rust/pull/116214
* https://github.com/rust-lang/rust/pull/116432
* https://github.com/rust-lang/rust/pull/116824
* https://github.com/rust-lang/rust/pull/118105
* https://github.com/rust-lang/rust/pull/119561
|
|
|
|
|
|
|
|
|
|
Fixes a regression caused by 0a50dba50bedd24377bd1066da3b4b7066df4d28
|
|
rustdoc: point at span in `include_str!`-ed md file
Fixes #118549
|
|
|
|
rustdoc: synthetic auto trait impls: accept unresolved region vars for now
https://github.com/rust-lang/rust/pull/123348#issuecomment-2032494255:
> Right, [in #123340] I've intentionally changed a `vid_map.get(vid).unwrap_or(r)` to a `vid_map[vid]` making rustdoc panic if `rustc::AutoTraitFinder` returns a region inference variable that cannot be resolved because that is really fishy. I can change it back with a `FIXME: investigate` […]. [O]nce I [fully] understand [the arcane] `rustc::AutoTraitFinder` [I] can fix the underlying issue if there's one.
>
> `rustc::AutoTraitFinder` can also return placeholder regions `RePlaceholder` which doesn't seem right either and which makes rustdoc ICE, too (we have a GitHub issue for that already[, namely #120606]).
Fixes #123370.
Fixes #112242.
r? ``@GuillaumeGomez``
|
|
|
|
|
|
|
|
|
|
|
|
When displaying multispans, ignore empty lines adjacent to `...`
```
error[E0308]: `match` arms have incompatible types
--> tests/ui/codemap_tests/huge_multispan_highlight.rs:98:18
|
6 | let _ = match true {
| ---------- `match` arms have incompatible types
7 | true => (
| _________________-
8 | | // last line shown in multispan header
... |
96 | |
97 | | ),
| |_________- this is found to be of type `()`
98 | false => "
| __________________^
... |
119 | |
120 | | ",
| |_________^ expected `()`, found `&str`
error[E0308]: `match` arms have incompatible types
--> tests/ui/codemap_tests/huge_multispan_highlight.rs:215:18
|
122 | let _ = match true {
| ---------- `match` arms have incompatible types
123 | true => (
| _________________-
124 | |
125 | | 1 // last line shown in multispan header
... |
213 | |
214 | | ),
| |_________- this is found to be of type `{integer}`
215 | false => "
| __________________^
216 | |
217 | |
218 | | 1 last line shown in multispan
... |
237 | |
238 | | ",
| |_________^ expected integer, found `&str`
```
|
|
```
error[E0308]: `match` arms have incompatible types
--> tests/ui/codemap_tests/huge_multispan_highlight.rs:98:18
|
6 | let _ = match true {
| ---------- `match` arms have incompatible types
7 | true => (
| _________________-
8 | | // last line shown in multispan header
... |
96 | |
97 | | ),
| |_________- this is found to be of type `()`
98 | false => "
| __________________^
... |
119 | |
120 | | ",
| |_________^ expected `()`, found `&str`
error[E0308]: `match` arms have incompatible types
--> tests/ui/codemap_tests/huge_multispan_highlight.rs:215:18
|
122 | let _ = match true {
| ---------- `match` arms have incompatible types
123 | true => (
| _________________-
124 | |
125 | | 1 // last line shown in multispan header
... |
213 | |
214 | | ),
| |_________- this is found to be of type `{integer}`
215 | false => "
| __________________^
216 | |
217 | |
218 | | 1 last line shown in multispan
... |
237 | |
238 | | ",
| |_________^ expected integer, found `&str`
```
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #121025 (add known-bug tests for derive failure to detect packed repr)
- #121194 (Refactor pre-getopts command line argument handling)
- #121563 (Use `ControlFlow` in visitors.)
- #122173 (Don't ICE in CTFE if raw/fn-ptr types differ)
- #122175 (Bless tidy issues order)
- #122179 (rustc: Fix typo)
- #122181 (Fix crash in internal late lint checking)
- #122183 (interpret: update comment about read_discriminant on uninhabited variants)
Failed merges:
- #122076 (Tweak the way we protect in-place function arguments in interpreters)
- #122132 (Diagnostic renaming 3)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Refactor pre-getopts command line argument handling
Rebased version of #111658. I've also fixed the Windows CI failure (although I don't have access to Windows to test it myself).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #119592 (resolve: Unload speculatively resolved crates before freezing cstore)
- #120103 (Make it so that async-fn-in-trait is compatible with a concrete future in implementation)
- #120206 (hir: Make sure all `HirId`s have corresponding HIR `Node`s)
- #120214 (match lowering: consistently lower bindings deepest-first)
- #120688 (GVN: also turn moves into copies with projections)
- #120702 (docs: also check the inline stmt during redundant link check)
- #120727 (exhaustiveness: Prefer "`0..MAX` not covered" to "`_` not covered")
- #120734 (Add `SubdiagnosticMessageOp` as a trait alias.)
- #120739 (improve pretty printing for associated items in trait objects)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
expression
|
|
|
|
make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern
These arms would never be hit anyway, so the pattern makes little sense. We have had a future-compat lint against float matches in general for a *long* time, so I hope we can get away with immediately making this a hard error.
This is part of implementing https://github.com/rust-lang/rfcs/pull/3535.
Closes https://github.com/rust-lang/rust/issues/41620 by removing the lint.
https://github.com/rust-lang/reference/pull/1456 updates the reference to match.
|
