This is an archive of the discontinued LLVM Phabricator instance.

Trivial patch that cleans up some function signatures from unused parameters.
ClosedPublic

Authored by zturner on Jun 16 2014, 1:31 PM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

zturner updated this revision to Diff 10455.Jun 16 2014, 1:31 PM
zturner retitled this revision from to Trivial patch that cleans up some function signatures from unused parameters..
zturner updated this object.
zturner edited the test plan for this revision. (Show Details)
zturner added reviewers: chandlerc, rnk, dblaikie.
zturner set the repository for this revision to rL LLVM.
zturner added a subscriber: Unknown Object (MLST).
dblaikie accepted this revision.Jun 16 2014, 1:38 PM
dblaikie edited edge metadata.

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)

This revision is now accepted and ready to land.Jun 16 2014, 1:38 PM

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

In D4162#8, @zturner wrote:

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)

zturner closed this revision.Jun 16 2014, 2:02 PM
zturner updated this revision to Diff 10457.

Closed by commit rL211054 (authored by @zturner).