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.

Sign up for GitHub

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

Jump to bottom

Bump the cargo group across 1 directory with 5 updates #2479

Closed
wants to merge 1 commit into from
Closed

Bump the cargo group across 1 directory with 5 updates #2479

wants to merge 1 commit into from

Conversation

dependabot[bot]
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Nov 4, 2024 •
edited
Loading

Bumps the cargo group with 5 updates in the / directory:

Package From To
thiserror 1.0.65 1.0.68
anyhow 1.0.91 1.0.92
nalgebra 0.33.1 0.33.2
wgpu 22.1.0 23.0.0
url 2.5.2 2.5.3

Updates thiserror from 1.0.65 to 1.0.68

Release notes

Sourced from thiserror's releases.

1.0.68

  • Handle incomplete expressions more robustly in format arguments, such as while code is being typed (#341, #344)

1.0.67

  • Improve expression syntax support inside format arguments (#335, #337, #339, #340)

1.0.66

  • Improve compile error on malformed format attribute (#327)
Commits
  • 8d06fb5 Release 1.0.68
  • 372fd8a Merge pull request #344 from dtolnay/binop
  • 08f8992 Disregard equality binop in fallback parser
  • d2a823d Merge pull request #343 from dtolnay/unnamed
  • b3bf7a6 Add logic to determine whether unnamed fmt arguments are present
  • 490f9c0 Merge pull request #342 from dtolnay/synfull
  • 7daf1b1 Defer is_syn_full() call until first expression
  • c92ac99 Merge pull request #341 from dtolnay/parsescan
  • 40a53f7 Interleave Expr parsing and scanning better
  • 925f2dd Release 1.0.67
  • Additional commits viewable in compare view

Updates anyhow from 1.0.91 to 1.0.92

Release notes

Sourced from anyhow's releases.

1.0.92

  • Support Rust 1.82's &raw const and &raw mut syntax inside ensure! (#390)
Commits

Updates nalgebra from 0.33.1 to 0.33.2

Changelog

Sourced from nalgebra's changelog.

[0.33.2] (29 October 2024)

Added

  • Add the convert-glam029 feature to enable conversion from/to types from glam v0.29.
Commits

Updates wgpu from 22.1.0 to 23.0.0

Release notes

Sourced from wgpu's releases.

v23.0.0 (2024-10-25)

Themes of this release

This release's theme is one that is likely to repeat for a few releases: convergence with the WebGPU specification! WGPU's design and base functionality are actually determined by two specifications: one for WebGPU, and one for the WebGPU Shading Language.

This may not sound exciting, but let us convince you otherwise! All major web browsers have committed to offering WebGPU in their environment. Even JS runtimes like Node and Deno have communities that are very interested in providing WebGPU! WebGPU is slowly eating the world, as it were. 😀 It's really important, then, that WebGPU implementations behave in ways that one would expect across all platforms. For example, if Firefox's WebGPU implementation were to break when running scripts and shaders that worked just fine in Chrome, that would mean sad users for both application authors and browser authors.

WGPU also benefits from standard, portable behavior in the same way as web browsers. Because of this behavior, it's generally fairly easy to port over usage of WebGPU in JavaScript to WGPU. It is also what lets WGPU go full circle: WGPU can be an implementation of WebGPU on native targets, but also it can use other implementations of WebGPU as a backend in JavaScript when compiled to WASM. Therefore, the same dynamic applies: if WGPU's own behavior were significantly different, then WGPU and end users would be sad, sad humans as soon as they discover places where their nice apps are breaking, right?

The answer is: yes, we do have sad, sad humans that really want their WGPU code to work everywhere. As Firefox and others use WGPU to implement WebGPU, the above example of Firefox diverging from standard is, unfortunately, today's reality. It mostly behaves the same as a standards-compliant WebGPU, but it still doesn't in many important ways. Of particular note is Naga, its implementation of the WebGPU Shader Language. Shaders are pretty much a black-and-white point of failure in GPU programming; if they don't compile, then you can't use the rest of the API! And yet, it's extremely easy to run into this:

fn gimme_a_float() -> f32 {
  return 42; // fails in Naga, but standard WGSL happily converts to `f32`
}

We intend to continue making visible strides in converging with specifications for WebGPU and WGSL, as this release has. This is, unfortunately, one of the major reasons that WGPU has no plans to work hard at keeping a SemVer-stable interface for the foreseeable future; we have an entire platform of GPU programming functionality we have to catch up with, and SemVer stability is unfortunately in tension with that. So, for now, you're going to keep seeing major releases and breaking changes. Where possible, we'll try to make that painless, but compromises to do so don't always make sense with our limited resources.

This is also the last planned major version release of 2024; the next milestone is set for January 1st, 2025, according to our regular 12-week cadence (offset from the originally planned date of 2024-10-09 for this release 😅). We'll see you next year!

Contributor spotlight: @​sagudev

This release, we'd like to spotlight the work of @​sagudev, who has made significant contributions to the WGPU ecosystem this release. Among other things, they contributed a particularly notable feature where runtime-known indices are finally allowed for use with const array values. For example, this WGSL shader previously wasn't allowed:

const arr: array<u32, 4> = array(1, 2, 3, 4);
fn what_number_should_i_use(idx: u32) -> u32 {
return arr[idx];
}

…but now it works! This is significant because this sort of shader rejection was one of the most impactful issues we are aware of for converging with the WGSL specification. There are more still to go—some of which we expect to even more drastically change how folks author shaders—but we suspect that many more will come in the next few releases, including with @​sagudev's help.

We're excited for more of @​sagudev's contributions via the Servo community. Oh, did we forget to mention that these contributions were motivated by their work on Servo? That's right, a third well-known JavaScript runtime is now using WGPU to implement its WebGPU implementation. We're excited to support Servo to becoming another fully fledged browsing environment this way.

Major Changes

In addition to the above spotlight, we have the following particularly interesting items to call out for this release:

wgpu-core is no longer generic over wgpu-hal backends

Dynamic dispatch between different backends has been moved from the user facing wgpu crate, to a new dynamic dispatch mechanism inside the backend abstraction layer wgpu-hal.

Whenever targeting more than a single backend (default on Windows & Linux) this leads to faster compile times and smaller binaries! This also solves a long standing issue with cargo doc failing to run for wgpu-core.

... (truncated)

Changelog

Sourced from wgpu's changelog.

23.0.0 (2024-10-25)

Themes of this release

This release's theme is one that is likely to repeat for a few releases: convergence with the WebGPU specification! WGPU's design and base functionality are actually determined by two specifications: one for WebGPU, and one for the WebGPU Shading Language.

This may not sound exciting, but let us convince you otherwise! All major web browsers have committed to offering WebGPU in their environment. Even JS runtimes like Node and Deno have communities that are very interested in providing WebGPU! WebGPU is slowly eating the world, as it were. 😀 It's really important, then, that WebGPU implementations behave in ways that one would expect across all platforms. For example, if Firefox's WebGPU implementation were to break when running scripts and shaders that worked just fine in Chrome, that would mean sad users for both application authors and browser authors.

WGPU also benefits from standard, portable behavior in the same way as web browsers. Because of this behavior, it's generally fairly easy to port over usage of WebGPU in JavaScript to WGPU. It is also what lets WGPU go full circle: WGPU can be an implementation of WebGPU on native targets, but also it can use other implementations of WebGPU as a backend in JavaScript when compiled to WASM. Therefore, the same dynamic applies: if WGPU's own behavior were significantly different, then WGPU and end users would be sad, sad humans as soon as they discover places where their nice apps are breaking, right?

The answer is: yes, we do have sad, sad humans that really want their WGPU code to work everywhere. As Firefox and others use WGPU to implement WebGPU, the above example of Firefox diverging from standard is, unfortunately, today's reality. It mostly behaves the same as a standards-compliant WebGPU, but it still doesn't in many important ways. Of particular note is Naga, its implementation of the WebGPU Shader Language. Shaders are pretty much a black-and-white point of failure in GPU programming; if they don't compile, then you can't use the rest of the API! And yet, it's extremely easy to run into a case like that from gfx-rs/wgpu#4400:

fn gimme_a_float() -> f32 {
  return 42; // fails in Naga, but standard WGSL happily converts to `f32`
}

We intend to continue making visible strides in converging with specifications for WebGPU and WGSL, as this release has. This is, unfortunately, one of the major reasons that WGPU has no plans to work hard at keeping a SemVer-stable interface for the foreseeable future; we have an entire platform of GPU programming functionality we have to catch up with, and SemVer stability is unfortunately in tension with that. So, for now, you're going to keep seeing major releases and breaking changes. Where possible, we'll try to make that painless, but compromises to do so don't always make sense with our limited resources.

This is also the last planned major version release of 2024; the next milestone is set for January 1st, 2025, according to our regular 12-week cadence (offset from the originally planned date of 2024-10-09 for this release 😅). We'll see you next year!

Contributor spotlight: @​sagudev

This release, we'd like to spotlight the work of @​sagudev, who has made significant contributions to the WGPU ecosystem this release. Among other things, they contributed a particularly notable feature where runtime-known indices are finally allowed for use with const array values. For example, this WGSL shader previously wasn't allowed:

const arr: array<u32, 4> = array(1, 2, 3, 4);
fn what_number_should_i_use(idx: u32) -> u32 {
return arr[idx];
}

…but now it works! This is significant because this sort of shader rejection was one of the most impactful issues we are aware of for converging with the WGSL specification. There are more still to go—some of which we expect to even more drastically change how folks author shaders—but we suspect that many more will come in the next few releases, including with @​sagudev's help.

We're excited for more of @​sagudev's contributions via the Servo community. Oh, did we forget to mention that these contributions were motivated by their work on Servo? That's right, a third well-known JavaScript runtime is now using WGPU to implement its WebGPU implementation. We're excited to support Servo to becoming another fully fledged browsing environment this way.

Major Changes

In addition to the above spotlight, we have the following particularly interesting items to call out for this release:

wgpu-core is no longer generic over wgpu-hal backends

Dynamic dispatch between different backends has been moved from the user facing wgpu crate, to a new dynamic dispatch mechanism inside the backend abstraction layer wgpu-hal.

... (truncated)

Commits
  • 08c9d8c chore: bump WGPU workspace crates to 23
  • 1ab5f65 docs(CHANGELOG): add missing entry for #6107
  • 9bf9bb8 style(CHANGELOG): join soft-wrapped lines in Unreleased
  • 0ad2753 docs(CHANGELOG): add Major changes item for Optional entry points
  • cd5f52b docs(CHANGELOG): add Major changes item for windows ecosystem migration
  • 5e06e2a style(CHANGELOG): end entries with periods
  • 1a26cc0 style(CHANGELOG): use imperative tense in #6276 entry
  • 276a8a6 typo(CHANGELOG): add missing "in" b/w author and PR num.
  • 3dfeed6 docs(CHANGELOG): add high-level content for release
  • 6a053cf docs(CHANGELOG): use imperative tense for #6108 entry
  • Additional commits viewable in compare view

Updates url from 2.5.2 to 2.5.3

Release notes

Sourced from url's releases.

v2.5.3

What's Changed

New Contributors

Full Changelog: servo/rust-url@v2.5.2...v2.5.3

Commits

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

@dependabot
Bump the cargo group across 1 directory with 5 updates
c2cc977 
Bumps the cargo group with 5 updates in the / directory:

| Package | From | To |
| --- | --- | --- |
| [thiserror](https://github.com/dtolnay/thiserror) | `1.0.65` | `1.0.68` |
| [anyhow](https://github.com/dtolnay/anyhow) | `1.0.91` | `1.0.92` |
| [nalgebra](https://github.com/dimforge/nalgebra) | `0.33.1` | `0.33.2` |
| [wgpu](https://github.com/gfx-rs/wgpu) | `22.1.0` | `23.0.0` |
| [url](https://github.com/servo/rust-url) | `2.5.2` | `2.5.3` |



Updates `thiserror` from 1.0.65 to 1.0.68
- [Release notes](https://github.com/dtolnay/thiserror/releases)
- [Commits](dtolnay/thiserror@1.0.65...1.0.68)

Updates `anyhow` from 1.0.91 to 1.0.92
- [Release notes](https://github.com/dtolnay/anyhow/releases)
- [Commits](dtolnay/anyhow@1.0.91...1.0.92)

Updates `nalgebra` from 0.33.1 to 0.33.2
- [Changelog](https://github.com/dimforge/nalgebra/blob/main/CHANGELOG.md)
- [Commits](dimforge/nalgebra@v0.33.1...v0.33.2)

Updates `wgpu` from 22.1.0 to 23.0.0
- [Release notes](https://github.com/gfx-rs/wgpu/releases)
- [Changelog](https://github.com/gfx-rs/wgpu/blob/trunk/CHANGELOG.md)
- [Commits](gfx-rs/wgpu@wgpu-v22.1.0...wgpu-v23.0.0)

Updates `url` from 2.5.2 to 2.5.3
- [Release notes](https://github.com/servo/rust-url/releases)
- [Commits](servo/rust-url@v2.5.2...v2.5.3)

---
updated-dependencies:
- dependency-name: thiserror
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: cargo
- dependency-name: anyhow
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: cargo
- dependency-name: nalgebra
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: cargo
- dependency-name: wgpu
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: cargo
- dependency-name: url
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: cargo
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot requested a review from hannobraun as a code owner November 4, 2024 17:52
@dependabot dependabot bot added dependencies Pull requests that update a dependency file rust Pull requests that update Rust code labels Nov 4, 2024
@dependabot dependabot bot mentioned this pull request Nov 4, 2024
Closed
@hannobraun
Copy link
Owner

@dependabot show wgpu ignore conditions

@dependabot Dependabot
Copy link
Contributor Author

dependabot bot commented on behalf of github Nov 4, 2024

No ignore conditions found for the dependency wgpu

@hannobraun
Copy link
Owner

@dependabot wgpu ignore patch version

@hannobraun
Copy link
Owner

@dependabot wgpu ignore minor version

@hannobraun
Copy link
Owner

@dependabot ignore wgpu patch version

@dependabot Dependabot
Copy link
Contributor Author

dependabot bot commented on behalf of github Nov 4, 2024

OK, I won't notify you about version 23.0.0 of wgpu again, unless you unignore it.

@dependabot Dependabot
Copy link
Contributor Author

dependabot bot commented on behalf of github Nov 4, 2024

Looks like these dependencies are updatable in another way, so this is no longer needed.

@dependabot dependabot bot closed this Nov 4, 2024
@dependabot dependabot bot deleted the dependabot/cargo/cargo-93e4259618 branch November 4, 2024 18:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@hannobraun hannobraun Awaiting requested review from hannobraun hannobraun is a code owner

Assignees
No one assigned
Labels
dependencies Pull requests that update a dependency file rust Pull requests that update Rust code
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@hannobraun