chore: Bump Rust to 1.82 #19349
Closed
chore: Bump Rust to 1.82 #19349
Conversation
This file contains 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
cla-bot
bot
added
the
cla-signed
Fixes #19353 Release Notes: - N/A
…#19358) Release Notes: - N/A
…onth (#19367) This PR makes it so new subscriptions will have their billing cycle anchored to the first of the month. When someone signs up today, they will be billed starting on the first of next month. Release Notes: - N/A Co-authored-by: Antonio <[email protected]> Co-authored-by: Richard <[email protected]>
- This reverts the change I made in #15535 which set `option_as_meta` to `true` in the default settings. - `true` is a reasonable default for US Keyboards, but is terrible for many others which rely on `alt+<key>` for totally normal keystroke combinations.
Ran into this this morning. At least I suspect I ran into it. In any case: we need to reset the missed hearbeats to 0 in case we got any connection activity. Release Notes: - N/A
This makes the `editor: copy permalink to line` and `editor: copy permalink to line` actions work in SSH remote projects. Previously it would only work in local projects. Demo: https://github.com/user-attachments/assets/a8012152-b631-4b34-9ff2-e4d033c97dee Release Notes: - N/A
This PR is a quick follow-up to #19364 which updates some left-out occurrences of `option_as_meta` to the new default value (`false`).
Release Notes: - Fixed inconsistent serialization of workspace paths order
Release Notes: - N/A
Release Notes: - Fixed `cmd-o` in an SSH project to always open a local project
- Closes: #19351 - Switch to using the official [typos GitHub Action](https://github.com/crate-ci/typos/blob/master/docs/github-action.md) - Move the typos check into `actions/check_style` - Move Squawk Postgres migration check out of `actions/check_style` file into ci.yml - `actions/check_style` can now be run on stateless/linux runners (previous required self-hosted MacOS runner) - ci.yml: Split old `style` into checks into those that can run statelessly (linux) and everything else into a new `migration` group which benefit from the full git checkout available on the MacOS runners. - ci.yml: Move `Check unused dependencies` from style to `linux_tests` - Add `if: github.repository_owner == 'zed-industries'` to all jobs so they won't try and run on GitHub forks.
…editor (#18240) This changes the `/workflow` command so that instead of emitting edits in separate steps, the user is presented with a single tab, with an editable diff that they can apply to the buffer. Todo * Assistant panel * [x] Show a patch title and a list of changed files in a block decoration * [x] Don't store resolved patches as state on Context. Resolve on demand. * [ ] Better presentation of patches in the panel * [ ] Show a spinner while patch is streaming in * Patches * [x] Preserve leading whitespace in new text, auto-indent insertions * [x] Ensure patch title is very short, to fit better in tab * [x] Improve patch location resolution, prefer skipping whitespace over skipping `}` * [x] Ensure patch edits are auto-indented properly * [ ] Apply `Update` edits via a diff between the old and new text, to get fine-grained edits. * Proposed changes editor * [x] Show patch title in the tab * [x] Add a toolbar with an "Apply all" button * [x] Make `open excerpts` open the corresponding location in the base buffer (#18591) * [x] Add an apply button above every hunk (#18592) * [x] Expand all diff hunks by default (#18598) * [x] Fix #18589 * [x] Syntax highlighting doesn't work until the buffer is edited (#18648) * [x] Disable LSP interaction in Proposed Changes editor (#18945) * [x] No auto-indent? (#18984) * Prompt * [ ] make sure old_text is unique Release Notes: - N/A --------- Co-authored-by: Marshall Bowers <[email protected]> Co-authored-by: Antonio <[email protected]> Co-authored-by: Richard <[email protected]> Co-authored-by: Marshall <[email protected]> Co-authored-by: Nate Butler <[email protected]> Co-authored-by: Antonio Scandurra <[email protected]> Co-authored-by: Richard Feldman <[email protected]>
This PR moves the spelling check out of the `check_style` action, which we can leave for just checking formatting. We can't use the `crates-ci-typos` action as-is on the macOS runners due to the absence of `wget`. Release Notes: - N/A
This PR updates a doc comment to use proper capitalization. Also removes an unneeded `return`. Release Notes: - N/A
1 task
|
It seems that we're hitting an infinite loop on this line https://github.com/zed-industries/zed/blob/main/extensions/test-extension/src/test_extension.rs#L77 when we're trying to restart the language server at , which results in stalled await on |
|
The test passes when the test extension is compiled with 1.81 and the rest uses 1.82. |
|
I've bisected it to nightly-2024-08-24 and I'm pretty sure it's rust-lang/rust@736f773 that's the culprit. |
osiewicz
added a commit
to osiewicz/rust
that referenced
this pull request
Nov 18, 2024
When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
osiewicz
added a commit
to osiewicz/rust
that referenced
this pull request
Nov 18, 2024
When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
|
Given that we pivoted into fixing stdlib for this (rust-lang/rust#133184), this PR seems obsolete. |
|
Eh, I'd say this PR is still relevant, but we can reopen it in a few months. |
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Dec 8, 2024
…-remove-dir-all, r=Noratrieb wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Dec 9, 2024
…-remove-dir-all, r=Noratrieb wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this pull request
Dec 9, 2024
…-remove-dir-all, r=Noratrieb wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this pull request
Dec 9, 2024
…-remove-dir-all, r=Noratrieb wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
fmease
added a commit
to fmease/rust
that referenced
this pull request
Dec 9, 2024
…-remove-dir-all, r=Noratrieb wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
fmease
added a commit
to fmease/rust
that referenced
this pull request
Dec 9, 2024
…-remove-dir-all, r=Noratrieb wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
fmease
added a commit
to fmease/rust
that referenced
this pull request
Dec 10, 2024
…-remove-dir-all, r=Noratrieb wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 10, 2024
Rollup merge of rust-lang#133184 - osiewicz:wasm-fix-infinite-loop-in-remove-dir-all, r=Noratrieb wasi/fs: Improve stopping condition for <ReadDir as Iterator>::next When upgrading [Zed](zed-industries/zed#19349) to Rust 1.82 I've encountered a test failure in our test suite. Specifically, one of our extension tests started hanging. I've tracked it down to a call to std::fs::remove_dir_all not returning when an extension is compiled with Rust 1.82 Our extension system uses WASM components, thus I've looked at the diff between 1.81 and 1.82 with respect to WASI and found 736f773 As it turned out, calling remove_dir_all from extension returned io::ErrorKind::NotFound in 1.81; the underlying issue is that the ReadDir iterator never actually terminates iteration, however since it loops around, with 1.81 we'd come across an entry second time and fail to remove it, since it would've been removed previously. With 1.82 and 736f773 it is no longer the case, thus we're seeing the hang. The tests do pass when everything but the extensions is compiled with 1.82. This commit makes ReadDir::next adhere to readdir contract, namely it will no longer call readdir once the returned # of bytes is smaller than the size of a passed-in buffer. Previously we'd only terminate the loop if readdir returned 0.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Closes #ISSUE
Release Notes: