prefixed_export warnings on some architectures about ring HOT 10 CLOSED

Hmm...why would our CI jobs pass if this happens?

from ring.

They are warnings. Does your CI treats warnings as errors (mk/cargo.sh test run from command line does not)?

from ring.

Warnings confirmed in example https://github.com/briansmith/ring/actions/runs/7492345579/job/20400988301

from ring.

I do see the warnings but they do not cause the build to break.

from ring.

Sorry, should have made it clear - it's -D warnings in our application build that's causing builds to fail. We don't really expect warnings from 3rd party crates (or our own code), and ring did not formerly issue any.

from ring.

Is there a way to get the #[allow(deprecated]) to work? If not, I will accept a PR that replaces the #[deprecated] with a comment and that removes the useless #[allow(deprecated]).

from ring.

I think the code as it is is trying to apply #[allow(deprecated)] to the function after macro expansion, rather than to the macro invocation itself. I don't know of a way of applying an attribute to a macro invocation - I doubt this is possible. The only way I could get it to work is by having #![allow(deprecated)] at the file level in montgomery.rs (and removing the useless #[allow(deprecated] on the macro invocation). Would that work for you?

from ring.

I think we're better off just replacing the #[deprecated(...)] on the definition with a comment, and then removing the #[allow(deprecated)]. I still want to get other deprecation warnings, if any, in montgomery.rs.

from ring.

Yes, that would be better than using the deprecation as a TODO marker, then masking it.

from ring.

I'm going to close this. It is annoying that we have these warnings but we don't need to have an issue to track the annoyance.

from ring.