Kevin: thank you so much for the extremely detailed response about the different APIs available! [quote='791817022, DTS Engineer, /thread/757382?answerId=791817022#791817022'] Keep in mind that in many cases these APIs are actually best used to complement each other, not as direct replacements. For example, an app might use FSEvents to determine that a large hierarchy "has changed" while there app was not running, then rely on kqueue or Dispatch for realtime monitoring while they are running. [/quote] Interesting, gotcha! Here's a related question: since rust-analyzer is only interested in file change events while the IDE is running (we take deliberate steps to avoid any external, serializable state for a bunch of reasons that I'll elide for now, but I can get into later!), does it still make sense sense to do the layering you describe, or can we reasonably rely on the real-time approaches? For context, I'd group the two types of file events we get as "human-driven" (where a user might create a new file or whatever) or "machine-driven" (where the user switched branches or is rebasing, so we'd see a lot file change events in quick succession). We ran into the most issues with the latter, most commonly in the form of stale diagnostics when fed file change events by VS Code. That is a great question that I'm not (quite) ready to answer yet, but I wanted to reply with what I already had. I'll have more to say about this in the next day or two. Thanks again! I also realized that I didn't clarify the current state particularly well: by switching to using FSEvents via the Notify Rust library, rust-analyzer's reliability during rebases went from "guaranteed to be broken" to "basically works every time". I'm mostly asking if the last few percentage points of reliability are possible/if any potential footguns that we'd inadvertently introduce to macOS users by relying on that directly (e.g., would there be any gotchas with this approach on an NFS-based file system like Eden? are there any potential negative interactions with FSKit-based virtual file systems?)

I created a feedback item FB18543729 with an attached sysdiagnose, if that's of any help!

Thanks so much for the response! clang and rustc (by design on Rust' part, to be clear!) are sufficiently similar that it was pretty easy to translate between C++ and Rust! Your tips/suggestions almost worked for me, except that the binary would be sigkilled'd immediately after launch. I did some rubber-duck debugging using Claude, and it—rather impressively!—pointed out in https://claude.ai/share/5a4ca3ca-9e98-4e2a-b9ae-71b49c6983cf that the entitlement I needed to use was com.apple.security.get-task-allow, not com.apple.security-get-task-allow. Instruments' diagnostic contained a typo! Once I fixed this typo, I was able to use the "Processor Trace" instrument via xctrace. Of course, since this is beta software, which I hit a few bugs, which I'll cover at the end of this post. Apple silicon code must be signed, so the linker automatically applies an ad-hoc signature. You can see this if you dump the hello tool before re-signing it: [dump redacted] If you’re going to re-sign the binary anyway, you can disable linker signing with the -no_adhoc_codesign linker option. I think the Rust compiler sets the adhoc signature somewhere by default, so while I agree it's kinda wasteful to replace it later, it's also not the worst. but it’s not appropriate for a product that you want to ship to a wide range of users Yeah, I figured as such. I'm only really using these adhoc binaries for as part of my local development workflow. The Bugs! Anyways! I promised a few bug reports, here they are! Typo in Diagnostics Instruments and xctrace have a typo in their disagnostics entitlement: they both suggest com.apple.security-get-task-allow instead of com.apple.security.get-task-allow. I spent my morning scratching my head over this. See below for the typo: ❯ xctrace record --template 'Processor Trace' --target-stdout - --launch -- target/dev-rel/deps/hir_ty-f1dbf1b1d36575fe --exact tests::incremental::add_struct_invalidates_trait_solve Starting recording with the Processor Trace template. Launching process: hir_ty-f1dbf1b1d36575fe. Ctrl-C to stop the recording Run issues were detected (trace is still ready to be viewed): * [Error] Processor Trace cannot profile this process without proper permissions. * [Error] Recovery Suggestion: Either: 1. Add the 'com.apple.security-get-task-allow' entitlement to your binary entitlements file, or 2. Make sure the build setting CODE_SIGN_INJECT_BASE_ENTITLEMENTS = YES is enabled when building with Xcode. Recording failed with errors. Saving output file... Output file saved as: Launch_hir_ty-f1dbf1b1d36575fe_2025-07-02_13.39.40_EBCB3760.trace OOMs in Instruments I had to use xctrace record --template 'Processor Trace' --target-stdout - --launch -- hir_ty-f1dbf1b1d36575fe --exact tests::incremental::add_struct_invalidates_trait_solve from my shell instead of launching from Instruments directly, as Instruments ended up using something like 130 GB of RAM, forcing me to restart my Mac. I have only have a paltry 48GB! An Entitlement for Profiling using Hardware Profiling Features Feels Strange I would personally expect that a linker-signed, adhoc binary would imply com.apple.security.get-task-allow. Some additional, assorted thoughts: rustc tends to use the system's C compilers to indirectly drive the linker, which means that if there's some feature that the linker should be doing automatically on said platform, the Rust compiler does it. Given that the Rust compiler produces adhoc-signed binaries by default and I can debug those binaries using lldb without any additional entitlements, I'd expect the same of hardware-supported CPU execution tracing (modulo restarting my Mac), especially if the CPU execution tracing in M4 processors is anything similar to similar to Intel's Processor Trace: https://lldb.llvm.org/use/intel_pt.html. A friend pointed out that your phrasing of "That is, the signature applied by the linker" should have clued me into the fact that there's some linker magic happening with ld_prime. Cards on the table, I think there should be a little more magic happening :D. The new profiling functionality is downright magical. It just works with non-Swift/C/Objective-C languages and I feel like it's a shame that end-users need to become deeply familiar with codesigning to use this incredible set of tooling. Heck, I bought the Mac I'm writing this post on two days ago in order to use this feature! Anyways, thanks so much for your help and let me know if I can provide any additional detail!

Thanks Quinn! Well, that’s an annoying cascade failure. I copied it from you who copied it from Instruments. But, yeah, I shouldn’t have let that slip past )-: Thanks for the heads up. No worries! I should've noticed that and it's my first time seeing a typo in a diagnostic like this. It's not something I expect to see. The best way to get these in front of the folks who can actually enact change is to file them in Feedback Assistant. See Bug Reporting: How and Why? for more on that. Thanks for the information and sorry for not being familiar with the process of reporting bugs to Apple! For the bugs, here are my feedback items: The Instruments OOM: FB18583028. The "adhoc-signed binaries shouldn't need an additional entitlement just to be profiled" feedback item: FB18543729. I submitted both under "Developer Tools & Resources", but I can see an argument for the latter being filed under something closer to "kernel/core OS". Lemme know if you'd like me to file the entitlement feedback there! Except for the Typo in Diagnostics issue. There’s no need for you to file an additional bug about that, unless you want to be notified of the fix. I didn't submit a feedback item for the typo; I think your bug report is sufficient :). I'll just keep an eye on the changelog of future Xcode releases!