Extend glam support up to version 0.24.0.

[jnises]

We would like update glam version to match other dependencies.

[eddyb]

Seems the new copysign stuff causes some issues.

This looks like it might be an issue upstream in glam where compatibility with no_std+libm wasn't checked?
Though, it also feels like it may be limited to target_arch = "spirv" support?

[eddyb]

I suspect this is blocked on this PR getting into a release (whether 0.23.1 or 0.24.0):

• Make enabling libm override std math functions bitshifter/glam-rs#389

cc @bitshifter (no_std + libm broke in 0.23.0 AFAICT)

[jnises]

If I patch glam to latest main the problem goes away.
So I guess bitshifter/glam-rs#389 solves the issue.

[eddyb]

Merge remote-tracking branch 'origin/main' into glam-update-23

Make sure to run git pull --rebase instead of git pull, as these merge commits could cause issues.

Also, remember to mark the commit as "ready for review" and ping me to look at once, once it's 100% ready.

[jnises]

Merge remote-tracking branch 'origin/main' into glam-update-23

Make sure to run git pull --rebase instead of git pull, as these merge commits could cause issues.

Also, remember to mark the commit as "ready for review" and ping me to look at once, once it's 100% ready.

Sorry. I had forgotten about this PR 😓
I can have a look at it next week.

[jnises]

This seems to work for us now.
Would it be better to accept a range of glam versions?
@eddyb

[eddyb]

Suggested change

	num-traits = { version = "0.2.14", default-features = false, features = ["libm"] }
	num-traits = { version = "0.2.15", default-features = false, features = ["libm"] }

... this is all it takes to make 0.23 work, too, I'm so sorry for not noticing this earlier!

(EDIT: unresolved this to leave it visible as an explanation)

[eddyb]

Let's do the range thing now that we know raising the num-traits dependency is enough to support 0.23, and don't forget to add a CHANGELOG entry along the lines of "relaxing glam version requirements" or something (i.e. we should specify the range we support, not just say we updated).

[eddyb]

(sorry for the back & forth, I'll apply these suggestions myself to land this)

[eddyb]

Btw, one of the reasons we can keep using a range is that we actually do have a bit of testing, from:

• ci: add custom lint for spirv-std building with -Z minimal-versions. #1054

That is, cargo -Z minimal-versions will always pick the lowest endpoint of the range (0.22 even after this PR), so that test will be able to catch anything as obvious as spirv-std using a newer glam type/method.