`#[new]` doesn't play nice with `cfg_attr`

[c410-f3r]

Compiles:

use pyo3::prelude::*;

#[pyclass]
#[derive(Debug)]
pub struct Foo {
  field: i32
}

#[pymethods]
impl Foo {
  #[new]
  pub fn new(field: i32) -> Self {
    Self { field }
  }
}

Doesn't compile with Invalid type as custom self and cannot find attribute 'new' in this scope errors:

#[cfg(feature = "with_pyo3")]
use pyo3::prelude::*;

#[cfg_attr(feature = "with_pyo3", pyclass)]
#[derive(Debug)]
pub struct Foo {
  field: i32
}

#[cfg_attr(feature = "with_pyo3", pymethods)]
impl Foo {
  // Change `#[cfg_attr(feature = "with_pyo3", new)]` for `#[new]` and `cargo build --feature with_py03` to see a successful compilation.
  #[cfg_attr(feature = "with_pyo3", new)]
  pub fn new(field: i32) -> Self {
    Self { field }
  }
}

[davidhewitt]

According to gitter this is also an issue for #[pyo3(get)] etc.

Probably needs a thorough review of cfg_attr compatibility.

[c410-f3r]

Version 0.10 worsens conditional compilation. Now #[cfg_attr(feature = "with_pyo3", pymethods)] and #[cfg_attr(feature = "with_pyo3", pyclass)] doesn't compile either.

[davidhewitt]

Thanks for the update. I'll try to give this some investigation soon.

[birkenfeld]

I can't reproduce the latest report; the example given above compiles fine with 0.10 if I make the #[new] unconditional, but the other attributes remain conditional.

It does not compile without #[new], but that has nothing to do with conditional attributes.

[birkenfeld]

I'm not sure how to resolve this. We can of course look into cfg_attr and ignore it while processing attributes, but that is only correct when the condition is as reported here, switching PyO3 off. Something like switching between two different #[new] implementations depending on flags would still fall down.

Is there a way at all to resolve cfg_attr at macro evaluation time?

[davidhewitt]

I don't know if we can "resolve" cfg_attr at macro evaluation time, but I guess we can check if the cfg_attr on the method is the same as the one on the whole pymethods block - and then if we're running the pymethods attribute macro we know that the cfg_attr must be applicable.

I suggest we start building a list of examples in this thread. For each example, we can either:

• figure out a way to support it, and add a PR and tests.
• add documentation saying why we can't support it.

My hope is that we can support "typical" use cases in this way. Or we're pleasantly surprised and find an elegant solution for everything!

@c410-f3r it would be really helpful if you could start us off by providing the new examples which you reported today as not working with 0.10.

[birkenfeld]

I don't know if we can "resolve" cfg_attr at macro evaluation time, but I guess we can check if the cfg_attr on the method is the same as the one on the whole pymethods block

Can we, though? When the pymethods macro is called its cfg_attr is already gone...

[davidhewitt]

Can we, though? When the pymethods macro is called its cfg_attr is already gone...

Oh, darn. But the other ones still present?

[programmerjake]

maybe something like the cfg_expr crate could be used to evaluate cfg() conditions? This really should be part of the proc_macro library.

[birkenfeld]

Oh, darn. But the other ones still present?

Yes, that's the problem. I quickly checked with a serde derive(Deserialize) and an inner serde attribute, and that worked. So either serde is doing some work here, or handling for derive macros is different and all attributes are resolved before the derive macro is called. (I suspect the latter.)

EDIT: confirmed, it's the latter.

@programmerjake as I understand, that's one half of the puzzle. (Already very helpful!) The other would be to get the current build config and use it evaluating these expressions. Does the proc macro have access to it?

[programmerjake]

@programmerjake as I understand, that's one half of the puzzle. (Already very helpful!) The other would be to get the current build config and use it evaluating these expressions. Does the proc macro have access to it?

I think it might through env vars from cargo.

Created thread on rust internals: https://internals.rust-lang.org/t/add-api-for-evaluating-cfg-conditions-from-proc-macros/12459?u=programmerjake

[c410-f3r]

@davidhewitt There are no errors with pymethods or pyclass because I forgot to enable the macros feature flag. I am sorry for the fuzz, should have paid more attention to the changelog.