-
Notifications
You must be signed in to change notification settings - Fork 5k
Fix build break on linux-armel #115767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix build break on linux-armel #115767
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.
- Adds void casts for
hasSeed
andhasSecretKey
inCryptoNative_MLDsaGetPalId
.
|
Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones |
src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c
Outdated
Show resolved
Hide resolved
…ey_ml_dsa.c Co-authored-by: Kevin Jones <[email protected]>
The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including runtime/eng/pipelines/common/evaluate-default-paths.yml Lines 84 to 90 in 6d3b842
It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction. |
That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/. The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run. And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere". |
I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs. I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR. |
Yeah, that's why I walked it back to saying my interest is about "build", not "test".
I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).
I agree. |
Part of this is that the coreclr subset includes
Agreed |
No description provided.