In #1482, we relaxed zerocopy-derive's MSRV policy, which led to the issue that, when testing on the MSRV toolchain, a version of syn was chosen with a higher MSRV than ours. In order to work around that issue, we added the following in CI:
|
# Ensure that Cargo resolves the minimum possible syn version so that if we |
|
# accidentally make a change which depends upon features added in more |
|
# recent versions of syn, we'll catch it in CI. |
|
- name: Pin syn dependency |
|
run: | |
|
set -eo pipefail |
|
# Override the exising `syn` dependency with one which requires an exact |
|
# version. |
|
cargo add -p zerocopy-derive 'syn@=2.0.46' |
We later decided that there was a better workaround. In #1564, we removed that CI step.
Now, in #1586, we are seeing the same issue again - syn is resolved to a version whose MSRV is higher than ours - but this time only in the newly-introduced zerocopy-target-has-atomics toolchain.
For now, I've decided to work around this by re-introducing the above-mentioned CI step. Eventually, we should more thoroughly debug why #1564 didn't fully resolve the issue.
NOTE: If we decide we want to remove this, we need to consider whether the original justification no longer holds: namely, whether we still need this step in order to ensure that we're not accidentally relying on more recent syn features despite our dependency in zerocopy-derive/Cargo.toml being for a lower version. cc #305
In #1482, we relaxed zerocopy-derive's MSRV policy, which led to the issue that, when testing on the MSRV toolchain, a version of syn was chosen with a higher MSRV than ours. In order to work around that issue, we added the following in CI:
zerocopy/.github/workflows/ci.yml
Lines 123 to 131 in 9e59a1a
We later decided that there was a better workaround. In #1564, we removed that CI step.
Now, in #1586, we are seeing the same issue again - syn is resolved to a version whose MSRV is higher than ours - but this time only in the newly-introduced
zerocopy-target-has-atomicstoolchain.For now, I've decided to work around this by re-introducing the above-mentioned CI step. Eventually, we should more thoroughly debug why #1564 didn't fully resolve the issue.
NOTE: If we decide we want to remove this, we need to consider whether the original justification no longer holds: namely, whether we still need this step in order to ensure that we're not accidentally relying on more recent syn features despite our dependency in
zerocopy-derive/Cargo.tomlbeing for a lower version. cc #305