Allow to track multiple alloc-ids, call-ids and pointer tags #2075
Conversation
|
☔ The latest upstream changes (presumably #2071) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Thanks for the PR! I'll try to review it soon, but I am also flying overseas today and still need to pack my stuff so things might get delayed a bit. In case of a conflict, please do a rebase -- we'd like to not have merge commits inside PRs. |
|
No problem, i havent made that many changes, so resolving any conflicts is not too difficult. Sorry, i did not know that you are using rebases in this repo, i read about it in the rustc dev guide, but the contribution guidelines did not mention it and i am not used to using rebase. Should i do something about the merge commits (like try to rebase and resolve again)? |
|
Yeah we follow the same procedures as rustc, generally speaking. Rebasing will require you to resolve the conflicts. So if you follow the dev guide you should be good. :) |
|
So should i leave the current commits or delete them and then resolve the conflicts using rebase? |
|
Once you are done there should be a single commit with your changes. |
|
Ah now i think i get it, i did not create a branch in my fork, does anything break if i branch of |
|
Eh, I don't quite know what you mean. You can do all the rebasing locally until your local state is just one commit on top of the |
|
This looks solid, I just have some minor nits. :) Thanks a lot! |
- Changed arg parsing to handle comma seperated list of `u64`'s.
- Changed type and field names of config, executor and global state
to hold a set of tracked ids.
- Adjusted Readme:
- explained list format
- arguments do not overwrite, instead append
- no effect on duplication
- Created a parsing function for comma separated lists
- Added error printing to alloc_id parsing
|
Nice. :) I just did a last tweak that I did not notice the first time around. @bors r+ |
|
📌 Commit b472ef5 has been approved by |
|
☀️ Test successful - checks-actions |
|
This PR produced a ~8% performance regression because it degrades inlining, particularly of |
|
Ouch, good catch. Can you open an issue for that? |
Closes #2073.