Skip to content

[swift-inspect] Expose task completion flag #80184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

kastiglione
Copy link
Contributor

@kastiglione kastiglione commented Mar 20, 2025

Depends on #80183.

@kastiglione
Copy link
Contributor Author

@swift-ci smoke test

@kastiglione
Copy link
Contributor Author

oh wait, I bet I need more plumbing…

@kastiglione
Copy link
Contributor Author

yep, I missed swift_reflection_asyncTaskInfo.

From #77167 (review):

We should probably add things to the C interface as well, but that's harder since we don't want to break the ABI. Not sure what the best approach is there, we can add a swift_reflection_asyncTaskInfo2 with the new stuff, but that could grow a lot of variations.

@kastiglione kastiglione reopened this Mar 20, 2025
@mikeash
Copy link
Contributor

mikeash commented Mar 21, 2025

Adding a new struct and a new function every time we want to add a field is going to be a pain.

I'm thinking, for new C Remote Mirror APIs, we should switch to returning a pointer to a struct instead of a struct. We have allocateTemporaryObject in the wrapper code to make it easy to return a pointer that's valid until the next call. Then we can add fields to existing structs returned in this manner without breaking old clients. We can put a version number at the front of each one so that new clients know which fields are valid and which should be ignored. We'll still need a 2 variant for this call, and any others which we want to evolve, but at least it would stop there.

Alternatively, we could have the caller pass a buffer and a size, and we fill out as much of the struct as will fit. This would be more awkward to call but maybe a bit more efficient.

@kastiglione
Copy link
Contributor Author

kastiglione commented Mar 21, 2025

That sounds like a good solution @mikeash.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants