| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #107553 (Suggest std::ptr::null if literal 0 is given to a raw pointer function argument)
- #107580 (Recover from lifetimes with default lifetimes in generic args)
- #107669 (rustdoc: combine duplicate rules in ayu CSS)
- #107685 (Suggest adding a return type for async functions)
- #107687 (Adapt SROA MIR opt for aggregated MIR)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Adapt SROA MIR opt for aggregated MIR
The pass was broken by https://github.com/rust-lang/rust/pull/107267.
This PR extends it to replace:
```
x = Struct { 0: a, 1: b }
y = move? x
```
by assignment between locals
```
x_0 = a
x_1 = b
y_0 = move? x_0
y_1 = move? x_1
```
The improved pass runs to fixpoint, so we can flatten nested field accesses.
|
|
Suggest adding a return type for async functions
Fixes #90027.
|
|
lenko-d:default_value_for_a_lifetime_generic_parameter_produces_confusing_diagnostic, r=compiler-errors
Recover from lifetimes with default lifetimes in generic args
Fixes [#107492](https://github.com/rust-lang/rust/issues/107492)
|
|
r=WaffleLapkin
Suggest std::ptr::null if literal 0 is given to a raw pointer function argument
Implementation feels a little sus (we're parsing the span for a `0`) but it seems to fall in line the string-expected-found-char condition right above this check, so I think it's fine.
Feedback appreciated on help text? I think it's consistent but it does sound a little awkward maybe?
Fixes #107517
|
|
Add explanatory message for [#must_use] in ops
Fixes #103320
|
|
|
|
r=GuillaumeGomez
rustdoc: compute maximum Levenshtein distance based on the query
Preview: https://notriddle.com/notriddle-rustdoc-demos/search-lev-distance-2023/std/index.html?search=regex
The heuristic is pretty close to the name resolver, maxLevDistance = `Math.floor(queryLen / 3)`.
Fixes #103357
Fixes #82131
Similar to https://github.com/rust-lang/rust/pull/103710, but following the suggestion in https://github.com/rust-lang/rust/pull/103710#issuecomment-1296360267 to use `floor` instead of `ceil`, and unblocked now that https://github.com/rust-lang/rust/pull/105796 made it so that setting the max lev distance to `0` doesn't cause substring matches to be removed.
|
|
Recover form missing expression in `for` loop
Close #78537
r? `@estebank`
|
|
don't point at nonexisting code beyond EOF when warning about delims
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing. This would cause the debug assertion ice to trigger. I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :( But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Fixes https://github.com/rust-lang/rust/issues/107423
r? `@compiler-errors`
|
|
|
|
rustdoc: change trait bound formatting
Fixes #85566
Before
<img width="268" alt="image" src="https://user-images.githubusercontent.com/29011024/208326689-cc9b4bae-529c-473c-81e2-fc5ddb738f07.png">
Now
<img width="268" alt="image" src="https://user-images.githubusercontent.com/29011024/216216918-d7923787-3e3b-486d-9735-4cecd2988dba.png">
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Provide structured suggestion for binding needing type on E0594
Partially address #45405.
|
|
rustdoc: fix item-spacer
rustdoc: use proper comment style
rustdoc: change formatting where clauses for traits
rustdoc: remove semicolon from provided methods
update provided methods formatting
|
|
Do not deaggregate MIR
This turns out to simplify a lot of things.
I haven't checked the consequences for miri yet.
cc `@JakobDegen`
r? `@oli-obk`
|
|
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing.
This would cause the debug assertion ice to trigger.
I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :(
But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Fixes https://github.com/rust-lang/rust/issues/107423
r? @compiler-errors
|
|
Replace nbsp in all rustdoc code blocks
Based on #106125 by `@dtolnay` — this PR fixes the line wrapping bug.
Fixes #106098. This makes code copyable from rustdoc rendered documentation into a Rust source file.
|
|
Replace `ConstFnMutClosure` with const closures
Also fixes a parser bug. cc `@oli-obk` for compiler changes
|
|
|
|
Partially address #45405.
|
|
Rollup of 6 pull requests
Successful merges:
- #107082 (Autotrait bounds on dyn-safe trait methods)
- #107427 (Add candidates for DiscriminantKind builtin)
- #107539 (Emit warnings on unused parens in index expressions)
- #107544 (Improve `TokenCursor`.)
- #107585 (Don't cause a cycle when formatting query description that references a FnDef)
- #107633 (Fix suggestion for coercing Option<&String> to Option<&str>)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix suggestion for coercing Option<&String> to Option<&str>
Fixes #107604
This also makes the diagnostic `MachineApplicable`, and runs `rustfix` to check we're not producing incorrect code.
``@rustbot`` label +A-diagnostics
|
|
Don't cause a cycle when formatting query description that references a FnDef
When a function returns `-> _`, we use typeck to compute what the resulting type of the body _should_ be. If we call another query inside of typeck and hit a cycle error, we attempt to report the cycle error which requires us to compute all of the query descriptions for the stack.
However, if one of the queries in that cycle has a query description that references this function as a FnDef type, we'll cause a *second* cycle error from within the cycle error reporting code, since rendering a FnDef requires us to compute its signature. This causes an unwrap to ICE, since during the *second* cycle reporting code, we try to look for a job that isn't in the active jobs list.
We can avoid this by using `with_no_queries!` when computing these query descriptions.
Fixes #107089
The only drawback is that the rendering of opaque types in cycles regresses a bit :| I'm open to alternate suggestions about how we may handle this...
|
|
Emit warnings on unused parens in index expressions
Fixes: #96606.
I am not sure what the best term for "index expression" is. Is there a better term we could use?
|
|
|
|
|
|
|
|
Co-Authored-By: David Tolnay <dtolnay@gmail.com>
|
|
Don't generate unecessary `&&self.field` in deriving Debug
Since unsized fields may only be the last one in a struct, we only need to generate a double reference (`&&self.field`) for the final one.
cc `@nnethercote`
|
|
|
|
Parse and recover from type ascription in patterns
Reintroduce part of #106960, which was reverted in #107478.
r? `@compiler-errors`
|
|
r=compiler-errors
Add tests to assert current behavior of large future sizes
Based on a couple of sources:
- https://swatinem.de/blog/future-size/
- https://github.com/rust-lang/rust/issues/62958
|
|
Suggest `{var:?}` when finding `{?:var}` in inline format strings
Link to issue: https://github.com/rust-lang/rust/issues/106572
This is my first PR to this project, so hopefully I can get some good pointers with me from the first PR.
Currently my idea was to test out whether or not this is the correct solution to this issue and then hopefully expand upon the idea to not only work for Debug formatting but for all of them. If this is a valid solution, I will create a new issue to give a better error message to a broader range of wrong-order formatting.
|
|
Suggest `move` in nested closure when appropriate
Fix #64008.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=notriddle,petrochenkov
Fix handling of items inside a `doc(hidden)` block
Fixes #106373.
cc `@aDotInTheVoid`
r? `@notriddle`
|
