Closed
Conversation
Add two small tests to highlight how vertical tab is handled differently. - vertical_tab_lexer.rs checks that the lexer treats vertical tab as whitespace - ascii_whitespace_excludes_vertical_tab.rs shows that split_ascii_whitespace does not split on it This helps document the difference between the Rust parser (which accepts vertical tab) and the standard library’s ASCII whitespace handling. See: rust-lang/rust-project-goals#53
make sure tabs and spaces are well checked
Add failing UI test for invalid whitespace (zero width space) This adds a //@ check-fail test to ensure that disallowed whitespace characters like ZERO WIDTH SPACE are rejected by the Rust lexer.
git commit -m "Fix tidy: add trailing newline" git push
Remove unnecessary blank lines in invalid_whitespace.rs
Update comment to clarify usage of ZERO WIDTH SPACE.
Updated error messages to clarify the issue with invisible characters.
Update test to check for invalid whitespace characters.
Fix whitespace issue causing unknown token error.
Fix invisible character issue in variable assignment.
Updated error message to clarify invisible characters.
Updated error message for invisible characters in code.
Add error message for invalid whitespace in code
…yukang tests: add whitespace tests for vertical tab behavior This PR adds two small tests to highlight how vertical tab (\x0B) is handled differently across Rust's whitespace definitions. The Rust lexer treats vertical tab as whitespace (Unicode Pattern_White_Space), while `split_ascii_whitespace` follows the WhatWG Infra Standard and does not include vertical tab. These tests make that difference visible and easier to understand. See: rustfoundation/interop-initiative#53
…lace, r=chenyukang Rewrite `FlatMapInPlace`. Replace the hacky macro with a generic function and a new `FlatMapInPlaceVec` trait. More verbose but more readable and typical. LLM disclosure: I asked Claude Code to critique this file and it suggested the generic function + trait idea. I implemented the idea entirely by hand. r? @chenyukang
…-closure, r=wesleywiser Fix wrong suggestion for returning async closure Fixes rust-lang#150701 r? @estebank
…TaKO8Ki Fix `#[expect(dead_code)]` liveness propagation Fixes rust-lang#154324 Fixes rust-lang#152370 (cc @eggyal) Previously, when traversing from a `ComesFromAllowExpect::Yes` item (i.e., with `#[allow(dead_code)]` or `#[expect(dead_code)]`), other `ComesFromAllowExpect::Yes` items reached during propagation would be updated to `ComesFromAllowExpect::No` and inserted into `live_symbols`. That caused `dead_code` lint couldn't be emitted correctly. After this PR, `ComesFromAllowExpect::Yes` items no longer incorrectly update other `ComesFromAllowExpect::Yes` items during propagation or mark them live by mistake, then `dead_code` lint could behave as expected.
…anBrouwer,GuillaumeGomez Move diagnostic attribute target checks from check_attr Move diagnostic attribute target checks into their targets. Part of rust-lang#131229 (comment) This is much easier with `emit_dyn_lint` :) (thanks @GuillaumeGomez !) I think there might be some opportunity to simplify all these `check_diagnostic_*` methods in `check_attr`. However there are some diagnostic attribute prs in flight and I'd like to wait for those to land first and then think about it. So that PR is not for today. r? @JonathanBrouwer (or @GuillaumeGomez if you want)
…rochenkov Ensure we don't feed owners from ast lowering if we ever make that query tracked follow-up to rust-lang#153489 I don't expect this to ever really be an issue, but better safe than sorry 😆
rustbot
added
A-attributes
Member
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
Contributor
|
PR #155028, which is a member of this rollup, changed its commit SHA. This rollup was closed. |
rustbot
removed
the
S-waiting-on-author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
FlatMapInPlace. #155582 (RewriteFlatMapInPlace.)#[expect(dead_code)]liveness propagation #154377 (Fix#[expect(dead_code)]liveness propagation)Failed merges:
AttributeLintKindvariants - part 5 #155590 (Remove AttributeLintKind variants - part 5)r? @ghost
Create a similar rollup