Expand debugging problem: Add further background to the documentation.#45
Expand debugging problem: Add further background to the documentation.#45Ajay-singh1 wants to merge 2 commits intorustfoundation:mainfrom
Conversation
…iteria Signed-off-by: Ajay Singh <ajaykripa8736968359@gmail.com>
Ajay-singh1
changed the title
teor2345
left a comment
teor2345
left a comment
There was a problem hiding this comment.
Hi, I appreciate the enthusiasm here, but I'm not sure if we're ready to fill in some of this information in the problem statement yet.
This information has to come from active users of these features. It should be supported by links to documentation, decisions about project goals, and stories of user experiences. The "unresolved questions" section is filled in later, when we've covered most of the problem statement, and know what questions are left over.
If you want to apply for Outreachy, please follow the instructions here to submit a code example for "calling overloaded C++ functions from Rust":
https://rust-lang.zulipchat.com/#narrow/channel/578347-outreachy/topic/project.20-.20Calling.20overloaded.20C.2B.2B.20functions.20from.20Rust/near/581501981
The build system project is closed to new applicants, but you can choose from any of the 3 other Rust projects:
https://www.outreachy.org/apply/project-selection/#the-rust-project
|
|
||
| Rust currently emits debug information that is largely compatible with existing tooling designed for C and C++. However, Rust’s language features—such as enums with rich semantics, pattern matching, and async/await transformations—do not always map cleanly onto these formats. | ||
|
|
||
| As a result, debuggers often fall back to displaying low-level representations of Rust types, exposing implementation details (e.g., discriminants and internal fields) rather than high-level abstractions. |
There was a problem hiding this comment.
How do you know this? Can you link to where you got this information from?
There was a problem hiding this comment.
There was a problem hiding this comment.
It is mentioned on the official documentation.
|
|
||
| In mixed-language projects, these issues are amplified. C++ and Rust use different abstractions and conventions, and there is no unified model for representing types and execution flow across both languages in debugging tools. | ||
|
|
||
| Additionally, Rust’s async model introduces compiler-generated state machines, which can obscure control flow and make stack traces harder to interpret during debugging. |
There was a problem hiding this comment.
Again, this paragraph needs a reference to user experiences or other documentation of what works and what doesn't.
There was a problem hiding this comment.
I'll add a reference to this section of the documentation.
teor2345
added
documentation
question
Removed specific acceptance criteria and unresolved questions related to Rust debugging.
Ajay-singh1
changed the title
2 participants
Summary
This PR improves the debugging problem description for mixed Rust and C++ environments by adding missing sections and clarifying the problem space.
Changes
Motivation
Debugging mixed Rust and C++ programs is currently difficult due to differences in type systems, debug information, and language semantics. Existing tooling often exposes low-level representations rather than meaningful abstractions, making it harder for developers to understand program behavior.
Notes