Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve print_tts #114571

Merged
merged 3 commits into from
Dec 11, 2023
Merged

Improve print_tts #114571

merged 3 commits into from
Dec 11, 2023

Conversation

nnethercote
Copy link
Contributor

By slightly changing the meaning of tokenstream::Spacing we can greatly improve the output of print_tts.

r? @ghost

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 7, 2023
@nnethercote nnethercote marked this pull request as draft August 7, 2023 05:58
@rust-log-analyzer

This comment has been minimized.

@nnethercote
Copy link
Contributor Author

@petrochenkov: you suggested to me the idea of using jointness during pretty-printing, this is a draft attempt.

  • It works really well. The output is much improved, and there's scope for further improvements.
  • Does this code look like what you intended?
  • Where does print_tt's output show up in practice? I see it in the output of stringify!, is there anywhere else?
  • Could changes to the output break real-world code? The docs for stringify! explicitly state that the output might change, so I'm not too worried by that, but maybe there are other places it could affect.
  • At the last minute I discovered that, as written, this would re-introduce Breaking behavior change for TokenStream containing trailing joint token #76399 (cc @matklad). As mentioned in a comment in the code, I think I can fix this by making additional changes to tokenstream::Spacing.
  • There is more work to be done:
    • As mentioned in the comments, I could add Spacing fields to TokenTree::Delimited, which currently lacks them.
    • I haven't gone through all the code constructed internally with token_alone and token_joint, but there might be some room for improvement.
    • I think tokenstream::Spacing should probably be renamed. It's bad that it means something slightly different to proc_macro::Spacing. Especially if it becomes a 3-value or 4-value enum to work around Breaking behavior change for TokenStream containing trailing joint token #76399.
    • tt_prepend_space is still needed for code generated by proc macros. I think it could be improved some more. Alternatively, it could be removed and its logic moved into to_internal.

@petrochenkov petrochenkov self-assigned this Aug 7, 2023
@nnethercote
Copy link
Contributor Author

I am working on a fix for the #76399 issue. It's going well and I will put it up soon. In the meantime, don't look at the old code.

@nnethercote
Copy link
Contributor Author

nnethercote commented Aug 8, 2023

New code is up and ready for review.

  • Does this code look like what you intended?
  • Where does print_tt's output show up in practice? I see it in the output of stringify!, is there anywhere else?
  • Could changes to the output break real-world code? The docs for stringify! explicitly state that the output might change, so I'm not too worried by that, but maybe there are other places it could affect.

These questions are still relevant.

I have fixed this.

  • I haven't gone through all the code constructed internally with token_alone and token_joint, but there might be some room for improvement.

I have done this now, in the final commit.

I have done this too. The new type is called FollowedBy.

@nnethercote nnethercote marked this pull request as ready for review August 8, 2023 05:06
@petrochenkov
Copy link
Contributor

I posted a doc update for stable public-facing Spacing in #114617.

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 8, 2023

I don't think FollowedBy is a right model for this.

The "jointness" is an inherent property attached to a single token (tree) rather than to a sequence of token trees.
Token streams can be arbitrarily modified by users and with the new scheme the real stream can go out of sync with FollowedBy values even more easily than with the previous Spacing.

I think the matklad's scheme in #76285 was fine - when parsing a token stream we just need to track whether a token is immediately followed by something or not, and then "censor" that information at proc macro boundary to match the public facing behavior documented in #114617.

I'd ideally first land a version of #76285 first, without any pretty-printing changes or renamings, but with regressions fixed.
Not sure how exactly the regression was fixed in this PR, but I assume it doesn't strictly require introducing a third variant?

@petrochenkov
Copy link
Contributor

As for pretty-printing streams from proc macros, I think we can extend the internal spacing to enum Spacing { Joing, Alone, Unspecified } where Unspecified comes from non-Punct tokens created by proc macros.
In the Unspecified case pretty-printing can fall back to heuristics.

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 8, 2023
@nnethercote
Copy link
Contributor Author

You haven't answered the following questions yet.

  • Where does print_tt's output show up in practice? I see it in the output of stringify!, is there anywhere else?
  • Could changes to the output break real-world code? The docs for stringify! explicitly state that the output might change, so I'm not too worried by that, but maybe there are other places it could affect.

It would be helpful if you did.

I don't think FollowedBy is a right model for this.

What is the right model? You've made two suggestions:

  • Reinstate Move jointness censoring to proc_macro #76285, which was just a refactoring that didn't affect pretty-printing at all.
  • Add Spacing::Unspecified, which might help pretty-printing of proc macro code slightly, but would have no effect on pretty-printing of parsed code.

This is a PR mostly about pretty-printing of parsed code, but your suggestions don't relate to that.

The "jointness" is an inherent property attached to a single token (tree) rather than to a sequence of token trees.

I don't understand how FollowedBy is particularly different. Both are attached to single tokens. Both describe a relationship with the subsequent token tree.

Token streams can be arbitrarily modified by users and with the new scheme the real stream can go out of sync with FollowedBy values even more easily than with the previous Spacing.

Arbitrarily modified how? Token streams can be modified in proc macros but FollowedBy isn't used there, Spacing is. How else can token streams be arbitrarily modified by users?

I think the matklad's scheme in #76285 was fine

It caused a regression.

when parsing a token stream we just need to track whether a token is immediately followed by something or not, and then "censor" that information at proc macro boundary to match the public facing behavior documented in #114617.

That's exactly what this PR does. The three-value FollowedBy enum tracks what a token is followed by, and then it is "censored" at the proc macro boundary by converting it to the less expressive Spacing. FollowedBy is also used to improve pretty-printing.

I'd ideally first land a version of #76285 first, without any pretty-printing changes or renamings, but with regressions fixed. Not sure how exactly the regression was fixed in this PR, but I assume it doesn't strictly require introducing a third variant?

The problem in #76285 was the addition of code in from_internal that changed Joint markers to Alone if they weren't followed by a TokenTree::Token that satisfies is_op. This included the final token in a stream.

My original code had a similar check, causing the same problem. I fixed it by moving the is_op check from from_internal back into parse_token_trees, and introducing the three values in FollowedBy. I even added a comment warning others from adding a check to from_internal, because both matklad and I had made that mistake.

As for pretty-printing streams from proc macros, I think we can extend the internal spacing to enum Spacing { Joint, Alone, Unspecified } where Unspecified comes from non-Punct tokens created by proc macros. In the Unspecified case pretty-printing can fall back to heuristics.

What about pretty-printing streams from parsed code? The whole point of this PR is to improve that case. #76285 didn't affect that case. Your original suggestion on Zulip was "it would be preferable to preserve jointness for all tokens and use it instead during pretty-printing." That is what this PR does. You said that FollowedBy isn't the right model, but you haven't suggested an alternative that would improve pretty-printing from parsed code. The Joint/Alone model used for proc macros won't suffice, because Alone covers both "followed by whitespace" and "followed by non-punct", and better pretty-printing requires those cases be distinguished. Your suggested Joint/Alone/Unspecified also won't help that case.

FollowedBy works because it (a) has enough information to improve pretty-printing of parse code, and (b) downgrades perfectly to Spacing for proc macros.

@petrochenkov petrochenkov added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 9, 2023
@petrochenkov
Copy link
Contributor

I'll return to this in a few days.

In the meantime a question - how does this PR deal with the 'lifetime case?
The quote token must use Spacing::Joint in proc macros, but it will use FollowedBy::Other in rustc token streams.
So we still need to check the next token at proc macro boundary to decide whether to do censoring or not.
So we could check for the Punct vs Other distinction in the same place as well, instead of keeping two different variants in FollowedBy.

@nnethercote
Copy link
Contributor Author

In the meantime a question - how does this PR deal with the 'lifetime case?

The same way the current code does.

The quote token must use Spacing::Joint in proc macros, but it will use FollowedBy::Other in rustc token streams.

No. The Lifetime token contains the quote and the identifier. It is split here. This PR doesn't change that.

@petrochenkov
Copy link
Contributor

Does this code look like what you intended?

No :D

@petrochenkov
Copy link
Contributor

Where does print_tt's output show up in practice? I see it in the output of stringify!, is there anywhere else?

  • stringify!
  • Display impl for proc_macro::TokenStream
  • pretty-printing with rustc -Z unpretty (the result is sometimes fed to rustc again)
  • diagnostics

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 16, 2023

Could changes to the output break real-world code?

There's a possibility, at least.
Results of proc_macro::TokenStream::to_string and -Z unpretty can be parsed again, and in the past it happened especially often.
So it's better to preserve spacing at least for punctuation, if possible.

It's better to run the changes through crater in any case, because even the /*«*/ /*»*/ change had some compatibility issues.

@petrochenkov
Copy link
Contributor

  • Reinstate Move jointness censoring to proc_macro #76285, which was just a refactoring that didn't affect pretty-printing at all.
  • Add Spacing::Unspecified, which might help pretty-printing of proc macro code slightly, but would have no effect on pretty-printing of parsed code.

This is a PR mostly about pretty-printing of parsed code, but your suggestions don't relate to that.

There are a few logical changes here that I would prefer to review and land separately.

  • One is moving the jointness censoring to proc macro boundary
  • Another is using the jointness info for improving pretty printing for parsed code
  • Then Spacing::Unspecified can be added on top of that to improve pretty-printing for proc-macro generated code

@petrochenkov
Copy link
Contributor

What is the right model?

The current Spacing enum (possibly extended by Unspecified later).
The distinction between FollowedBy::Punct and FollowedBy::Other is only important at proc macro boundary, so I want to contain it to proc macro server, and do not want to thread it through the rest of the compiler.

@petrochenkov
Copy link
Contributor

petrochenkov commented Aug 16, 2023

The issue in #76399 is that the token stream constructed purely through proc macro interface (TokenStream::from(TokenTree::Punct(Punct::new(':', Spacing::Joint))))) somehow goes through logic that treats it as parsed code? Which results in marking the last token as Alone, which would be the right thing for parsed code.

TokenStream::from(TokenTree::Punct(Punct::new(':', Spacing::Joint)))) should certainly not go through a logic for parsed code.

UPD: Ah, I see, #114571 (comment) talks about the regression reason, but I don't like the way in which it's fixed in this PR.

@craterbot
Copy link
Collaborator

🎉 Experiment pr-114571-3 is completed!
📊 22 regressed and 3 fixed (393301 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Dec 1, 2023
@nnethercote
Copy link
Contributor Author

nnethercote commented Dec 5, 2023

I looked at the most recent full run. There are two new errors, each repeated a few times. I think neither is significant.

vgtk

Various errors like this, coming from the vgtk crate.

[INFO] [stdout] error: expected ",", ":", "::", "=" or "|"
[INFO] [stdout]   --> src/main.rs:37:61
[INFO] [stdout]    |
[INFO] [stdout] 37 |                     <CheckButton active=self.done on toggled=|_| Message::Toggle { index } />
[INFO] [stdout]    |                                                             ^
[INFO] [stdout]    |
[INFO] [stdout]    = note: this error originates in the macro `proc_macro_call_0` which comes from the expansion of the macro `gtk` (in Nightly builds, run with -Z macro-backtrace for more info)

vgtk has less than 5,000 downloads ever from crates.io, and hasn't been modified in over 3 years, so I don't think it's worth spending time on.

openbook-v2

Various errors like this, coming from openbook-v2:

[INFO] [stdout] error[E0119]: conflicting implementations of trait `Zeroable` for type `AnyEvent`
[INFO] [stdout]    --> /opt/rustwide/cargo-home/git/checkouts/openbook-v2-bb287b4bf73a7086/4a6daab/programs/openbook-v2/src/state/orderbook/heap.rs:220:32
[INFO] [stdout]     |
[INFO] [stdout] 219 | #[zero_copy]
[INFO] [stdout]     | ------------ first implementation here
[INFO] [stdout] 220 | #[derive(Debug, bytemuck::Pod, bytemuck::Zeroable)]
[INFO] [stdout]     |                                ^^^^^^^^^^^^^^^^^^ conflicting implementation for `AnyEvent`

This is from openbook-dex, which has only ~400 downloads ever from crates.io, from a single published version. Also not worth spending time on.

Conclusion

Based on this and the previous analysis, I think this is ok to be merged. The only follow-up would be to modify const-random to avoid problems. Those problems only showed up in tests on a couple of crates, but const-random has been downloaded 13.4M times so it seems prudent to fix it anyway.

@petrochenkov: what do you think?

compiler/rustc_expand/src/mbe.rs Outdated Show resolved Hide resolved
compiler/rustc_parse/src/lexer/tokentrees.rs Outdated Show resolved Hide resolved
compiler/rustc_parse/src/parser/expr.rs Outdated Show resolved Hide resolved
let this_spacing = if next_tok.is_punct() {
Spacing::Joint
} else if next_tok.kind == token::Eof {
Spacing::Alone
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this exception fixes cases like this?

// EOF immediately after string, so spacing is joint-hidden
"string"

The string token is then put into a token stream before an identifier.

"string"suffix

After pretty-printing and re-lexing the lexical structure is broken, "string"suffix is interpreted as 1 token instead of 2.

Spacing::Alone for EOF doesn't address the root issue here.
"string" can still get joint spacing in cases like "string"+ and be printed as "string"suffix later.

This case needs a special case in pretty-printer.
Then special treatment for EOF in this file won't be necessary.
That's not an urgent issue though, it can be addressed separately later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The one crate for which this was a problem is described in this comment above:


DarumaDocker.reactor-wasm

Uses wasmedge_bindgen macro from wasmedge-bindgen-macro-0.1.13.

Weird one... this:

   let gen = quote! {
        #[no_mangle]
        pub unsafe extern "C" fn #func_ident(params_pointer: *mut u32, params_count: i32) {         
        ...
   }

somehow becomes this:

#[no_mangle] pub unsafe extern "C"fn run(params_pointer : * mut u32, params_count : i32) {

The lack of space after "C" is a legitimate problem. Hmm.

Somehow, Eof is involved. If we change things so that tokens followed by
Eof have Alone spacing instead of JointHidden spacing, that fixes the
problem. I don't understand why.


So it is a string suffix issue like you suggested. A follow-up sounds good, it only affected one crate in all the crater runs.

@petrochenkov
Copy link
Contributor

r=me after the style fixes.
@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 8, 2023
`tokenstream::Spacing` appears on all `TokenTree::Token` instances,
both punct and non-punct. Its current usage:
- `Joint` means "can join with the next token *and* that token is a
  punct".
- `Alone` means "cannot join with the next token *or* can join with the
  next token but that token is not a punct".

The fact that `Alone` is used for two different cases is awkward.
This commit augments `tokenstream::Spacing` with a new variant
`JointHidden`, resulting in:
- `Joint` means "can join with the next token *and* that token is a
  punct".
- `JointHidden` means "can join with the next token *and* that token is a
  not a punct".
- `Alone` means "cannot join with the next token".

This *drastically* improves the output of `print_tts`. For example,
this:
```
stringify!(let a: Vec<u32> = vec![];)
```
currently produces this string:
```
let a : Vec < u32 > = vec! [] ;
```
With this PR, it now produces this string:
```
let a: Vec<u32> = vec![] ;
```
(The space after the `]` is because `TokenTree::Delimited` currently
doesn't have spacing information. The subsequent commit fixes this.)

The new `print_tts` doesn't replicate original code perfectly. E.g.
multiple space characters will be condensed into a single space
character. But it's much improved.

`print_tts` still produces the old, uglier output for code produced by
proc macros. Because we have to translate the generated code from
`proc_macro::Spacing` to the more expressive `token::Spacing`, which
results in too much `proc_macro::Along` usage and no
`proc_macro::JointHidden` usage. So `space_between` still exists and
is used by `print_tts` in conjunction with the `Spacing` field.

This change will also help with the removal of `Token::Interpolated`.
Currently interpolated tokens are pretty-printed nicely via AST pretty
printing. `Token::Interpolated` removal will mean they get printed with
`print_tts`. Without this change, that would result in much uglier
output for code produced by decl macro expansions. With this change, AST
pretty printing and `print_tts` produce similar results.

The commit also tweaks the comments on `proc_macro::Spacing`. In
particular, it refers to "compound tokens" rather than "multi-char
operators" because lifetimes aren't operators.
This is an extension of the previous commit. It means the output of
something like this:
```
stringify!(let a: Vec<u32> = vec![];)
```
goes from this:
```
let a: Vec<u32> = vec![] ;
```
With this PR, it now produces this string:
```
let a: Vec<u32> = vec![];
```
Because the spacing-based pretty-printing partially preserves that.
@nnethercote
Copy link
Contributor Author

I fixed the style nits.

@bors r=petrochenkov

@bors
Copy link
Contributor

bors commented Dec 10, 2023

📌 Commit 940c885 has been approved by petrochenkov

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 10, 2023
@bors
Copy link
Contributor

bors commented Dec 11, 2023

⌛ Testing commit 940c885 with merge a9cb8ee...

@bors
Copy link
Contributor

bors commented Dec 11, 2023

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing a9cb8ee to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 11, 2023
@bors bors merged commit a9cb8ee into rust-lang:master Dec 11, 2023
12 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Dec 11, 2023
@nnethercote nnethercote deleted the improve-print_tts branch December 11, 2023 02:28
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a9cb8ee): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.2% [0.2%, 0.2%] 1
Regressions ❌
(secondary)
0.8% [0.5%, 1.0%] 8
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.2% [-0.3%, -0.2%] 2
All ❌✅ (primary) 0.2% [0.2%, 0.2%] 1

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.0% [-1.0%, -1.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -1.0% [-1.0%, -1.0%] 1

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.1% [0.0%, 0.2%] 31
Regressions ❌
(secondary)
0.1% [0.1%, 0.2%] 12
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.1% [0.0%, 0.2%] 31

Bootstrap: 668.008s -> 669.249s (0.19%)
Artifact size: 314.06 MiB -> 314.13 MiB (0.02%)

@rustbot rustbot added the perf-regression Performance regression. label Dec 11, 2023
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Feb 18, 2024
Pkgsrc changes:
 * Adapt checksums and patches.

Upstream chnages:

Version 1.76.0 (2024-02-08)
==========================

Language
--------
- [Document Rust ABI compatibility between various types]
  (rust-lang/rust#115476)
- [Also: guarantee that char and u32 are ABI-compatible]
  (rust-lang/rust#118032)
- [Warn against ambiguous wide pointer comparisons]
  (rust-lang/rust#117758)

Compiler
--------
- [Lint pinned `#[must_use]` pointers (in particular, `Box<T>`
  where `T` is `#[must_use]`) in `unused_must_use`.]
  (rust-lang/rust#118054)
- [Soundness fix: fix computing the offset of an unsized field in
  a packed struct]
  (rust-lang/rust#118540)
- [Soundness fix: fix dynamic size/align computation logic for
  packed types with dyn Trait tail]
  (rust-lang/rust#118538)
- [Add `$message_type` field to distinguish json diagnostic outputs]
  (rust-lang/rust#115691)
- [Enable Rust to use the EHCont security feature of Windows]
  (rust-lang/rust#118013)
- [Add tier 3 {x86_64,i686}-win7-windows-msvc targets]
  (rust-lang/rust#118150)
- [Add tier 3 aarch64-apple-watchos target]
  (rust-lang/rust#119074)
- [Add tier 3 arm64e-apple-ios & arm64e-apple-darwin targets]
  (rust-lang/rust#115526)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------
- [Add a column number to `dbg!()`]
  (rust-lang/rust#114962)
- [Add `std::hash::{DefaultHasher, RandomState}` exports]
  (rust-lang/rust#115694)
- [Fix rounding issue with exponents in fmt]
  (rust-lang/rust#116301)
- [Add T: ?Sized to `RwLockReadGuard` and `RwLockWriteGuard`'s Debug impls.]
  (rust-lang/rust#117138)
- [Windows: Allow `File::create` to work on hidden files]
  (rust-lang/rust#116438)

Stabilized APIs
---------------
- [`Arc::unwrap_or_clone`]
  (https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#method.unwrap_or_clone)
- [`Rc::unwrap_or_clone`]
  (https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#method.unwrap_or_clone)
- [`Result::inspect`]
  (https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.inspect)
- [`Result::inspect_err`]
  (https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.inspect_err)
- [`Option::inspect`]
  (https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.inspect)
- [`type_name_of_val`]
  (https://doc.rust-lang.org/stable/std/any/fn.type_name_of_val.html)
- [`std::hash::{DefaultHasher, RandomState}`]
  (https://doc.rust-lang.org/stable/std/hash/index.html#structs)
  These were previously available only through `std::collections::hash_map`.
- [`ptr::{from_ref, from_mut}`]
  (https://doc.rust-lang.org/stable/std/ptr/fn.from_ref.html)
- [`ptr::addr_eq`](https://doc.rust-lang.org/stable/std/ptr/fn.addr_eq.html)

Cargo
-----

See [Cargo release notes]
(https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-176-2024-02-08).

Rustdoc
-------
- [Don't merge cfg and doc(cfg) attributes for re-exports]
  (rust-lang/rust#113091)
- [rustdoc: allow resizing the sidebar / hiding the top bar]
  (rust-lang/rust#115660)
- [rustdoc-search: add support for traits and associated types]
  (rust-lang/rust#116085)
- [rustdoc: Add highlighting for comments in items declaration]
  (rust-lang/rust#117869)

Compatibility Notes
-------------------
- [Add allow-by-default lint for unit bindings]
  (rust-lang/rust#112380)
  This is expected to be upgraded to a warning by default in a future Rust
  release. Some macros emit bindings with type `()` with user-provided spans,
  which means that this lint will warn for user code.
- [Remove x86_64-sun-solaris target.]
  (rust-lang/rust#118091)
- [Remove asmjs-unknown-emscripten target]
  (rust-lang/rust#117338)
- [Report errors in jobserver inherited through environment variables]
  (rust-lang/rust#113730)
  This [may warn](rust-lang/rust#120515)
  on benign problems too.
- [Update the minimum external LLVM to 16.]
  (rust-lang/rust#117947)
- [Improve `print_tts`](rust-lang/rust#114571)
  This change can break some naive manual parsing of token trees
  in proc macro code which expect a particular structure after
  `.to_string()`, rather than just arbitrary Rust code.
- [Make `IMPLIED_BOUNDS_ENTAILMENT` into a hard error from a lint]
  (rust-lang/rust#117984)
- [Vec's allocation behavior was changed when collecting some iterators]
  (rust-lang/rust#110353)
  Allocation behavior is currently not specified, nevertheless
  changes can be surprising.
  See [`impl FromIterator for Vec`]
  (https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html#impl-FromIterator%3CT%3E-for-Vec%3CT%3E)
  for more details.
- [Properly reject `default` on free const items]
  (rust-lang/rust#117818)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants