RFC: Multi-Type Return Position Impl Trait (MTRPIT)

Summary
This RFC enables Return Position Impl Trait (RPIT) to work in functions which return more than one type:
// possible already
fn single_iter() -> impl Iterator<Item = i32> {
    1..10 // `std::ops::Range<i32>`
}

// enabled by this RFC
fn multi_iter(x: i32) -> impl Iterator<Item = i32> {
    match x {
        0 => 1..10,                   // `std::ops::Range<i32>`
        _ => vec![5, 10].into_iter(), // `std::vec::IntoIter<i32>`
    }
}

Rendered

I would prefer an explicit syntax, such as enum impl Trait, as I think doing it implicitly could become a performance footgun.

Language-level support for delegation/proxies

I'd much rather see this alternative implemented first. Delegation is the number one language-level complaint I have personally.
The lack of delegation is also a missing piece of the puzzle when I am training people who are familiar with classical inheritance-based OOP. Many of these people use inheritance to achieve code reuse[^1] and ask how they can achieve similar benefits when transitioning to Rust. I have to shrug and vaguely wave my hand towards non-ideal code generation techniques and say "someday I hope Rust gets delegation".
Since the delegation functionality appears to be a prerequisite for the implementation of this RFC, it seems to me that the difference in effort would be the user-level syntax that exposes delegation. I'd propose following that thread first and then seeing how much of this RFC is needed — maybe everyone is happy with delegation + the remaining hand-created implementation and this RFC isn't needed, or perhaps a pattern emerges in the ecosystem that would improve or replace what this RFC proposes.
[^1]: For better or worse — I have my opinions but this is off topic.

This seems to be related to 2414, which I didn't see mentioned after a small cursory glance at this RFC.
I'm very much in favor of this. It is a substantial quality of life improvement: I have run across multiple use cases for this feature and it just seems like something that should "just work", i.e. the compiler can automate for me, instead of having to manually declare one-use enums or having to work with/around the shortcomings of the auto-enums crate.
I would strongly advocate for an x() -> enum impl MyTrait syntax because I do think that it should be clear what the compiler is doing for us. Clarity of code abstractions is, after all, a major priority of the Rust language.

As @Mark-Simulacrum points out, not all traits can have a multi-type delegating implementation synthesized. The set of traits where this implementation can be synthesized is almost exactly one that already exists -- dyn-safe traits! Multi-type impl trait is type erasure fundamentally related to dyn Trait; anything that can be put into a vtable can just as easily be dispatched statically via enum.
I'd like to see the RFC place more emphasis on how this acts as a statically dispatched alternative to dyn Trait, rather than a more capable impl Trait. Because of the object safety concerns and type erasure involved, multi-type impl trait is imho much closer to dyn Trait than impl Trait, which is a singular opaque type and keeps all of the fun non-object safe functionality like receiverless associated functions, types, and constants.
There are of course still some differences; multi-type impl trait produces a Sized type compatible with where Self: Sized like those on Iterator returning Wrapper<Self>, and the enum_dispatch crate demonstrates how static enum dispatch is often significantly faster than dyn dispatch.
Being a "sized dyn Trait" isn't a fully correct specification either, though. A trait remains object-safe when defining associated functions without a receiver if that function is bound by Self: Sized, since the dyn Trait object is ?Sized and doesn't have that associated function. Like with dyn Trait, MVRPIT can't provide a definition of receiverless functions. Similarly, traits with associated types bound by Self: Sized remain object safe (but can't be used), and it's possible that associated const could be treated similarly in the future.
Making an object-safe trait no longer object-safe in an update is already currently a subtle pitfall that's easy to miss if a trait wasn't originally designed to be used as a trait object. Complicating the dyn safety rules to introduce MVRPIT seems unwise.

The RFC talks about not having a syntax for anonymous enums in general, but we have one: type alias impl trait (TAIT), i.e. type T = impl Trait. This can be thought of like a return-position impl trait that is captured and usable in other contexts.
Except, this opens up a load more questions. Likely, it would destroy inference and make it impossible to easily have a "defining usage" for TAIT, since conflicts could just be programming errors, or a genuine request for an enum type.
Honestly, this feels like a good indicator that this should at minimum be opt-in, but I'm not sure otherwise. But definitely, interoperability with TAIT is a must.

One major discussion point from #2414 that seems missing here was around a desugaring to something that resembles InlineBox<dyn Trait, /* compiler generated max size of all possible options */>, explicitly using dynamic dispatch with the value stored inline rather than enum based dispatch. I seem to recall some benchmarking of that was performed, but after a quick skimming of the issue again I couldn't find it. (There was also significant discussion of what features would be required of a delegation feature to support this usecase).

The set of traits where this implementation can be synthesized is almost exactly one that already exists -- dyn-safe traits!

One major difference is fns with type parameters, which always block dyn safety, but pose no major obstacle to synthesizability except perhaps in some cases where the Self type gets involved.

How does this RFC interact with unsafe traits?
For example: bytemuck::Pod requires that the type can hold any bit pattern, which an enum wouldn't satisfy.

another thing to consider:
what happens when a trait has a blanket implementation such that generating a delegating implementation of the trait for the generated enum would conflict with the blanket implementation?
pub trait Blanket {
    fn f(&self) {
        println!("called on {}", type_name::<Self>());
    }
}

pub trait Tr: Blanket {
    fn g(&self) {}
}

impl<T: Tr> Blanket for T {}

pub fn f(a: impl Tr, b: impl Tr, c: bool) -> impl Tr {
    if c { a } else { b }
}

impl Tr for () {}
impl Tr for &'_ () {}

pub fn g(c: bool) {
    // what does this print?
    f((), &(), c).f();
}

Any idea what enum_dispatch lacks or requires rustc help?  Are they handling where Self: Sized bounds nicely?  A reasonable approach here would be:
fn multi_iter(x: i32) -> #[enum_dispatch] impl Iterator<Item = i32>

The main limitation of enum_dispatch is that it requires annotating the trait definition site as well as the usage, so that it knows what the trait definition is. There's nothing preventing combining enum_dispatch with the auto-enums approach, so long as enum_dispatch supports dispatching to generic types. If it doesn't, adding in some TAIT can be used to give names to the inferred types.
But also, as a fundamental limitation of procedural macros, enum_dispatch does not have type information. It quite literally cheats in order to know both the trait definition and the delegation set at the same time. Because of this cheating, it's incapable of handling multiple traits with the same name, and trying to use enum_dispatch for a trait defined upstream may or may not work, depending on how the compiler happens to use the proc macro server and whether this is a clean compile or not. I much prefer [ambassador]'s approach to hooking up delegation, if you couldn't tell.
Because type information is unknown, any procedural macro implementation (whether auto-enums, enum_dispatch, ambassador, or some other crate) requires either developer assistance to identify the set of types to dispatch to or to conservatively generate a separate enum case for every possible return path in a function. The compiler has type information, and can consolidate multiple instances of the same type into a single enum arm, and potentially even when layering MTRPIT, depending on what the runtime type downcasting semantics are.

ambassador should be added to prior art as well. It just does the delegation part, but it does so for arbitrary traits (which you must annotate directly or via facsimile), unlike auto-enums.

Downcasting brings up an important point: how do we handle stability?
For Iterator, implementing unstable-to-implement methods can impact performance of stable-to-call methods (e.g. try_fold is unstable to implement because of using Try), especially for std types which can just implement the root method everything else is implemented in terms of.
For Error, on the other hand, Error::type_id is unstable because it is unsound to implement except with the default body. This case is I believe saved by the proposed rule of only delegating a defaulted method if any of the delegatees have an implementation for it, but I don't recall if any other std traits are relying on any such tricks.
The safe answer is probably to say that items only get delegated if the delegating implementation can actually be written in the crate doing the delegation. Actually defining the preconditions, taking into mind even such things as unnameable types, which some crates do rely on[^1] to make things unimplementable outside of their crate, seems extremely difficult.
[^1]: Thankfully, I only know of cases which use unnamable types to make semver-exempt public-for-impl-reasons APIs more difficult to use. I can't shake the feeling I've seen a case of relying on an unnamable type being unnamable for soundness, though...
I also don't recall any mention of unsafe traits. The compiler cannot guarantee a delegating implementation is sound; thus delegation of an unsafe trait MUST NOT be done automatically without the unsafe trait opting in.

Some more edge cases I haven't seen mentioned yet:

If the trait puts any interesting bounds on Self (e.g. supertrait bounds), those also have to be delegated.
To that point, sealed traits. Commonly implemented by an unnamable supertrait, but also via required functions which name unnamable types. A simple example of a trait where individual types can be returned as impl Trait but can't be combined into an enum implementing the trait.
If the trait has associated types, it's somewhat unclear if iteratively generating more anonymous dispatch enums is even guaranteed to finish in a finite number of steps. It certainly means that
Returning Wrapper<Self::AssociatedType> can't be delegated if the associated type isn't constrained to be a singular type.

The more I consider it, the more I end up convinced that multi-type impl Trait has severe fundamental limitations not present for single-type impl Trait that just can't be papered over. None of them are immediately obvious when considering the idea; dyn Trait works, after all. But nearly every other corner I examine, there's a corner case which presents issues for synthesizing delegation implementations.
A fundamental motivation of the RFC as written is that Box<dyn Trait> does not necessarily itself implement Trait, it merely provides access to the type-erased object which implements Trait. But that very limitation can and is relied upon; that a crate knows the complete set of types that implements its trait. You can argue that traits where a new implementation showing up would be unsound should be unsafe, but even std[^1] defines safe traits where a downstream impl is unsound.
[^1]: In std's defense, a) essentially all of the examples are from early Rust before unsafe trait with fully safe API was properly understood, b) most examples gate the ability to write unsound impls behind unstability, essentially pretending the unsound parts don't exist, and c) std is uniquely allowed to rely on compiler/language implementation details in ways user code isn't supposed to.
Either this feature will have the same interface semantics of dyn* Trait or it will need to define a new set of constraints for what traits are mtrpit-safe. This should probably be defined positively, as a list of things mtrpit-safe traits are allowed to do, rather than rule out any problematic cases. It's as of yet unclear whether this will result in a different API for the caller than impl Trait, assuming Trait is mtrpit-safe. But it will necessarily restrict what traits can be used, so it's never going to be as simple as "now you can use multiple types in RPIT."

The more I consider it, the more I end up convinced that multi-type impl Trait has severe fundamental limitations not present for single-type impl Trait that just can't be papered over. None of them are immediately obvious when considering the idea; dyn Trait works, after all. But nearly every other corner I examine, there's a corner case which presents issues for synthesizing delegation implementations.

Yeah, I completely agree. I do believe the limitations are coherent enough that we can create a framework to handle them. But the starting point of this RFC was from a place where I (incorrectly) assumed these limitations might be at most minor; enough so that -> impl Trait returning more than one type would work almost identical to the way it does today.
That's clearly proving not to be true. unsafe Trait, fn () -> Self (Default), supertraits, associated constants, and delegation itself require some careful design considerations. Nothing that I think we can't overcome. But I am unsure whether the scope of this RFC is now big enough that it may not align with the lang team's priorities. And I'm also unsure whether I can commit the time required at this point to see this through to completion.

I think #2884 sounds more useful and largely subsumes this.  If enums provide some speedup over indirection then people could use enum_dispatch more or similar.

@yoshuawuyts With my lang hat on: I don't object to an approach like this, if the corner cases were addressed (through support or through documentation of non-support). But I would definitely want it to use a different syntax than -> impl Trait, to flag the use of static multi-type dispatch like this. (I can also imagine giving the compiler the freedom to decide based on various factors whether to use an enum or some manner of dyn*.)
I don't know offhand whether this or some other approach would be best. @nikomatsakis, thoughts here, with respect to dyn* or otherwise?

@burdges simply because the optimizer is typically better able to optimize a call to a known function than a call to an unknown function. If doing static dispatch to #[inline(never)] functions, the difference should be essentially zero. Compilers are also getting better at "devirtualization," slowly bringing the gap closer and down to perhaps just down to the extra Box allocation/indirection that often comes with dynamic dispatch.

I would prefer an explicit syntax, such as enum impl Trait, as I think doing it implicitly could become a performance footgun.

Personally I agree with the need for explicitness, but disagree with the semantic implication of the position. If the user is getting a hidden enum, or a dyn type, or all those details should be hidden, it's an implementation detail. Instead I'd specify it inside the function, so something like return enum data. It means that we explicitly have to define return enum inside all cases, but this helps make it clear why this works
foo(x:bool) -> impl Bar {
    match x {
        true => TrueBar{x:5},
        false=> FalseBar{Default::default..},
    }
}

But this wouldn't:
foo(x:bool) -> impl Bar {
    let result = match x {
        true => TrueBar{x:5},
        false=> FalseBar{Default::default..},
    }
    return result;
}

Instead we'd have to write
foo(x:bool) -> impl Bar {
    match x {
        true => return enum TrueBar{x:5},
        false=> return enum FalseBar{Default::default..},
    }
}

And it becomes clear why this is a special thing related to the function, not to the expression itself.

Just for the record, I prefer if we had just impl Trait instead of enum dyn Trait. I don't think that a branch warrants a second warning keyword, and it would just end up being noise. I agree that for the case of dyn Trait having the dyn keyword serves as a useful warning for dynamic vtable lookups, but even in that case I'd consider its importance to be arguable.
If the implementation required an allocation or a dynamic lookup I'd agree, but it only involves a branch. Having two performance warnings for enum dispatch while having one for dynamic dispatch seems backwards to me. Specially considering enum dispatch can be inlined while dynamic dispatch cannot.

As discussed above, we've delegation trouble so this needs rules more closely resembling dyn Trait, not really like impl Trait.
An impl Trait form becomes something nobody likes:
fn multi_iter(x: i32) -> impl Deref<Target=impl Trait>+DerefMut

Having two performance warnings for enum dispatch while having one for dynamic dispatch seems backwards to me.

If that's the main objection, there's an easy counteroffer: -> enum Trait.
I want to make it clear though that at least my objection to using unadorned -> impl Trait for hidden enum trait dispatch has nothing to do with any hidden performance costs. The objection is purely from the fact that introducing enum trait dispatch brings along extra restrictions not present with -> impl Trait.
If the restrictions are exclusively on what traits can be used and has no visible impact on the caller, then a signature of -> impl Trait is accurate and fine. If there are semantic implications and/or restrictions on the caller[^0], on the other hand, then a different syntax should be used.
[^0]: The fact that a fresh type is returned instead of the underlying type certainly has the potential to have semantic impact. Doing so is potentially desirable even for a single type, and I'm fond of using the compiler's knowledge of MTRPIT to flatten the enum dispatch when nested, but that's certainly quite likely to be semantically observable and invalid to do without specific -> enum Trait semantics different from -> impl Trait allowing it.

If the implementation required an allocation or a dynamic lookup I'd agree, but it only involves a branch.

"Just a branch" undersells it a bit. If we do decide to restrict MTRPIT enum to just being an optimization over -> dyn* Trait[^1], then it's accurate by definition. But at least as specified MTRPIT wants to allow significantly more, and those are more places for costs to sneak in[^3]. Plus, we're entirely ignoring monomorphization cost, as well as the ability of the compiler to devirtualize dyn Trait[^2].
[^1]: This is the experimental syntax being used by the dyn async initiative, and corresponds to the idea of returning an opaque owned dyn Trait object independent of how ownership is actually handled.
[^2]: If you return a Box<dyn Trait> but the concrete type is knowable (e.g. via inlining), compilers are quite eager to turn the indirect call into a direct call and continue optimizing with that. This is not surprisingly motivated in significant part by OOP design encouraging exactly that, whether via encapsulation behind an interface or leaving virtual members open rather than final.
[^3]: The obvious is if associated types aren't set and are recursively turned into enum dispatch themselves, each one also has dispatch overhead, as well as that creating dyn Trait from it will cause two levels of dispatch. More subtle are the inhibiting of specialization and defaulted methods potentially going through dispatch multiple times (though that one should in theory be a fairly simple loop invariant code motion optimization to eliminate).
Personally, I think MTRPIT needs to wait for the outcome of the dyn* experiment; the use case is essentially the same, just monomorphic instead of polymorphic. Depending on where dyn* ends up, the analogous syntax of impl* may potentially be appropriate.

An interesting observation can be made: I think the set of traits which can be allowed with enum dispatch/delegation is equal to the set of traits that "should" be implemented for !, the canonical memberless enum (uninhabited type). Automatically synthesizing trait implementations for ! is unfortunately probably impossible, but if an opt in is required, it could apply both to enable enum delegation and !'s implementation simultaneously. (Perhaps also impls for Box<dyn Trait>, dyn* Trait, or even &[mut] dyn Trait? Lots of potential to explore.)

This "MTRPIT" can also be applied to variables.
let future: impl Future<Output=()>
= if x {
   async {} // `{{async0}}`
 }
else {
   async {} // `{{async1}}`
 }

If that's the main objection, there's an easy counteroffer: -> enum Trait.

That is something I'd be down for.

The objection is purely from the fact that introducing enum trait dispatch brings along extra restrictions not present with -> impl Trait.
I see, I had misunderstood the purpose for the separate syntax.

What I don't understand, is why do const items and associated functions cause so much trouble. They are completely inaccessible. I could imagine someone try to access them using TAIT and universal function call syntax, but that doesn't seem like something difficult to prevent. I'd just leave const items uninitialized and associated functions unimplemented!.

What I don't understand, is why do const items and associated functions cause so much trouble. They are completely inaccessible.

Accessing associated constants and functions is as easy as passing an impl Trait return value to a function like this:
const fn get_const<T: WithConst>(_: &T) -> u8 {
    T::CONST
}

full demonstration

I would prefer an explicit syntax, such as enum impl Trait, as I think doing it implicitly could become a performance footgun.

I don't think it would have a performance impact, though it may be nice to let people know that you're possibly returning different types that are promised to all have the same methods.

@shepmaster, what is delegation/proxying and how is it better than this solution?

Honestly, this feels like a good indicator that this should at minimum be opt-in, but I'm not sure otherwise. But definitely, interoperability with TAIT is a must.

@clarfonthey, this has been discussed in the form of enum impl Trait syntax. I think this is a reasonable compromise, and since it's opt-in, while it's still under development, it could be more or less tweaked to squeeze around some of the issues mentioned.

A delegation solution would broaden the #[derive(Trait)] toolbox in various ways, which sounds much more powerful, but also much more complex.
It's fairly clear enum Trait winds up morally more a flavor of dyn Trait than a flavor of impl Trait.   As noted above, enum Trait: Trait is false, just like dyn Trait: Trait is false.  It follows enum impl Trait should not be the syntax here.
dyn Trait is a type because it's always instantiated the same.  enum Trait is not always instantiated the same.  enum Trait could seemingly be a trait however, roughly like FnOnce, FnMut, and Fn, so then -> impl enum Trait makes sense.
Amusingly dyn Trait: enum Trait so enum Trait maybe useful more broadly, like in delegation.  I think fn() -> Box<impl enum Trait> could return Box<dyn Trait> under the hood even.
We produce dyn Traits via casts as Pointer<dyn Trait> because this only requite changing pointer metadata.  We do not want this for enum Trait so yeah one likely wants some keyword the constructs the concrete type of the enum.  It's unclear if this should happen at the merger site or if maybe the compiler should infer all the variants more cleverly, ala
let mut it = enum it;
if backward { it = enum if.rev(); }
// loop { ... it = it.map(|x| ...) ...}  // error, cannot instantiate enum variants

All this said, we'd maybe benefit more from dyn Trait being optimized better under the hood, but I'm unsure if I understood this whole discussion up thread.

what is delegation/proxying and how is it better than this solution?

@CalinZBaenen Wikipedia defines delegation and proxying as well as the related forwarding better than I will in a comment.
As I understand it, this RFC effectively proposes creating delegation as a compiler implementation detail and limited to enums. However, the concept of delegation can be useful for cases beyond that. As a few made up examples without much thought put to it...

I want to write an iterator adapter that counts how many times Iterator::next was called. A naïve implementation would forget to delegate Iterator::size_hint, degrading performance.
I want to combine a Foo (which implements FooTrait and a Bar (which implements BarTrait) into a Pair type and implement both FooTrait and BarTrait by calling the corresponding methods on Pair's member fields.

Around this, where should the variant go?

@burdges, I don't quite understand the question.
I think we may be thinking about this feature with different mindsets. (F.ex. what is "the variant"?)

Yes exactly, dyn Trait could simply be optimize for expected vtables, especially with https://github.com/rust-lang/rfcs/pull/2884, so then zero new syntax, just -> dyn Trait runs faster sometimes.

But wouldn't dyn Trait still be dynamic dispatch and not static-dispatch.
Or would one of the "optimizations" be to make it static? (At that point I wouldn't call it just an optimization.)

Yes exactly,

What are you agreeing to?

It follows -> enum impl Trait should not be the syntax here.

Also, how did you come to this conclusion?

@clarfonthey

There's also all the work on dyn* Trait as well which might eliminate the need for this in a lot of cases.

Not necessarily.
Apparently, according to this post, only types that are pointer sized or less can make use of dyn*, which could be "a lot" of cases, but it also equally leaves "a lot" of cases unaccounted for.
Also the size of a pointer, size_of::<usize>() varies depending on the architecture of your target, so that may make its usability unpredictable if you want to compile for all sorts of targets.
This would use an enum-like structure which would (seemingly) have no such limitation (except for ones that may already be imposed my the max size of an enum).

But definitely, interoperability with TAIT is a must.

I feel like this would have to inherently exist.
Sure, I don't believe a typealias can alias all types (unless it can), but I do believe if a typealias can alias a "normal" impl T it can also alias an {enum impl T}.

Except, this opens up a load more questions. Likely, it would destroy inference and make it impossible to easily have a "defining usage" for TAIT, since conflicts could just be programming errors, or a genuine request for an enum type.
Honestly, this feels like a good indicator that this should at minimum be opt-in,

I don't know about you, or anyone participating in this RFC (now or in the future), but I'm pretty set on enum impl Trait or impl enum Trait, it's concise, pretty much gets to the point, and is opt-in. Perfect.

I'd like to present my avocation for this feature.
Whether dyn* Trait works out well or not, I believe this still deserves a spot in Rust.
This is my very detailed response about why I believe this feature is good.
Any questions may be asked in the comments there or here (in reply to me by @ing).

@CalinZBaenen I'd like to point out that returning Self is perfectly fine and should be allowed for the cases where the method also has a parameter which can be used to deduce which type is meant.
so, impl enum Clone is perfectly valid since fn clone has a &self parameter so we know the Self type must match the passed-in Self.
pub trait ImplEnumIsValid: Clone {
    fn clone2(v: &Self) -> Self; // note parameters don't have to be `self` to work

    // impl enum would have to ensure the two Self's match
    fn foo(a: &Self, b: &mut Option<&Self>) -> Result<Self, ()>;

    // also works since `which` would become an enum with `PhantomData` fields,
    // the discriminant allows determining which `Self` type to use
    fn bar(which: PhantomData<Self>) -> Self;
}

@programmerjake

so that implies enum impl Trait is a more correct way to spell it than impl enum Trait...

I mean, we got the "roughdraft" name down, one of the two orderings of impl enum ... or enum impl ..., bikeshedding can be done more once we're closer to this RFC coming to fruition.

so, impl enum Clone is perfectly valid since fn clone has a &self parameter so we know the Self type must match the passed-in Self.

But how do we initially resolve the type for Self?
We'd need to essentially know the type the call will return before the function is called, which seems impossible. (Do you have any ideas around this?)

this case is an actually pretty interesting extension imho, which's type would have to become something like enum PhantomData<impl Trait>,

Howcome?

so that implies enum impl Trait is a more correct way to spell it than impl enum Trait...

How is that implied by the previous statement?

Also, the DEV post has been updated.
I have now posted a comment with theoretical output code for one of the testcases I had provided, originating from this Discord message.

so, impl enum Clone is perfectly valid since fn clone has a &self parameter so we know the Self type must match the passed-in Self.

But how do we initially resolve the type for Self? We'd need to essentially know the type the call will return before the function is called, which seems impossible. (Do you have any ideas around this?)

yes, simply use the exact same type as self:
fn f(v: bool) -> enum impl Clone {
    #[derive(Clone)]
    struct A(String);
    if v {
        A(String::from("blah"))
    } else {
        42i32
    }
}

becomes:
fn f(v: bool) -> impl Clone { // not always just `impl Trait`
    #[derive(Clone)]
    struct A(String);
    enum Ret {
        A(A),
        I32(i32),
    }
    impl Clone for Ret {
        fn clone(&self) -> Self {
            // here's how we determine which clone() to call:
            match self {
                Self::A(v) => Self::A(A::clone(v)),
                Self::I32(v) => Self::I32(i32::clone(v)),
            }
        }
    }
    if v {
        Ret::A(A(String::from("blah")))
    } else {
        Ret::I32(42i32)
    }
}

this case is an actually pretty interesting extension imho, which's type would have to become something like enum PhantomData<impl Trait>,

How come?

Because the value doesn't actually contain any impl Trait values, instead the type after enum is just an arbitrary fully-general type with an impl Trait inserted in it somewhere. Nevertheless, the enum dispatch still works fine:
pub trait MyTrait {
    fn bar(which: PhantomData<Self>) -> Self;
}

pub fn foo<T: MyTrait>(use_t: bool) -> enum PhantomData<impl MyTrait> {
    struct Fallback;
    impl MyTrait for Fallback {
        fn bar(which: PhantomData<Self>) -> Self {
            println!("Fallback::bar");
            Fallback
        }
    }
    if use_t {
        PhantomData::<T>
    } else {
        PhantomData::<Fallback>
    }
}

becomes:
pub trait MyTrait {
    fn bar(which: PhantomData<Self>) -> Self;
}

struct Fallback;

impl MyTrait for Fallback {
    fn bar(which: PhantomData<Self>) -> Self {
        println!("Fallback::bar");
        Fallback
    }
}

enum EnumImplMyTrait<T> {
    T(T),
    Fallback(Fallback),
}

enum EnumPhantomDataImplMyTrait<T> {
    T(PhantomData<T>),
    Fallback(PhantomData<Fallback>),
}

impl<T: MyTrait> EnumImplMyTrait<T> {
    fn bar(which: EnumPhantomDataImplMyTrait<T>) -> EnumImplMyTrait<T> {
        match which {
            EnumPhantomDataImplMyTrait::T(v) => EnumImplMyTrait::T(T::bar(v)),
            EnumPhantomDataImplMyTrait::Fallback(v) => EnumImplMyTrait::Fallback(Fallback::bar(v)),
        }
    }
}

pub fn foo<T: MyTrait>(use_t: bool) -> EnumPhantomDataImplMyTrait<T> {
    if use_t {
        EnumPhantomDataImplMyTrait::T(PhantomData::<T>)
    } else {
        EnumPhantomDataImplMyTrait::Fallback(PhantomData::<Fallback>)
    }
}

so that implies enum impl Trait is a more correct way to spell it than impl enum Trait...

How is that implied by the previous statement?

because enum impl Trait is the simplest case of enum SomeTypeWith<impl Trait>::InIt where that's enum $ty where $ty is a type that must have impl Trait somewhere in it (only once?).

Thank you for your response, @programmerjake. I understand much more clearly.
Also, nice work making manuscripts of what the converted code would look like. (Hopefully that will make this feature and its intent more clear to future readers.)

I'd like to point out that returning Self is perfectly fine and should be allowed for the cases where the method also has a parameter which can be used to deduce which type is meant.

I'd think no actually..
enum Trait needs concrete positive rules, like dyn Trait does, meaning support for niche cases ends somewhere.  As an analogy to ImplEnumIsValid, it's clear how DynCouldBeValid could compile:, but doing so oversteps the language's complexity budget.
trait DynCouldBeValid {
    fn dup(&self) -> Box<Self>;
}

fn bar(foo: &dyn DynCouldBeValid) -> Box<dyn DynCouldBeValid> {
    foo.dup()
}

I'd think enum Trait needs exactly the same positive rules as dyn Trait if only for the complexity budget.
In fact, your example convinces me enum Trait would be harmful feature.  At least for dyn Trait you could always add object safe methods, and where Self: Sized clauses, especially with https://github.com/rust-lang/rfcs/pull/2884, as well as inherent methods on dyn Trait itself, but enum Trait manages this less well.
Instead, dyn Trait should be optimize for expected vtables, perhaps via #[hot] annotations, maybe added by profiler, or whatever.   A profiler guided choice between dyn Trait and static enum dispatch would be much more broadly useful.

@burdges

Instead, dyn Trait should be optimize for expected vtables, perhaps via #[hot] annotations, maybe added by profiler, or whatever.

This could be a nice thing to do as well, but I feel like static-dispatch will always have some usacase(s) over dynamic-dispatch.
Not to mention you can hold enum Trait [<-- Not a concrete type.] values directly in a variable whereas you can't with dyn Trait values.

In fact, your example convinces me enum Trait would be harmful feature.

Just because of their use alone or in general? [I feel like it would be unfair to penalize for their usage.]
What do you find harmful about it?

I'd think enum Trait needs exactly the same positive rules as dyn Trait

"positive rules"?
Not necessarily. I feel like they are able to have slightly different semantics given the situations they apply to.

I'd think no actually..

So maybe I was right all along.

As I indicated here, I currently don't have the bandwidth to continue working on this. This RFC needs a fair bit of rewriting to capture the points raised in discussion, and even then still has a number of open questions. I'm going to close this issue to reflect my inability to commit to shepherding this RFC.
Thanks for the input and discussion everyone; I hope that this RFC and discussion will serve as a useful reference for future work!

@burdges, for the returning Self thing, I had an idea. What if for enum impl Trait it just returned another enum impl Trait (and did whatever with the self receiver, if any), that way you couldn't get into any weird state.
Yes, I know this would kind of conflict with the whole definition of Self, but it gets us around one issue and is perfectly adequate considering we're still following whatever constraints are yet to be charted.
(And they will be charted, because as an advocate for this feature, I'm going to vastly expand on this RFC.)

@charlie-lobo

Personally I agree with the need for explicitness, but disagree with the semantic implication of the position. If the user is getting a hidden enum, or a dyn type, or all those details should be hidden, it's an implementation detail. Instead I'd specify it inside the function, so something like return enum data.

But if we place enum with the return, doesn't this mean we can't use a theoretical enum impl Trait type in other places where we could usually use impl Trait?
If we do it the other way though we basically enable it in all cases.

@CalinZBaenen

But if we place enum with the return, doesn't this mean we can't use a theoretical enum impl Trait type in other places where we could usually use impl Trait?

Well a door closed sometimes means a window opened. We could extend this to be used on any expression. Basically enum impl Trait rather than specifying we are returning an anonymous impl type that uses an enum, means the expression is supposed to be put into an anonymous enum type, of which we know that it impls all traits by delegating to its passes. So we could do something like
// Alternatively we could specify it on the other side
// when we want to specify it elsewhere
// let secret_var = enum impl Trait match foo {
let secret_var: impl Trait = enum match foo {
    bar => SomeTypeImplementingTrait{x:1, y:"hello"},
    baz => AnotherTypeThatAlsoIsTrait(3.14),
};

So what I was proposing is rather than have an "abstract type" that coerces into an enum that delegates trait implementation, have an "expression modifier" that says that the expression that follow should have all its elements put into an enum where the enum implements (by delegation) a specific set of traits. Because the type is anonymous, a voldermort type, you can only store it by typing it as impl Trait or some of the other types such as std::any, but I am assuming that we do lose the possible types.
As to why I think it's better that way. I am thinking of code evolution.
So say I have a function fn foo(elem: Id) -> impl Trait. This function can sometimes return a u32 or a i32, depending on context, so the types are pretty small. OTOH Trait is a non-trivially sized trait, with a notable amount of methods, but is otherwise pretty simple. So I could return a dyn Trait without having to change the type of the function. But this brings in the VTable and that's expensive. I'd rather return an enum. I could make my own enum, but why not simply return a valid enum instead?
But later we get a new option, that is actually [u64; 8] suddenly things get pretty heavy to return on the enum (which has to be that big). Suddenly the dyn Trait option doesn't sound that bad. So I'd want to change the actual return type to be a dyn Trait rather than enum impl Trait, but the function signature doesn't change. After all this was only an implementation detail from the view of any user, so calling this a "breaking change" would be non-ideal. Unless we are going to talk about ABI stability and making that a breaking change...
Now that means that the feature isn't that useful as a type-signature, IMHO. Because once I choose it, I am stuck with a certain data-type profile, which kind of misses the point of this abstract features. It'd be better to explicitly add an enum that handles that, so it's easy to understand the size and effect of it on other things and realize when adding another option is going to have serious implications, because once I comitted to the enum, I am stuck with the enum, the boilerplate isn't that bad honestly (a macro to make the delegating impl would suffice). But if it's simply another tool I can swap out, it becomes much more attractive as a solution that is a good place to start, and later we can move out of. And we still keep the ability to use it anywhere we use impl Trait, though it can also be used with generics.

@programmerjake

another thing to consider:
what happens when a trait has a blanket implementation such that generating a delegating implementation of the trait for the generated enum would conflict with the blanket implementation?

As it turns out, this is not a special case.
This would (probably) work just how it works normally, by only calling ()'s implementation. Here's an example on the Rust Playground.
... And using heterogeneous types results in the correct output.

@charlie-lobo

So say I have a function fn foo(elem: Id) -> impl Trait. This function can sometimes return a u32 or a i32, depending on context, so the types are pretty small. OTOH Trait is a non-trivially sized trait, with a notable amount of methods, but is otherwise pretty simple. So I could return a dyn Trait without having to change the type of the function. But this brings in the VTable and that's expensive. I'd rather return an enum. I could make my own enum, but why not simply return a valid enum instead?

By impl Trait do you mean MTRPIT (enum impl Trait)?
If the answer to #1 is yes, like I assume it is, how can you return a dyn Trait? When and why does dyn get involved?
When you ask "but why not simply return a valid enum instead", what do you mean by "valid"? What makes your own enum "invalid"?

As to why I think it's better that way. I am thinking of code evolution.

How does this help code evaluation?
Could you provide a direct comparison between the enum impl Trait syntax and the impl Trait and match {expression}? Preferably with comments that may explain anything that may require a question.

Well a door closed sometimes means a window opened. We could extend this to be used on any expression.

How will the compiler know if one impl Trait is of the normal or multitype variety?
That metadata would have to be packaged.  (Though I guess enum impl Trait requires metadata anyways.)

@CalinZBaenen

By impl Trait do you mean MTRPIT (enum impl Trait)?

Kind of. What I mean is that impl Trait remains as the return type. The thing that changes to allow MTRPIT, AFAICT is the function itself, to the caller it didn't have to be different from any impl type, things are evolving a bit more. Just as you can return a dyn Trait from a function that does this. The wrapping of the multiple types into the shared interface happens inside the function body either way.
This is why the original statement didn't have any explicit statement. I agreed with the need for an explicit statement, but it would be for the benefit of someone looking at the function itself, not someone simply calling it. I'm just moving it around.

If the answer to number one is yes, like I assume it is, how can you return a dyn Trait? When and why does dyn get involved?

Actually that's a very good point, I should clarify. I am not thinking of what dyn currently is, but instead of what dyn* would allow us to be.
Now in a world where dyn* Trait and impl Trait why would we ever want to write: fn foo() -> dyn* Trait when we could write it as fn foo() -> impl Trait and then choose whatever type it is? Well the answer is simple: it's because dyn* Trait is an actual concrete type, even though it's hidden the details of the actual type, it does so behind a well known interface (a virtual table), we have a pointer to a piece of memory whose size is unknown, but this is very workable. If I have two instances of dyn* Trait I can swap them, or mess around with them, because I know the details concretely. That is dyn Trait is not an anonymous type, it's a concrete type that lets us use multiple types as one at runtime, size was an issue, but again dyn* Trait is all about solving that.
So dyn* Trait gives us something that impl Trait doesn't. But there's many traits we can't use dyn on, but we can use impl on. So it makes sense to have both. Ok so this is easy.
What I am arguing is that impl enum Trait is not like that. The thing is that if I have two impl Trait they may be radically different types behind the scenes, I cannot treat them "as the same thing" (put them in an array or such). The same thing here with impl enum Trait, since two different functions may have two different enums created, they cannot be considered interchangeable as dyn* Trait would be. That is impl enum Trait is anonymous at static time just like impl Trait and therefore has the same limitation. So there's no  benefit in exposing this as a return type over just returning an impl Trait, there's no difference from the point of view of a user of the type. Only when we create the instance do we care.
So while it makes sense to want to specify a function that returns dyn* Trait instead of a impl Trait, there's no point, IMHO, to have a function that returns impl enum Trait rather than impl Trait.

When you ask "but why not simply return a valid enum instead", what do you mean by "valid"? What makes your own enum "invalid"?

That was a poor choice of words. Why not return an anonymous enum instead? If no-one, including myself, will be able to recover that this is an enum, and deconstruct it, why even go through the hassle of doing it by hand? Let the compiler build it for me.

How does this help code evaluation?

Not evaluation evolution. Every function has an publicly visible part that shouldn't change (except to become a super-set of what it was) and a private part that can change easily. The public-part is more than the type, it's if you're using generic interfaces or impl, it's the kindness, etc. etc. And annotations can be part of this, when you expose them it becomes a problem, as people may want to switch.

Could you provide a direct comparison between the enum impl Trait syntax and the impl Trait and match {expression}? Preferably with comments that may explain anything that may require a question.

Not sure what you mean here?
I guess that comparing the example of people, if we had something that looks like
fn foo(b: bool) -> impl enum Trait {
     if b {
         return Foo{};
     } else {
        return Bar{};
}

I would rather it be written as
fn foo(b: bool) -> impl Trait {
    if b {
        return enum Foo{};
    } else {
        return enum Trait Bar{};
    }
}

Second return has excessive large. Or alternatively for this specific case:
fn foo(b: bool) -> impl Trait {
   enum if b {
        Foo{}
    } else {
        Bar{}
    }
}

As enum here is something that makes the expression a result of all its possible expressions. Type inference tells us it should be impl Trait but you could specify a more abstract thing.

How will the compiler know if one impl Trait is of the normal or multitype variety?

This is just sugar code for making an enum, implementing the trait, and returning it. It only matters in the function body and is an implementation detail. The compiler only needs to know this when it's creating the body. When calling all the compiler needs to know is that the returned type implements Trait. Now how does the compiler end up finding what is the actual value? The same way it does for every other function that returns impl Trait: the compiler always knows what is the true type, it just doesn't share that with the user on purpose.

That metadata would have to be packaged. (Though I guess enum impl Trait requires metadata anyways.)

Yup, you're right it does need to happen. Both cases end up in the same machine code, with the same tag bits added to allow us to pick on runtime which function to call. In both cases we do have a well sized, fully-stack bound piece of data.
The difference is not in the end-result program. The difference is in how the compiler works with it, and how the programmers that meet this will have to work around it or with it.

Not evaluation evolution.

Leaving this reply in advance; my bad.
I must have been tired or something.

It only matters in the function body and is an implementation detail. The compiler only needs to know this when it's creating the body.

This is a good argument.
I will nitpick that most people don't look at the function bodies in other libraries.
They usually just check the signature and read the according documentation

I understand your suggestion and I can, on some level, come to agree.
The main reason I don't like it is because you end up writing "enum" a lot more than I think you should have to.

[Misc. replies.]

Actually that's a very good point, I should clarify. I am not thinking of what dyn currently is, but instead of what dyn* would allow us to be.

Well, with the usize sizelimit, but yeah.

I guess that comparing the example of people, if we had something that looks like

What's with the Go casing convention?
It looks jarring when all functions are snake_case. (I literally just got used to it.)

Oops, I forgot to "mention" you, @charlie-lobo.
(I don't know if editing messages will alert you or not.)

One more thing I thought of.
What if not all codepaths have an enum? Is that return value still allowed and implicitly made one of the enum-dispatch values because it's -> impl Trait or will it be an error since other items have enum?


Add Next.js App Router guide

Oh, forgot to mention, you might need to update submodules and push. That's one of the reasons the build is failing. The other is a line longer than 79 characters, I think (a check which will be going away soon 🎉 ).


add new element updates

Elements to add with simple update:
collective title
other citation details
bounding box coordinates
reference system code

All added


Update nim 0.20

add byte cast explicitly
(not related to 0.20) add size check

I'm not sure type cast is right way, though, in 0.20 I need to do this modification.
Please let me know your comments.

Thank you for your contribution!


Remove some unnecessary allocations

Remove unnecessary allocations in lexer
Replace some .replace()s with in-place replacements

Please follow this template, if applicable.
Description
I removed some unnecessary allocations.
Checklist
Please make sure you can check all the boxes that apply to this PR.

[X] All widgets I've added are correctly documented.
[X] I added my changes to CHANGELOG.md, if appropriate.
[X] The documentation in the docs/content/main directory has been adjusted to reflect my changes.
[X] I used cargo fmt to automatically format all code before committing

Thanks for your efforts!


CreateImageWizard: Fix move selected packages

If fromAvailable is false, packagesavailable can be undefined if it's
the first package that's being moved over.

Broken after rebasing on top of #467

Closed in favour of #476


Update secure-connect.md

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6759fac2132221229fcc7892--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://675b7611138faf26cd521fc1--harness-developer.netlify.app

@HenAmar pls check this revised architectural diagram. If this looks Ok, you can update the diagram via this PR.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://676130de3f219a37ba077bc3--harness-developer.netlify.app


Files with TS only assets still get transpiled

Problem: Suppose a TS app has a interfaces directory. After transpilation to JS, those files are too transpiled but left empty. UI5 tooling then bundles them but that's another thing.
The predefined setup does not handle this case out-of-the box. I've searched for babel plugins / settings but the results were not very good.
Babel does have ignore property, but when --copy-files is enabled, then the interfaces are properly not processed but still copied in the dist, which is bad. There's also this issue but the additional flag also does not function perfectly.
To handle the issue therefore an additional build step can be added (e.g filtering or deleting unneeded files).
Before doing this however, I wanted to know whether there's possibility to add this behavior in this plugin. Otherwise additional customization steps for the building of TS UI5 apps need to be taken.
Thanks for any info in advance & BR

Hi @dfenerski ,
why does it need to be a .ts file at all? Can't it just be a .d.ts file? The ui5-tooling-transpile doesn't copy the .d.ts files when the generateDts option is disabled.
In general, if you have files only including type definitions, AFAICS, the recommendation is to use .d.ts files (https://stackoverflow.com/questions/37263357/how-to-declare-and-import-typescript-interfaces-in-a-separate-file). I found a small bug in the ui5-tooling-transpile in case of generateDts the relative names need to be made absolute. But this one I tackle independently.
WDYT?
Cheers, Peter

BTW: for the issue in ui5-tooling-transpile, I created an issue: https://github.com/ui5-community/ui5-ecosystem-showcase/issues/743

Thanks for reaching out @petermuessig,
the described solution does indeed solve the problem, so I think this issue can be closed.
In my case however we also have TS for the backend so implementing this would require changing some naming conventions for all **/interfaces/**/*.ts & **/types/**/*.ts files across the codebase to have .d.ts extension instead of the current .ts one. Filtering those files in the builder section of ui5.yaml files has in the same time worked out fine.
Maybe in the future the .d.ts solution is to be implemented, however I would like to research it some more beforehand (read more about ambient modules).
Thanks & BR,
Dimitar


Feat/shopping cart

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[ ] Bugfix
[x] Feature
[x] Refactoring

Needs QA check

@kodadot/qa-guild please review
should be able to buy from Explore, GalleryItem
should be able to add to cart from explore, galleryItem
should be able to buy multiple nft's at once via shopping cart

Needs Design Check

@exezbcz please review

Context

[x] Closes #6371
[x] Closes #6373
[x] leading to #6372

More Context
Ok it's a big PR, let me break it up
The Small stuff (16 files):

5 new asset files, 1 is empty cart image and 4 are cart icon in light/dark mode  regular / crossed out 3e0f716b9a00452f6f70a4f5f7d73f3a914e720b
changes to some Neo components to support design requirements (6 files)

NeoButton - text variant  fb24fc7199f12fab1617c2585ca796c363f5246c
NeoModal - no shadow fb24fc7199f12fab1617c2585ca796c363f5246c
NeoNft card - new hover action slot in order to add buy now / cart buttons to the card while keeping the logic in nft-gallery
41dc0f7a35ac22bacee10551f2e2dd8e1f5de7ee

Add shopping cart button to navbar (3 files) e8670b35130f7b2ea24bbf00aa1a2c18c1f75668
move nft avatar parsing c9abdecf48f7bb88f16d573ccfa0ebec8a3115d0 this utility was needed elsewhere as well so I moved it to a more common location (2 files)

The 'Meat' (19 files) :

new Shopping cart modal and confirm purchase modal (6 files) cd937a36af1ab9633848d956a007ce13c6780f4c
shopping cart store (1file) 506d189a26f5e3188840aac882e34af112993760
preferences store additions to control open/close of new modals (1 file) 2de0ce0ed806a83bb2901c4ab0d53dcc92d4889a
new Buy.vue component to group the buying logic (confirmation modal, loader, notifications, buy execution) (1 file) ad59f2ced39370eea2110ffa3725edc4d3ca0058
use Buy.vue in all layouts where there is navbar (7 files) 2fbbc24fea21fd23f2465619ed7a49d6775e2389
GalleryItem: (2 files)

redesign - no longer use the sliding button
remove buying logic out of gallery item (it is in Buy.vue now)
6c32e9da31c1b7a5306224aed4ebca7cf447aa2a, 410ec61533f8272e4d2462bc87a8aea105ac9dfb

explore cards - add buy now /  cart buttons (1 file) c2dab0b1fba37b63f7dd07824acfa8261282b27f

enable buying of multiple nfts at once (2 files):
0d307f5a6ee4e4810e0cceb978397cea281e5fb8
The Surprising stuff (4 files):

delete BaseGalleryItem.vue, unused file that was causing unexpected CSS side effects in GalleryItem 667bdcc4a3a9d002c97cf1676cd98e4bea8a7a79
add pub/sub pattern event bus - add the ability to emit and listen to events outside of vue component hierarchy
why? GalleryItem was listening to a buy-success event emitted from it's children. the response to the event is to trigger buy-success notification.
now that I moved the buy logic to the page level (in layouts) I needed a way to emit an event and have GalleryItem listen to it as it did before.
this opens up the ability to listen to buy-success  event or others in any component
0d307f5a6ee4e4810e0cceb978397cea281e5fb8, 38979dd257d4dc8f6bc9e0ea7b0435686c0d190e

Total accounted for 41 files
Q&A
1. why do we need Buy.vue component on layouts?

confirm-purchase dialog and the subsequent  loader can now be triggered through the shopping cart from any page that has the Navbar, therefore, they can't be placed in any particular page/ component
That is in contrast to the previous situation where user could buy only from GalleryItem page

2. why don't you use icon instead of assets for shopping cart button

both me and @exezbcz  could not find a striked-out-cart icon anywhere, so we use custom svg instead

3. why did you delete BaseGalleryItem.vue?

it created unexpected CSS effects in GalleryItem and afaik it isn't used anymore

4. EventBus? why? why don't you use pinia?

it is needed in order for Buy.vue to emit an event and GalleyItem to pick up that event to trigger the success buy notification
to do it through pinia would be awkward and difficult if we ever want to have multiple listeners on this event

Did your issue had any of the "$" label on it?

[x] My DOT address: Payout

Screenshot 📸

[x] My fix has changed UI

Copilot Summary

🤖 Generated by Copilot at 4336bba
This pull request adds a shopping cart feature to the NFT gallery, allowing users to buy multiple NFTs from different chains in one transaction. It also refactors some existing components and functions to improve the performance and usability of the gallery.

🤖 Generated by Copilot at 4336bba

We wanted to make buying NFTs a breeze
So we added some components and refactored with ease
We used ShoppingCartModal and ConfirmPurchaseModal too
And useIsBalanceEnough to check what you can do
Now you can buy from the gallery or the cart with execBuy* functions for each chain

woaah, cool

both me and @exezbcz  could not find a striked-out-cart icon anywhere, so we use custom svg instead

maybe use cart-x?

When I click striked-out-cart it does nothing, expected?

Go To Cart button not aligned to center

maybe use cart-x? ![image](https://user-images.githubusercontent.com/734428/257169198-2c97417a-73d6-4511-

@exezbcz wdyt?

When I click striked-out-cart it does nothing, expected?

yes

@preschian
fixed

Found some stuff.

overflow text
incorrect unit BSX -> KSM

@daiagi really nice work with the description! nice PR aswell, will check.

hello sir
Feedback
few things here
Cards

please have a look at this component
black button is an active state - it makes more sense than changing the icon and leaving the default state - this makes a better contrast

no outline around nft cards that are selected and are in the cart
buy now button should not change to go to cart, buy now is possible even when the item is in the cart

popup buttons are not centered on the card
normal button with a 16px font size should fit there, no?

Cart sidebar

when clicking explore nfts in the cart sidebar in light mode, it redirects me to explore, but in dark mode. Is there any way to keep the mode?
space between the separator and the nfts is now only 12px, it should be 16px

separator color k-shade please
could we please remove the hover effect when hovering over the title? It makes sense, but with the change of background, it does not look good

complete purchase should be active even without the connected wallet. When clicking the button, it should result in

Issue for insufficient funds is coming

gallery
this button in gallery does not work

it should remove item from the cart, making it possible to add it again

Modal

make the address name non bold font weight, there should not be a hover card over the profile
this pink part shows where is 16px padding, currently its incorrect between the bottom item and separator

items in this modal are not clickable

text size:

the price for nfts text should be 12px, small font size, k-black. The number there is 16px, also k-black
then there is royalties, the whole row is 12px in k-grey color. I will also make a copy for the tooltip there.
space between these two numbers is 8px

padding for this button is 24px 32px, same as the modal title

Questions
the buying flow is not done right? #6372

others

feel free to dm me

@prury +1

yup, buy now flow not yet working.
confirm purchase overflow and incorrect unit:

Mobile:
@exezbcz how's the buy/add to cart process should work when using mobile? the person will only be able to add items if they enter inside a gallery item?
Cart position:

I believe this should be there:

that's it for the moment, seems that Exez tackled most of the problems, will do another round after the fixes.

maybe use cart-x?

It doesn't look that nice, but if we really want to avoid using custom icons, then it's okay.

nah, I'm good with custom icons if there is no icon in the fa
how about using an icons stack? @daiagi @exezbcz
but you need extra CSS to match square button from the design
output:

code:

@exezbcz how's the buy/add to cart process should work when using mobile? the person will only be able to add items if they enter inside a gallery item?

correct

@prury @exezbcz
all the issues have been taken care of, please try again

hmm, interesting, @daiagi ready to battle CSS with my crazy instructions? :D I would maybe add the white line as well, above the cross line, like on the original icon :D

mmm I rather not tbh, if we are ok with the SVG icons then let's leave it at that  at the moment

tested buy of multiple nfts and all success:
stmn:
https://assethub-kusama.subscan.io/extrinsic/5057598-2?event=5057598-8
ksm:
https://kusama.subscan.io/extrinsic/19073481-2
rmrk:
https://kusama.subscan.io/extrinsic/19073580-2?event=19073580-41
bsx:
https://basilisk.subscan.io/extrinsic/3916515-2?event=3916515-7

will also check again, thanks @daiagi !

okay, last round 🔥
feedback

please remove the hover bg from the confirmation dialog - the item is not clickable - thus not even changing the bg

remove hover effect from address - I managed to click to it with open modal and I got redirected

add drop shadow to the modals, this is my fault, its not visible in figma
add a full-screen overlay when having the modal open - when you have the modal, you should not be able to open navbar items

cart sidebar

please make the sidebar width same as other sidebars (notification, wallet, etc) - afaik this is 360px
close the sidebar when clicking the item inside - going to gallery item from cart

wrong hover effect on the remove all textlink

Buy flow

managed to sign transaction for nfts that I do not have enough funds for.

I think this could be solved in #6522

Not connected wallet

here is this weird flow when adding items to cart when not connected. You get currently redirected to the modal with confirm button disabled. It should be like this: In cart you click confirm purchase, connected wallet dialog popups, once you connect, confirmation dialog is displayed

Otherwise really solid, and thank you!

@daiagi i'm aware that this PR is huge already and you pulled a great great work, I'm happy to add the following to another issue if you wish:

Statemine testing:
Went and bought 3 NFTS
https://assethub-kusama.subscan.io/extrinsic/5060255-2
none of them went to my address
one of them is this one: https://deploy-preview-6501--koda-canary.netlify.app/stmn/gallery/6-8
tried again, got an error: https://assethub-kusama.subscan.io/extrinsic/5060296-2

is it hard to clear the contents of the cart once the transaction ends?

~to be edited

ii'm aware that this PR is huge already and you pulled a great great work, I'm happy to add any findings in another issue

doing some digging me and @prury  realized the issue was not from this PR, but probably an indexer issue on stick

#6530

@exezbcz
:heavy_check_mark: please remove the hover bg from the confirmation dialog - the item is not clickable - thus not even changing the bg
:heavy_check_mark: remove hover effect from address - I managed to click to it with open modal and I got redirected
:heavy_check_mark:   add drop shadow to the modals, this is my fault, its not visible in figma
:heavy_check_mark:  add a full-screen overlay when having the modal open - when you have the modal, you should not be able to open navbar items
:heavy_check_mark:  please make the sidebar width same as other sidebars (notification, wallet, etc) - afaik this is 360px
ok but it forces to ellipsis many names
:heavy_check_mark:   close the sidebar when clicking the item inside - going to gallery item from cart
:heavy_check_mark: managed to sign transaction for nfts that I do not have enough funds for.
not sure how, but it shouldn't happen anymore

here is this weird flow when adding items to cart when not connected. You get currently redirected to the modal with confirm button disabled. It should be like this: In cart you click confirm purchase, connected wallet dialog popups, once you connect, confirmation dialog is displayed

right now clicking any button that leads to confirmation dialog (explore grid, cart, gallery item) while not connected will popup connect wallet dialog
i am not sure how to "connect" the dailogs, i.e make the confirm dialog appear after a successful wallet connection
let's defer this to follow up issue

wrong hover effect on the remove all textlink

what color it should be?

✔ add a full-screen overlay when having the modal open - when you have the modal, you should not be able to open navbar items

now there is a double cross (in the top right corner of the screen)

✔ close the sidebar when clicking the item inside - going to gallery item from cart

It works only when clicking the nft name, not the item preview - it took me a while to figure out why :D
otherwise, I will leave other things to some followups ✅

now there is a double cross (in the top right corner of the screen)

didn't see it. nice catch. fixed

It works only when clicking the nft name, not the item preview - it took me a while to figure out why :D

oh yeah. fixed

follow ups it is then!

yess, nice job!

promise won't break 🤞
impressive work!

pay 100 usd

😍 Perfect, I’ve sent the payout
💵 $100 @ 4.97 USD/DOT ~ 20.121 $DOT
🧗 1cAsKZYNRb8dkSCpn4eVkEn6ycNZTGoDo5dGDgB8J1UUWK8
🔗 0xfd1d0522c51329cf716653f1151caf71225456d8c9bb0f846d347c878222b1ad
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


test(travis.yml): run tests on Travis

Add the test run script to travis to verify PRs and pushes

:+1:

👍

Bluemix toolchain: Delivery Pipeline deployed carbon-components-react to Bluemix Design System, including commit c259aecec4608ce1d5e612fa513519c16636cec6


filepath.Clean cannot be used as safe sanitizer

What version of Go are you using (go version)?

# go version
go version go1.13.1 linux/amd64

Does this issue reproduce with the latest release?
Yes. Using golang:latest
What operating system and processor architecture are you using (go env)?
go env Output
# go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build633713348=/tmp/go-build -gno-record-gcc-switches"

What did you do?

package main

import (
	"fmt"
	"path"
	"path/filepath"
)

func main() {
		basedir := "/tmp"
		fmt.Println(path.Join(basedir, filepath.Clean("../../../.../../../../../../"), "file.txt"))
		fmt.Println(path.Join(basedir, filepath.Clean("/../../../.../../../../../../"), "file.txt"))

}

https://play.golang.org/p/sbCquGUpnyc
What did you expect to see?
/tmp/file.txt
/tmp/file.txt
What did you see instead?
/file.txt
/tmp/file.txt
Seems like filepath.Clean does not clean path completely. Therefore, filepath.Clean cannot be used as safe sanitizer against LFI/doubledot/directory traversal type of attacks.

Although, Clean is not sanitizer - it should be stated as such in documentation:

Although, filepath.Clean is not sanitizer it should be noted in documentation in big bold letters:
https://golang.org/pkg/path/filepath/#Clean

The documentation for Clean explains precisely what it does.  The documentation does not claim that Clean is any sort of sanitizer, since it isn't one.  The documentation says what it does: "Clean returns the shortest path name equivalent to path by purely lexical processing."

Therefore, filepath.Clean cannot be used as safe sanitizer against LFI/doubledot/directory traversal type of attacks.

Correct.  No purely lexical function can do that.


Added python3 joblib as a rosdep

Please add the following dependency to the rosdep database.
Package name:
python3-joblib
Package Upstream Source:
https://github.com/joblib/joblib
Purpose of using this:
Joblib allows for easy parallelization of workloads in Python. The Python 2 version of the package is already part of rosdep.
Distro packaging links:
Links to Distribution Packages

Debian: https://packages.debian.org/stable/python3-joblib

REQUIRED

Ubuntu: https://packages.ubuntu.com/focal/python3-joblib

REQUIRED

Fedora: https://src.fedoraproject.org/rpms/python-joblib

IF AVAILABLE

Arch: https://archlinux.org/packages/community/any/python-joblib/

IF AVAILABLE

Gentoo: https://packages.gentoo.org/packages/dev-python/joblib

IF AVAILABLE

Could you address the automatic check warning?

Key 'python3-joblib' might be satisifed by opensuse package named 'python3-joblib': https://software.opensuse.org/package/python-joblib

Updated, thanks.


Add better command line documentation

Extend gulp-help so that we can define param documentation for each individual task, and categorize tasks. (For instance, separate deployment and build tasks visually).

This has been completed.


🐛 BUG: typo in wrangler-devtools Content-Security-Policy

Which Cloudflare product(s) does this pertain to?
Wrangler core
What version(s) of the tool(s) are you using?
3.22.3 [Wrangler]
What version of Node are you using?
21.4.0
What operating system are you using?
Mac
Describe the Bug
When accessing https://devtools.devprod.cloudflare.dev/ with another layer of DevTools open, I see the following error in the JS console: The Content-Security-Policy directive 'script-src' contains 'script-src' as a source expression. Did you want to add it as a directive and forget a semicolon?.
The error corresponds to this line from the wrangler-devtools patch: https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler-devtools/patches/0015-Basic-support-for-Safari.patch#L33
Based on the CSP: script-src docs, I think getting rid of the 2nd script-src should fix the CSP:
-<meta http-equiv="Content-Security-Policy" content="object-src 'none'; script-src 'sha256-nR3ouvAaRD5oAvx24d8aFSv1EH9XKi9uVvoOsvVuW8U=' script-src 'sha256-AIRkz8wOl/LgmUJduw9AsUnrb94PlBpePfk0Rowm+Vo=' 'self' 'unsafe-eval' https://chrome-devtools-frontend.appspot.com">
+<meta http-equiv="Content-Security-Policy" content="object-src 'none'; script-src 'sha256-nR3ouvAaRD5oAvx24d8aFSv1EH9XKi9uVvoOsvVuW8U=' 'sha256-AIRkz8wOl/LgmUJduw9AsUnrb94PlBpePfk0Rowm+Vo=' 'self' 'unsafe-eval' https://chrome-devtools-frontend.appspot.com">

Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
js_app:43
The Content-Security-Policy directive 'script-src' contains 'script-src' as a source expression. Did you want to add it as a directive and forget a semicolon?

@penalosa


ToC footer not at the bottom

Operating system: MacOS 10.13
Last upstream commit : bdb693031027c2e5af77cb709cb86836c3e2e74c
Browser version(s): Chrome Version 61.0.3163.100
Ruby version :  2.4.2

First at all, thanks you for great library. I have tried to setup my docs and see footer not always at the bottom. This is a bug or something wrong in my config ?

Oh god wat haha! Haven't seen that before. Is there some minimal example you can upload showing this behavior?

Here my code:

Hrm, I was more hoping for a minimal example that I could run on my own computer to see the issue?
If it's too big to upload, you could check to see if your same markdown on a fresh install of Slate causes this bug. If not, it's probably something in your custom styling?

Ok, I will write a minimal example and send you.

example.zip

This is my example and behavior when run on my computer

It looks like your fork has a ton of custom CSS that we can't officially support — we like to debug issues with the whole project, but don't have time to help debug every person's individual setup for free. I'm sorry! If you have an example with the standard CSS that has this bug, would be glad to take a look at it.

Thanks for your help.


HTML5 Godot will not detect FullScreen if entered via browser/f11 request.

Tested versions
3.x
System information
web (Chromium)
Issue description
This behaviour mathes the one partialy described on https://stackoverflow.com/questions/27501409/exit-full-screen-using-f11-key-and-esc-key
What happen is, OS.window_fullscreen will only return True if godot itself asked for the fullscreen.
If user press f11 (when intercepted by brower, not captured inside godot), or go to hamburger menu and click fullscreen,
OS.window_fullscreen will not return true.
Indeed fullscreen godot shows ESC, and fullscreen browser shows F11;
this prevents good fullscreen behaviour management.
Steps to reproduce
Acess this and enter fullscreen via input and via browser request.
Minimal reproduction project (MRP)
A single label node with the script:
extends Label
func _process(delta):
	text = str(OS.window_fullscreen)
func _input(event):
	if !OS.window_fullscreen and event is InputEventMouseMotion == false:
		OS.window_fullscreen = true

AND.
After entering via browser request one can RE-ENTER fullscreen, and detect true.
Then, one can EXIT 2 TIMES FULLSCREEEN.
The first time via ESC, now detection goes back to false, but viewport is still  fullscreen
Then, using F11, one can really exit fullscreen.
OR
Diretly  pressing f11 will exit "both" fullscreen at the same time.

Well, it seens that F11 put the BROWSER on fullscreen, and the engine request put the "page?".
So, maybe its 2 classes of fullscreen available. Idk.
Needs testing and a further investigation on apis.

Godot 4 test
I tested on v4.2.1.stable.official [b09f793f5] with the equivalent DisplayServer.window_get_mode() == DisplayServer.WINDOW_MODE_EXCLUSIVE_FULLSCREEN or DisplayServer.window_get_mode() == DisplayServer.WINDOW_MODE_FULLSCREEN on itch.io (so I can click outside game and press F11 for a browser fullscreen, not in-game fullscreen) and it seems to lock DisplayServer.window_get_mode() to one value that is not fullscreen nor exclusive fullscreen (haven't debugged the exact value yet, possibly DisplayServer.WINDOW_MODE_WINDOWED). As a result both my in-game fullscreen toggle option and my keyboard shortcuts to toggle fullscreen based on current state are broken (only force setting window mode to a certain value should work).
Note: itch.io can add a custom bottom-right button on top of the HTML template to toggle "real" fullscreen (fullscreen on embedded game, not page) and this one is fully compatible with the Godot window mode change. So I'll tell users not to use browser page fullscreen for now.

Detecting browser fullscreen sounds difficult to detect in a 100% reliable manner. You'd expect to be able to compare the canvas size to the display size, but there are several complications that can arise due to multi-monitor setups (I don't know how web browsers handle this).
Also, many browsers intentionally report a false screen resolution in an attempt to thwart fingerprinting.

@Calinou

unless browsers have an API they reliably use to be able to query whether the browser has just entered/exited fullscreen

It doesn't seem like Chrome fires the fullscreenChange event when the user presses F11 or (fn+F for Mac). Additionally, document.fullscreenElement seems to be null on those same button presses. I wonder if this is intentional for Chrome.


C# add microbenchmarks project

add editor.config for C# to prevent using editor.config with indentSize=2 from repo root
add skeleton of C# microbenchmarks project

Also adds a microbenchmark that tests how much is C#'s overhead of sending a message (streaming send). It's done by setting up a fake environment and then invoking callSafeHandle.StartSendMessage and then retrieving the completion from completion registry (and cleaning up the BatchContext). The C core part of the processing is eliminated by short-circuiting calls to grpc_call_start_batch.
Short circuiting can be achieved with the newly introduce native method "grpcsharp_test_override_method". In real-life, the overriding capability won't add any noticeable overhead (it's like invoking a virtual method).
Similar technique can be used to add more microbenchmarks that test overhead of receiving a message, running a unary call, etc. This should be great for evaluating optimizations considered for C# (and it makes it easy to see how well potential improvements scale).

Friendly ping

Known failures:
https://github.com/grpc/grpc/issues/11325


question (not an issue)

Really nice component, exactly what i will need for my next project! I wandering what could be the effort to make it available for Angular 2.
Best regards,

Hi @stherrienaspnet,
thank you. I'm looking forward to start an Angular ≥ 2 / Material 2 version within the next  two weeks. But I think I'll start it from scratch, so I can't say anything about release dates...

If you need support for the next version let me know. I will prerfer contribute to your component than start a new one. You already have experience with this kind of component...

That's a good idea. Have you checked out the dev branch allready?

Not yet but i will soon :)
Le 9 juin 2017 4:02 PM, "David Enke"<EMAIL_ADDRESS>a écrit :

That's a good idea. Have you checked out the dev branch allready?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/davidenke/angular-material-keyboard/issues/9#issuecomment-307486240,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF19cYz-artDJiUm6n7g_JsDiFgeidO3ks5sCaTZgaJpZM4NDahd
.


KAFKA-6527:Enable DynamicBrokerReconfigurationTest.testDefaultTopicConfig

As title, the test was run on local over 100 time, I did not get any fail so try to enable it for CI.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@TaiJuWu , thanks for the PR. One comment:
Could you left a comment in this PR to mention you're going to take it over? https://github.com/apache/kafka/pull/13953 . Otherwise, it's a duplicated PR in the community.

Let's ship it to run it in the QA ASAP


Supporting >= operator for versions

Why? Example on autoprefixer, I want to add prefixes when at least the browser uses one of a thousand (>= 0.1%), but now i can do this using >= 0.09%. It is implicit and not very convenient. I can do PR if your accept.

browserslist supported >=

@Semigradsky
>= 0.1%

browserslist: Unknown browser query `>= 0.1%`

Done 66eaa16

Released in 2.1 version


ImportError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found

Hello,
This is the error I have encountered.
ImportError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /home/user/anaconda3/lib/python3.8/site-packages/bpy.so)
Can you help me with this ?

https://github.com/docker-library/docs/tree/master/python#pythonversion-alpine

The main caveat to note is that it does use musl libc instead of glibc

Questions like these should be asked over at the Docker Community Forums, Docker Community Slack, or Stack Overflow. Since these repos aren't really a user-help forum

Thank you. Closing the issue.


Default setup_configuration value should be False

For the individual configuration items, e.g.
SITES_CONFIG_ENABLE
NOTIF_OPENZAAK_CONFIG_ENABLE
OPENZAAK_NOTIF_CONFIG_ENABLE
ADMIN_OIDC_CONFIG_ENABLE
etc etc. For all of them.
When I run setup_configuration now if I just want to configure ADMIN_OIDC_CONFIG_ENABLE I will need to explicitly set all the others to False. This is very annoying.

In overleg met Joerie op naam van Sergei.

I'm going to need a lot more context because this doesn't ring any bells for me

Of course.
So for example, openzaak: https://open-zaak.readthedocs.io/en/latest/installation/config/openzaak_config_cli.html?highlight=setup_configuration
For demonstration sake I have unset SITES_CONFIG_ENABLE, OPENZAAK_DOMAIN, OPENZAAK_ORGANIZATION.
Now when the init container with setup_configuration runs it will result in an error:
CommandError: Prerequisites for configuration are not fulfilled: Site Configuration: OPENZAAK_DOMAIN, OPENZAAK_ORGANIZATION settings should be provided

openzaak-8496bc744d-zld7t                                0/1     Init:CrashLoopBackOff   4 (20s ago)      4m11s

For openzaak there are not that many yet and the chart sets it to false by default: https://github.com/maykinmedia/charts/blob/b0039064130c3c24269c83e7a150f35be7a43b1a/charts/openzaak/values.yaml#L17
When a new setup_configuration item is added with a new release it would break the existing setup_configuration config because this new item would default to True when not set. You would need to explicitly set this new item to False to prevent the command from failing.

@joeribekker I think this is better suited for Anna / team bron that actually define the setup configuration items and maintain that library?

Discussed with Sjoerd, and the following enable_setting 'True' default value should be set to False:
https://github.com/maykinmedia/django-setup-configuration/blob/0c5557799f3bb9f340112dfb4ca7b99d35986fe4/django_setup_configuration/configuration.py#L42C55-L42C59

@sjoerdie incorrectly assumed that this issue was already resolved (Taiga OIP 2563) , @pi-sigma is taking a look anyway

I can do it in django_setup_configuration, but it won't affect Open Zaak configuration much, since we define all *_ENABLE settings there (https://github.com/open-zaak/open-zaak/blob/88b6e9ff734d604255837c0e8d18ff5e8a9ce6d2/src/openzaak/conf/includes/base.py#L275 )
So it should be done in all components which use django_setup_configuration

I've added tasks to this issue to keep track of the progress


[DL_edition] Windows CI mamba setup fails

Windows CI is failing during miniconda setup:
Run conda-incubator/setup-miniconda@v2
Gathering Inputs...
Creating bootstrap condarc file in C:\Users\runneradmin\.condarc...
Ensuring installer...
Running installer...
Setup environment variables...
Parsing environment...
Configuring conda package cache...
Applying initial configuration...
Initializing conda shell integration...
Adding tools to 'base' env...
Ensuring environment...
Updating 'teachopencadd' env from conda env update...

Error: The process 'C:\Miniconda3\condabin\mamba.bat' failed with exit code 1

When switching to setup-micromamba the following appears in the log
2023-05-26T08:46:55.3514041Z error    libmamba Could not solve for environment specs
2023-05-26T08:46:55.3514479Z     The following package could not be installed
2023-05-26T08:46:55.3573974Z     └─ pyg 2.2.0  does not exist (perhaps a typo or a missing channel).

On windows, pyg needs to be handled differently. See here.


⚠ Bofrost.fr has degraded performance

In fbd9a25, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1400 ms

Resolved: Bofrost.fr performance has improved in 3eefb77 after 6 minutes.


[BUG] Since setuptools 75.0.0, packages fail to build with race condition: "No such file or directory"

setuptools version
setuptools==75.0.0
Python version
Python 3.12
OS
Gentoo Linux
Additional environment information
No response
Description
https://bugs.gentoo.org/939798
https://bugs.gentoo.org/939875
Packages fail to build with "no such file or directory" claiming that compiler output files cannot be created.
Expected behavior
Setuptools should create directories needed by an output file before running the compilation.
How to Reproduce
Build cython with job parallelism and cross your fingers.
Output
2024-09-19 21:23:05,173 root INFO running build_ext
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Tempita/_tempita.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Utils.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Compiler/FusedNode.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Compiler/Code.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Compiler/Visitor.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Compiler/FlowControl.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Plex/Scanners.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Compiler/Scanning.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Compiler/Parsing.py
[1/1] Cythonizing /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Plex/Machines.py
2024-09-19 21:23:13,316 root INFO building 'Cython.Plex.Scanners' extension
2024-09-19 21:23:13,372 root INFO creating /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11-python3_12/build/temp.linux-x86_64-cpython-312/var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Plex
2024-09-19 21:23:13,868 root INFO building 'Cython.Plex.Machines' extension
2024-09-19 21:23:13,869 root INFO x86_64-pc-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -O2 -pipe -ggdb -DNDEBUG -fPIC -I/usr/include/python3.12 -c /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Plex/Machines.c -o /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11-python3_12/build/temp.linux-x86_64-cpython-312/var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Plex/Machines.o
Assembler messages:
Fatal error: can't create /var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11-python3_12/build/temp.linux-x86_64-cpython-312/var/tmp/portage/dev-python/cython-3.0.11/work/cython-3.0.11/Cython/Plex/Machines.o: No such file or directory

Thanks for the report and for the analysis in https://github.com/pypa/distutils/issues/304#issuecomment-2423879878.

f2157f5
This commit in distutils looks incredibly suspicious. I cannot see how it would be functional. It replaces a global cache variable paired with a function that:
* checks if a directory has previously been created, or return early

* runs `Path.mkdir()`

* upon success, updates the global cache

with new logic that does this:
* check if a directory has previously been created, or return early

* update the global cache

* returns a function to call `Path.mkdir()`

This is not going to be parallel-safe.

I don't think the new logic characterization is quite fair. The new logic doesn't return a function to call Path.mkdir(), but like the previous logic, runs Path.mkdir().
So the only difference is the order of operations (whether the cache is updated before or after mkdir runs), and whether the cache is updated on a failure. Perhaps all that's needed to correct the behavior is to address that concern.

Before I cut a release with Setuptools, would either of you be willing to confirm that by applying 5904204 to an affected environment that it addresses the issue?

I just got back online after the holiday and haven't had a chance to test it (yet).
But I will say that based on the commit message alone, the regression test is wrong (and the fix might be wrong, but I'm not sure). After mkpath is run, the attempt was a success and the path is guaranteed to exist -- the problem isn't that failures may be cached, the problem is that the cache happens first, and then the success happens, so in a multi threaded application such as distutils (or setuptools),

mkpath will cache a success
another parallel job retrieves the cache and doesn't do anything, then errors out
the first job succeeds at creating the path and also succeeds at the overall threaded job

A test case testing for OSError doesn't simulate the thread conditions that failed in the bug report. I agree it's an additional failure mode.
I'm also inclined to agree without a chance to test it, that it's the same failure mode and a fix for one will fix both.
So I think the answer is that the setup.py -j$(nproc) case is still being untested and may continue to regress in different ways even though this regression has been solved.

Yes, I agree the proposed fix only addresses the "order of operations" failure mode and doesn't address issues of thread safety or other parallelism. I chose that approach because I believe that after correcting the "order of operations" concern, the behavior should be functionally the same as it was before the regression. That is, I've been unable to identify any way in which the code prior to f2157f50101906b300108e953bd4ccff26be9e2e would not have had the same parallelism risks, as both use a single global cache within the dir_util module.

So I think the answer is that the setup.py -j$(nproc) case is still being untested and may continue to regress in different ways even though this regression has been solved.

Yes, I agree, but I'm thinking that creating a proper regression test for this case would be difficult and brittle, especially since it's a race condition, so subject to machine performance and other measures. Without a minimal reproducer, it's difficult to even conceive of a regression test. That's why I'm taking a pragmatic approach to restore the prior behavior in the hopes that will be sufficient to unblock the issue.
I'd love to see a more robust test that captures failures in parallelism, perhaps more broadly across setuptools, but that's a much more ambitious ask and probably lower priority than some other open concerns. Still, if you feel strongly about it or especially if you'd like to contribute such a fix, I'd welcome you to file an issue with setuptools (or possibly here, but probably setuptools) to track the broader issue.

@jaraco, sorry for the delay. I've just tested the patch and it seems to fix it. At least I've tried with cython and h5py — without the patch, reproduced immediately; with it, ten successful builds in a row.


ci: fix for deployment failure

I deleted a necessary setting value carelessly, so I put it back.
I have confirmed that the deployment is successful in the dev container.


Update for jupyterlab 3

Awesome!! Thanks @davidbrochart!
I tested it and it works great, so I guess it's ready to merge?

Yes, although when developing with jlab I need to pip install after each change, so maybe I forgot something.

Yes, although when developing with jlab I need to pip install after each change, so maybe I forgot something.

It seemed to work after updating some scripts found in the extension cookiecutter. I'll merge this and address this issue in a follow-up PR.


dag to circuit to dag roundtrip is broken

Invoking the function retworkx.weakly_connected_components on the attached DAG gives different results, depending on whether it's the original DAG or the DAG is first converted to a circuit and back
(Interestingly the answer is correct only after I do the round-trip, not on the original DAG)
import pickle
import retworkx as rx
from qiskit.converters import circuit_to_dag, dag_to_circuit

def _how_many_subcircs(dag):
    rx_graph = dag._multi_graph
    rx_subgraphs = [ rx_graph.subgraph(list(subgraph_nodes))
                     for subgraph_nodes in rx.weakly_connected_components(rx_graph) ]
    return(len(rx_subgraphs))

with open('test_dag.pkl', 'rb') as handle:
    dag = pickle.load(handle)                # original dag

dag2 = circuit_to_dag(dag_to_circuit(dag))   # round-tripped dag

_how_many_subcircs(dag)    # returns 7, incorrect

_how_many_subcircs(dag2)   # returns 6, correct

test_dag.pkl.zip

Yeah, it definitely looks like the round trip converter is dropping an edges somewhere, for reference the dag before the conversion:

and after running circuit_to_dag(dag_to_circuit(dag)):

Ok after investigating with @mtreinish it looks like the original DAG was malformed (kind of obvious from the picture above too). So this is not a Qiskit issue. It would be nice if Qiskit was able to validate the DAGs though (in particular how data flows through them, all data should start in green nodes and end in red nodes).


UTM crashes when unplugging SSD when "querying USB devices"

Describe the issue
After disconnecting an USB device from UTM VM access, trying to reconnect it to the VM results in a hang while it's "Querying USB devices...". Unplugging the USB device crashes UTM immediately. May be related to #4942.
Configuration

UTM Version: 4.4.4
macOS Version: 14.1
Mac Chip (Intel, M1, ...): M2

Crash log
UTM-2023-11-02-170637.ips.zip
Debug log
debug.log.zip (was unable to crash UTM again, only hang)
Upload VM
N/A

Possibly related to #5811

No, its not fix. This solution didn't help me


Handling PDF Formatting Issues and Adjusting for Various Structures

Side note: I am writing this so I do not forget
There are issues when there are different kinds of pdf's being processed. For instance there could exist hyphens in the beginning, could also exist in the middle of the text similar to:
- Industry 4.0, also known as the fourth industrial revolution, refers to integrating digital
technologies into manufacturing processes. This essentially paves the way for the
Intelligent Industry-of-the-Future concept

I need to think of all the cases of how a pdf may be structured which isn't too bad, and then adjust the code accordingly to all those side cases.
Also, I need to update the repository I forked, with all the font sizes, as there may exist headers similar to:
## Big title text (need to adjust for this)

Regular text (works)

Possibility of simply using a PDF -> MD parser, or going the intensive learning route with using NLP (Natural Language Processing) to move PDF to MD.

Could I use spacy?

Can convert from PDF ➡ HTML ➡ MD ➡ PDF using both Pandoc and pdf2htmlEX
PDF ➡ HTML
HTML ➡ MD
MD ➡ PDF

Can also use LaTeX in this situation.

Can I use spacy for the Topic classification similar to this?

Topic Modeling

Almost done. Need to go from MD ➡ PDF

Going the Deep Learning + NLP Route.
Ideally need to learn the concept with the math one by one before application.
Links:

Deep Learning
RNN - Tensorflow
Transformers (also in 1.)


SliverResizingHeader

A sliver that is pinned to the start of its CustomScrollView and reacts to scrolling by resizing between the intrinsic sizes of its min and max extent prototypes.
The minimum and maximum sizes of this sliver are defined by minExtentPrototype and maxExtentPrototype, a pair of widgets that are laid out once. You can use SizedBox widgets to define the size limits.
This sliver is preferable to the general purpose SliverPersistentHeader for its relatively narrow use case because there's no need to create a SliverPersistentHeaderDelegate or to predict the header's minimum or maximum size.
The sample shows how this sliver's two extent prototype properties can be used to create a resizing header whose minimum and maximum sizes match small and large configurations of the same header widget.
https://github.com/flutter/flutter/assets/1377460/fa7ced98-9d92-4d13-b093-50392118c213
Related sliver utility PRs: https://github.com/flutter/flutter/pull/143538, https://github.com/flutter/flutter/pull/143196, https://github.com/flutter/flutter/pull/127340.

Pining into my inbox/review queue :)


Support postgresql kafka connector

Ref #4

Added support for PostgreSQL database

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: Atiq:x: Atiq SayyedAtiq, Atiq Sayyed seem not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


OCO orders

Hey all,
Any news on the OCO implementation? I saw 3 or 4 OCO pull requests but all are open now.
When will be this feature available and be merge in the library?
Thanks,
Leslie

https://github.com/anydoby/binance-java-api
this man already pushed his code for OCO you can use it


Kodik Parser Update

Kodik update for video url api endpoint ext
Kodik updated their endpoints system and now endpoint urls are dynamic.
Needed to update:

[x] Extractor of min js
[x] Endpoint parser

Completed