prefixed_export warnings on some architectures

[DavidHorton5339]

Recent changes have marked prefixed_export! macro as deprecated, and simultaneously tried to ignore the deprecated macro option. Unfortunately this still throws up a warning which causes builds to fail. The macro is only defined/used for architectures other than aarch64, arm, x86 and x86_64, so only those architectures are affected. Example targets exhibiting the problem are powerpc-unknown-linux-gnu, mipsel-unknown-linux-gnu warning: use of deprecated macro prefixed_export: #[export_name] creates problems and we will stop doing it.

   --> src/arithmetic/montgomery.rs:136:1
    |
136 | prefixed_export! {
    | ^^^^^^^^^^^^^^^
    |
    = note: `#[warn(deprecated)]` on by default

warning: unused attribute `allow`
   --> src/arithmetic/montgomery.rs:135:1
    |
135 | #[allow(deprecated)]
    | ^^^^^^^^^^^^^^^^^^^^
    |
note: the built-in attribute `allow` will be ignored, since it's applied to the macro invocation `prefixed_export`
   --> src/arithmetic/montgomery.rs:136:1
    |
136 | prefixed_export! {
    | ^^^^^^^^^^^^^^^
    = note: `#[warn(unused_attributes)]` on by default

[briansmith]

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

[DavidHorton5339]

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

[DavidHorton5339]

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

[briansmith]

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

[DavidHorton5339]

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.

[briansmith]

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]).

[DavidHorton5339]

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?

[briansmith]

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.

[DavidHorton5339]

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

[briansmith]

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.