No functionality change. I can probably just submit this with no review, but given that I don't have too many patches yet, i'll err on the side of caution.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Have you looked at the commit history of why this was present in the first place? Given that there's not much you can /do/ with a MutexGuard, I'm guessing the original author had it this way to indicate which functions had to be called with a MutexGuard already owned... - a poor man's thread safety check, as it were.
Not that I necessarily agree, but might be useful to understand (if it had previously had a use and was since removed, or at least the person who added it (assuming it was added for the reason I guessed above) is long gone, or if they're a current contributor maybe check with them to see why it was there)
But that's up to you - I'd probably be happy committing this without doing that work & happy to sign off on you doing the same. Maybe at least add comments to the functions you're removing the parameter from to document the precondition that the lock must be held, or maybe you could even add clang's thread safety attributes... (which would also mean turning on the warning in the build systems, etc, probably... blah blah blah)
The previous revision goes back over 8 years, and the commiter (Reid Spencer) doesn't seem to be active anymore. I thought about adding some comments to the methods, but really that comes down to adding a comment to every method of ExecutionEngineState, because those are all the methods that this dummy-parameter was being passed to. In other words, access to the entire ExecutionEngineState object is serialized. But this is already clear IMO because that is actually the whole purpose of the class, as described by the comment at lines 56 and 57 of ExecutionEngine.h
Fair enough. Sounds good to me then. It's not like, even if it is that idiom, it's one we subscribe to with any consistency in LLVM so it seems of little value.
(for my money, one day, we'll have a safe<T> (I'm sure there are already better names for this, probably under standardization as we speak) where you access it only by passing in a lambda:
s.do_stuff([](T& t) { ... });
so you can't forget to lock it, the safe<T> acquires a lock, then calls the lambda with the underlying object and the lock held. Short of leaking the T out there, you can't go far wrong)