Compile with stable rust

PyO3 requires following unstable

const_fn const fn tracking issue (RFC 911) rust-lang/rust#24111
specialization Tracking issue for specialization (RFC 1210) rust-lang/rust#31844
use_extern_macros Tracking issue for "macro naming and modularisation" (RFC #1561) rust-lang/rust#35896
proc_macro (proc_macro_attribute) Tracking issue for "macro naming and modularisation" (RFC #1561) rust-lang/rust#35896
associated_consts
~~Optional, for wrap_function!: concat_idents (Tracking issue for concat_idents rust-lang/rust#29599)~~ Solved with mashup

Doesn't proc macro work on stable rust? (or just partially) And there is proc-macro2

I think currently only proc macro for custom derive works on stable Rust, proc_macro_attribute don't.

proc_macro_attribute is unstable, info is in linked tracking issue.

Can this trick be used instead of proc_macro_attribute ?

no, it is not. pyo3 strictly requires proc_macro_attribute, because it requires access to token stream of impl sections.

no, it is not. pyo3 strictly requires proc_macro_attribute, because it requires access to token stream of impl sections.

I think this is exactly what it does, i.e. given the example:

#[macro_use] extern crate procedural_masquerade;
extern crate proc_macro;

define_proc_macros! {
    #[allow(non_snake_case)]
    pub fn foo_internal__stringify_const(input: &str) -> String {
        format!("const STRINGIFIED: &'static str = {:?};", input)
    }
}

The foo_internal__stringify_const function receives original code and returns generated code. You get a token stream using syn crate as with macros 1.1.

And all this works by wrapping a body of the macro into a type definition to leverage macros 1.1, to get a token stream.

The only difference is that:

#[mod2init]
fn init_function() {
}

Would be written as:

mod2init! {
  fn init_function() {
  }
}

I see. But that would be quite large task, I don’t think I can spend any time on it. Also there is specialization, I am not sure if it possible to avoid it

If you want to work on this task I can give you permission to repo

this features are stable now, const_unsafe_cell_new, const_size_of, const_ptr_null, const_ptr_null_mut

Stabilization of TryFrom has been reverted rust-lang/rust#50121

pyo3 does not use TryFrom

pyo3/src/objects/mod.rs

Line 183 in 9dc7661

    
           impl<'source> $crate::std::convert::TryFrom<&'source $crate::PyObjectRef> for $t

The macro pyobject_extract! uses TryFrom. To use PyO3 in stable rust, this library itself must be compiled with stable rustc.
IMHO, there is no merit to use this unstable feature, and should be dropped.

Feature gate try_from

@termoshtt

@termoshtt Good catch! pyo3 implements TryFrom, even though it currently uses PyTryFrom instead. I put a feature gate onto the implementation of TryFrom and removed the try_from feature. Once TryFrom becomes stable, we can than replace PyTryFrom.

Drop of fn_must_use in afcc87e causes many warnings

warning: `#[must_use]` on methods is experimental (see issue #43302)
   --> src/typeob.rs:154:5
    |
154 |     #[must_use]
    |     ^^^^^^^^^^^
    |
    = help: add #![feature(fn_must_use)] to the crate attributes to enable

Progress slowly continues; we want to get there but need more volunteer time to get this over the finish line yet. (pyo3 maintainer time in the last few months has been spent mostly on soundness problems as well as bugfixes, which are also very important.)

Last items to resolve are in #697. I can offer mentoring advice to anyone interested in helping out with pieces of the solution in there.

@jcdyer

@jcdyer The emphasis is on easy interoperability, not just any interoperability, which is the purpose of PyO3. That being said, I did pitch rust to my coworkers, and got enough leeway to experiment with it in a side project - because I realized that nightly wasn't as bad as it sounded.

That being said, I work in a research lab not an enterprise company and our risk tolerance for these sorts of things is significantly higher, so continuing to focus on using stable would be a big selling point for the language overall. Glad to see how active this community is - it says a lot about the language and ecosystem :)

we want to get there but need more volunteer time to get this over the finish line yet

Yeah, I also think it's a matter of time.
Now I have a serious NeurIPS deadline. Please wait for a bit.

Hello. It appears to me, from reading #210, that specialisisation is mostly used to implement class declaration. So how hard would it be to introducing a feature no-unstable-class-support to pyo3 that simply switches off class declaration, but allows code to be compiled on stable rust? People that want to use pyo3 instead of rust-cpython and can live without classes could then do so without having to use unstable.

Once specialisation is stable or pyo3 managed to get rid of it, class declaration would be allowed in no-unstable-class-support and the feature would become identical to the default configuration again. I think this would also be very much in line on how rustc itself adds new features.

An alternative would be the other way around: Make no-unstable-class-support the default and introduce a feature allow-unstable-class-support.

if we're going to use a cargo feature, we should use the enable unstable code feature rather than the disable version, since cargo features should be additive since that's how cargo's designed.

as an example, if one crate uses the unstable code and another one doesn't, then using the enable version of the feature would correctly deduce that unstable code should be enabled for the crate that requires it. if it was the disable version then cargo would incorrectly disable the unstable code even though a crate requires it, leading to compile failure.

If anything requires unstable code, then you need to use the unstable compiler on all the crates anyway in order to have the compiler versions match, so that's not a limitation.

Make sense. The reason I thought it up the other way round is, that it might make things appear from the documentation, but one should be able to work around this.

Hi. I don't know a lot about Rust, but trying to run an application I use often that recently introduced bits of rust.
Why can't PyO3 work with Rust 1.43.1, released last week? My OS ships stable rust. This ticket is 3 years old now, this is annoying.

Read comments above, work is ongoing to fix this but it takes time...

@sinetek The answer to the question you asked is in the thread above.

If you would like to get it working, the recommended way to work with rust as a developer is to use rustup to manage your rust toolchains, so you can have nightly and stable running side by side. You can get rustup from https://rustup.rs.

Then run the following:

rustup toolchain install nightly
rustup default nightly

Then when you want do run on stable, you can switch back with rustup default stable. You can also set per-directory overrides with rustup override. Run rustup override --help for details.

You can find more detail here: https://github.com/rust-lang/rustup#working-with-nightly-rust

@kngwyu

For all those following this thread... the current PyO3 master branch just had a PR merged which added support for stable Rust.

Extra special thanks to @kngwyu and @konstin who have been working to remove specialization from PyO3 for a long time - and as of this morning, we finally got there! 🎉 🚀 🐍 🦀

Cheers!

…

On Sun, Jun 21, 2020, 10:06 David Hewitt ***@***.***> wrote: For all those following this thread... the current PyO3 master branch just had a PR merged which added support for stable Rust. Extra special thanks to @kngwyu <https://github.com/kngwyu> and @konstin <https://github.com/konstin> who have been working to remove specialization from PyO3 for a long time - and as of this morning, we finally got there! 🎉 🚀 🐍 🦀 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFPQGZCMZPNWNYAXGESIS3DRXW5RBANCNFSM4DMCSS4Q> .

That's awesome progress you've been making this past 6 months! Huge congratulations on all your efforts.

excitement intensifies

congrats!

Navigation Menu

Repository navigation

Compile with stable rust #5

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Compile with stable rust #5

Description

Activity

tailhook commented on Jul 26, 2017

messense commented on Jul 26, 2017

fafhrd91 commented on Jul 26, 2017

tailhook commented on Dec 2, 2017

fafhrd91 commented on Dec 2, 2017

tailhook commented on Dec 2, 2017

fafhrd91 commented on Dec 2, 2017

fafhrd91 commented on Feb 15, 2018

termoshtt commented on May 3, 2018

fafhrd91 commented on May 3, 2018

termoshtt commented on May 4, 2018

konstin commented on May 5, 2018

termoshtt commented on May 13, 2018

13 remaining items

davidhewitt commented on Apr 22, 2020

TheButlah commented on Apr 23, 2020

kngwyu commented on Apr 24, 2020

nacaclanga commented on Apr 29, 2020

programmerjake commented on Apr 29, 2020

nacaclanga commented on Apr 29, 2020

philmb3487 commented on May 15, 2020

davidhewitt commented on May 15, 2020

jcdyer commented on May 15, 2020

davidhewitt commented on Jun 21, 2020

ikamensh commented on Jun 21, 2020

gilescope commented on Jun 22, 2020

TheButlah commented on Jun 22, 2020

fafhrd91 commented on Jun 22, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions