search

hannobraun / fornjot

Early-stage b-rep CAD kernel, written in the Rust programming language.
https://www.fornjot.app/
Other
2.06k stars 118 forks source link

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

Closed dependabot[bot] closed 3 weeks ago

dependabot[bot] commented 3 weeks ago

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: https://github.com/servo/rust-url/compare/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 ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore 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 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 ` 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 ` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore ` will remove the ignore condition of the specified dependency and ignore conditions
hannobraun commented 3 weeks ago

@dependabot show wgpu ignore conditions

dependabot[bot] commented 3 weeks ago

No ignore conditions found for the dependency wgpu

hannobraun commented 3 weeks ago

@dependabot wgpu ignore patch version

hannobraun commented 3 weeks ago

@dependabot wgpu ignore minor version

hannobraun commented 3 weeks ago

@dependabot ignore wgpu patch version

dependabot[bot] commented 3 weeks ago

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

dependabot[bot] commented 3 weeks ago

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