| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Currently fails.
---- [pretty] src/test/pretty/where-clauses.rs stdout ----
error: pretty-printed source does not match expected source
expected:
------------------------------------------
// pp-exact
fn f<'a, 'b, T>(t: T) -> isize where T: 'a, 'a: 'b, T: Eq { 0 }
// This is legal syntax, sometimes generated by macros. `where T: $($bound+)*`
fn zero_bounds<'a, T>() where 'a:, T: {}
fn main() {}
------------------------------------------
actual:
------------------------------------------
// pp-exact
fn f<'a, 'b, T>(t: T) -> isize where T: 'a, 'a: 'b, T: Eq { 0 }
// This is legal syntax, sometimes generated by macros. `where T: $($bound+)*`
fn zero_bounds<'a, T>() where 'a, T {}
fn main() {}
------------------------------------------
diff:
------------------------------------------
3 fn f<'a, 'b, T>(t: T) -> isize where T: 'a, 'a: 'b, T: Eq { 0 }
4
5 // This is legal syntax, sometimes generated by macros. `where T: $($bound+)*`
- fn zero_bounds<'a, T>() where 'a:, T: {}
+ fn zero_bounds<'a, T>() where 'a, T {}
7
8 fn main() {}
9
|
|
Add `do yeet` expressions to allow experimentation in nightly
Two main goals for this:
- Ensure that trait restructuring in https://github.com/rust-lang/rust/issues/84277#issuecomment-1066120333 doesn't accidentally close us off from the possibility of doing this in future, as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet
- Experiment with the *existence* of syntax for this, to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization, but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another.
r? `@oli-obk`
The lang `second` for doing this: https://github.com/rust-lang/lang-team/issues/160#issuecomment-1107896716
Tracking issues
- Lang, https://github.com/rust-lang/rust/issues/96373
- Libs-api, https://github.com/rust-lang/rust/issues/96374
|
|
Using an obviously-placeholder syntax. An RFC would still be needed before this could have any chance at stabilization, and it might be removed at any point.
But I'd really like to have it in nightly at least to ensure it works well with try_trait_v2, especially as we refactor the traits.
|
|
|
|
|
|
Parse inner attributes on inline const block
According to https://github.com/rust-lang/rust/pull/84414#issuecomment-826150936, inner attributes are intended to be supported *"in all containers for statements (or some subset of statements)"*.
This PR adds inner attribute parsing and pretty-printing for inline const blocks (https://github.com/rust-lang/rust/issues/76001), which contain statements just like an unsafe block or a loop body.
```rust
let _ = const {
#![allow(...)]
let x = ();
x
};
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
They are also removed from the prelude as per the decision in
https://github.com/rust-lang/rust/issues/87228.
stdarch and compiler-builtins are updated to work with the new, stable
asm! and global_asm! macros.
|
|
|
|
Currently fails with:
---- [pretty] pretty/async.rs stdout ----
error: pretty-printed source does not match expected source
expected:
------------------------------------------
// pp-exact
// pretty-compare-only
// edition:2021
async fn f() {
let first = async { 1 };
let second = async move { 2 };
join(first, second).await
}
------------------------------------------
actual:
------------------------------------------
// pp-exact
// pretty-compare-only
// edition:2021
async fn f() {
let first = async { 1 };
let second = async move { 2 };
join(first, second).await
}
------------------------------------------
diff:
------------------------------------------
3 // edition:2021
4
5 async fn f() {
- let first = async { 1 };
- let second = async move { 2 };
+ let first = async { 1 };
+ let second = async move { 2 };
8 join(first, second).await
9 }
10
|
|
|
|
|
|
This allows the format_args! macro to keep the pre-expansion code out of
the unsafe block without doing gymnastics with nested `match`
expressions. This reduces codegen.
|
|
This reverts commit d59b1f1ef4be692b67c1ff1b49ec810fd59452cf.
|
|
|
|
Remove unstable `--pretty` flag
It doesn't do anything `--unpretty` doesn't, and due to a bug, also
didn't show up in `--help`. I don't think there's any reason to keep it
around, I haven't seen anyone using it.
Closes https://github.com/rust-lang/rust/issues/36473.
|
|
For example, this code:
$arg:expr
used to be pretty-printed as:
$ arg : expr
but is now pretty-printed as:
$arg : expr
|
|
fix pretty print for `loop`
|
|
Use HTTPS links where possible
While looking at #86583, I wondered how many other (insecure) HTTP links were in `rustc`. This changes most other `http` links to `https`. While most of the links are in comments or documentation, there are a few other HTTP links that are used by CI that are changed to HTTPS.
Notes:
- I didn't change any to or in licences
- Some links don't support HTTPS :(
- Some `http` links were dead, in those cases I upgraded them to their new places (all of which used HTTPS)
|
|
|
|
|
|
r=nikomatsakis
Re-add support for parsing (and pretty-printing) inner-attributes in match body
Re-add support for parsing (and pretty-printing) inner-attributes within body of a `match`.
In other words, we can do `match EXPR { #![inner_attr] ARM_1 ARM_2 ... }` again.
I believe this unbreaks the only four crates that crater flagged as broken by PR #83312.
(I am putting this up so that the lang-team can check it out and decide whether it changes their mind about what to do regarding PR #83312.)
|
|
|
|
In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.
|
|
|
|
|
|
|
|
It doesn't do anything `--unpretty` doesn't, and due to a bug, also
didn't show up in `--help`. I don't think there's any reason to keep it
around, I haven't seen anyone using it.
|
|
|
|
|
|
|
|
|
|
They were originally called "opt-in, built-in traits" (OIBITs), but
people realized that the name was too confusing and a mouthful, and so
they were renamed to just "auto traits". The feature flag's name wasn't
updated, though, so that's what this PR does.
There are some other spots in the compiler that still refer to OIBITs,
but I don't think changing those now is worth it since they are internal
and not particularly relevant to this PR.
Also see <https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/opt-in.2C.20built-in.20traits.20(auto.20traits).20feature.20name>.
|
|
|
|
If a symbol name can only be imported from one place for a type, and
as long as it was not glob-imported anywhere in the current crate, we
can trim its printed path and print only the name.
This has wide implications on error messages with types, for example,
shortening `std::vec::Vec` to just `Vec`, as long as there is no other
`Vec` importable anywhere.
This adds a new '-Z trim-diagnostic-paths=false' option to control this
feature.
On the good path, with no diagnosis printed, we should try to avoid
issuing this query, so we need to prevent trimmed_def_paths query on
several cases.
This change also relies on a previous commit that differentiates
between `Debug` and `Display` on various rustc types, where the latter
is trimmed and presented to the user and the former is not.
|
|
This commit adds a regression test for #74745. While a
`ignore-tidy-trailing-lines` header is required, this doesn't stop the
test from reproducing, so long as there is no newline at the end of the
file.
However, adding the header comments made the test fail due to a bug in
pprust, fixed in the previous commit.
Signed-off-by: David Wood <david@davidtw.co>
|
|
This commit adjusts the pretty printing of mixed comments so that the
initial zero-break isn't emitted at the beginning of the line. Through
this, the `block-comment-wchar` test can have the `pp-exact` file
removed, as it no longer converges from pretty printing of the source.
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
