[Siddhi-sahu]

this pr adds rust wrappers, for std::stack<int> overloads.
overloads that works:

• new(): default constructor
• new(&StdStack):copy constructor
• new(&mut StdStack): move constructor
• new(&[T]) : iterator pair constructor ( c++ 23)
• new(&mut dyn Iterator<Item = T>) : from_range constructor ( c++23)

Also added plain (non-overloading) helpers, is_empty , push , size and top_const.
The tests check the right constructor is called for each overload.

failing example

top(&self) and top(&mut self) ; (cpp const T& top() const and T& top() ) , cannot both go into the overload macro, because the macro demands every overload of a name to have the same receiver kind.

skipped

allocator constructors: skipped on purpose.
container constructors: ( stack(const Container&) / stack(Container&&) ) , takes C++ deque, so they would need a rust wrapper for a duque first.

push(const T&) and push(T&&) differ only by &/&&. and copy and move constructor already, cover that. So it is skipped.
closes #46

1. Write Rust wrappers for that C++ type, for 3-5 different overloaded method names:
   • Create a new file named after your type in overloading-macros/cpp-overload-test/src/stdcpp
   • Wrap constructors first, writing tests to make sure the correct constructor is called
   • Explain any potential compatibility issues in a Limitations doc section
   • Explain usability issues in an Ergonomics doc section
   • Check that you have implemented all the overloads for each method name, or documented why you can't
   • Push your changes and wait for a review
2. Add a separate example with some failing overloads
   • Create a new file named after your type in overloading-macros/cpp-overload-test/examples
   • Wrap accessor/modifier methods
   • Explain how they fail in an Incompatibilities doc section
   • Explain how the overload failures could be resolved in a Workarounds doc section
   • Optional: If there's a C++ feature with no equivalent in Rust, explain that in an Inexpressible Overloads doc section
   • Push your changes and wait for a review
3. Update the overload macro compatibility table Markdown doc
   • If you haven't checked some kinds of overloads, put a ？in those squares
   • Push your changes and wait for a review

[teor2345]

This is a good start, but it needs a bit more work before stage 2.

[teor2345]

Just a reminder to move on to steps 2 & 3 in the PR description, and make sure they are up to date with your latest code changes.

Applications must be submitted to Outreachy by Monday 9 November, please include this PR and any other Rust PRs you've done in that time.

[teor2345]

Thank you, this looks good.

Please implement steps 2 & 3: failing overloads, and summarising the analysis. The instructions are in the PR description.

Please don't wait for review between them, there are only a few days left before applications are due.

[teor2345]

Please put this next to the code that implements these operations, so the comment can be updated when the code changes

[Siddhi-sahu]

Done 👍. thank you for the review.

[teor2345]

Just reminding you that the Outreachy final application deadline is this Monday 9 November. You can include any Rust PR or ticket work you've done, it doesn't have to be merged yet.

Please submit a final application on the Outreachy website before Monday. The exact deadline is 4pm UTC, but it is better to submit early. You can edit your submitted application up until the deadline (and you can keep working on PRs after the deadline).

[Siddhi-sahu]

@teor2345 thank you for the constant reminders, and support. I will submit my application soon.

You mean, 1. I can list any rust prs I have done during the contribution period, in different projects ?? In "Record a contribution" for this project?
2. and I can keep working on this pr and others, after 9 too?

[Siddhi-sahu]

In the move constructor, I wanted to talk about something. In forward list the move_from , builds the list in two steps:

std::forward_list other_ = std::move(*other);
return new std::forward_list(other_);

and since, other_ has a name , the final list is build by the copy constructor , not the move constructor . In StdStack , I did it in one step :

return new std::stack(std::move(*other));

the test also checks if the source is empty afters, but that check can't tell a move from a copy, here. in forward_list.rs also the source is empty afterwards.
because the step 1 really does moves the items out, so the test pass both ways. and can't really tell a move from a copy.

The task says that the test should show the correct constructor is called, and here the copy constructor build the final list.

is this how its supposed to be ?