node: Fix mask-or operator precedence by replacing + with |

[MarijnS95]

Fixes #209, CC @jbeich

A request for using masks and shifts on the known 0-1-2 constants defining the minor type of a DRM node resulted in the expression to maintain the original + from first subtracting the current node type followed by adding the requested node type. As the subtract of the current node type was replaced by a mask, the resulting old_id & ID_MASK + minor_base expression is interpreted as old_id & (ID_MASK + minor_base) because of operator precedence, while it would have been correctly interpreted as (old_id & ID_MASK) | minor_base when the correct | OR operator is used.

[MarijnS95]

CI says:

error: package fdeflate v0.3.6 cannot be built because it requires rustc 1.67.0 or newer, while the currently active rustc version is 1.66.0

Should we bump MSRV, lock fdeflate to an older version, downgrade fdeflate in CI like we already do for home or run the MSRV tests with cargo +nightly -Zminimal-versions generate-lockfile? I prefer the last one because that's what I do in many other crates. It not only exercises -Zminimal-versions which downstream crates/consumers may also be running, but also prevents this error from showing up in the future if any other crate bumps their MSRV beyond our rust-version in a patch release.

[Drakulix]

[...] or run the MSRV tests with cargo -nightly -Zminimal-versions generate-lockfile?

I think we do want to test against the newest available and compiler supported version though. We have a separate minimal test...

[MarijnS95]

I think we do want to test against the newest available and compiler supported version though. We have a separate minimal test...

Specifically, you want to check MSRV against the latest crate dependencies? That means we'll always be at the merit of our (transitive) dependencies bumping MSRV, and our CI subsequently failing on random PRs.

I'd prefer to combine the MSRV test with the minimal-versions test to keep overhead low. Right now the existing cargo check runs on nightly as well, the suggested change generates the lockfile on nightly while running check on the MSRV compiler (and we could also check it on the stable compiler).

[MarijnS95]

Note that that's what I did in #212, and we should probably continue this discussion there. Alternatively, we perhaps can and should exclude our examples / dev-dependencies from the MSRV build?

[MarijnS95]

@Drakulix I've also included all CI fixes in this one PR (the oldest) so that it can hopefully all go in using rebase-merge while the CI is green/happy with the final result :)

[Drakulix]

LGTM, thanks!