Update bitflags

[ltabis]

Hi,
I noticed that the bitflags dependency was out of date, so I bumped it, along with hashbrown and smallvec.

Most of the bitflags! calls seems to create internal bit flags for Rhai which aren't accessible from the public api. However, the ASTFlags is documented as accessible via the internal feature flag. Citing bitflag's 2.0 release:

If you use bitflags! types in your public API then upgrading this library may cause breakage in your downstream users.

Is this acceptable ? If not, I'll close this PR.

[schungx]

I'd hesitate to bump dependencies unless absolutely necessary, just because it may force users to bump as well, causing a cascade. The user can always bump them to the latest version...

As for version 2 of bitflags, do you know what breaking changes may be? I'd not like to break existing code unless for a good reason...

[ltabis]

The generated struct by the bitflags! macro will have fewer traits. To keep backwards compatibility, you can derive those traits using:

#[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)]

But I did not do it for every flags though, because some did not require all those traits ...

Also, the from_bits_unchecked function changed and .bits is replaced by .bits(), so if you user used those it will be breaking for them.

I'd hesitate to bump dependencies unless absolutely necessary

I don't think there are any reasons to keep this dependency up to date expect to prevent future security issues (if there are any) ... and being up to date :)

Feel free to close this or keep it, maybe bumping the depdendencies could be done once a major version of rhai goes out ? (if that is planned)

[schungx]

Actually, I also don't see any particular reason not to bump bitflags, since the flag types are all exposed under internals which is unstable anyway...

I would not bump other dependencies since the user can bump them. bitflags is a major version change so it must be bumped by us.

So if you would only bump bitflags here, I'd say it is good to go!

[ltabis]

Done, I've kept back hashbrown and smallvec. Also, just in case, I've implemented the traits quoted here for all bitflags structs to mitigate breaking changes for internal users.

[schungx]

How about using "2" instead of "2.3"?

Would lower versions cause a prob?

[ltabis]

If the authors of the crates keep following semantic versioning, yes it's no problem to use "2". However I had a few problems in personal projects where some maintainers would not bump major versions on breaking changes for specific reasons. I just took the habit of specifying specific versions because of that.

However if you want to set to "2" then I'll set to "2" :)

[schungx]

Yes I suggest setting to 2 unless there is a problematic version we'd need to avoid.

[schungx]

@ltabis Have you checked setting to "2"?

[ltabis]

Hey @schungx. Sorry for the late update, I was away for a bit. I've set hashbrown to version 2 and merge the latest commits.