Add _reentrancyGuardStorageSlot()

[EricForgy]

Fixes #5681 for ReentrancyGuardTransient.

This PR introduces a pure virtual function _reentrancyGuardStorageSlot() in ReentrancyGuardTransient.sol, mirroring the pattern used in the upgradeable Initializable.sol

Motivation

As discussed in #5681, storage slot collisions can occur when using OpenZeppelin contracts in delegatecall-based modular systems (e.g., the Diamond Standard). While this issue was originally raised in the context of upgradeable contracts, ReentrancyGuardTransient.sol in the non-upgradeable repo is in fact already upgrade-safe due to its use of a named storage slot.

Adding _reentrancyGuardStorageSlot() as a pure virtual function allows advanced users to override the default slot location safely in derived contracts, which is essential when using multiple delegatecall modules that each instantiate ReentrancyGuardTransient.

Summary of Changes

• Introduced _reentrancyGuardStorageSlot(), marked internal pure virtual
• Replaced all direct uses of REENTRANCY_GUARD_STORAGE with calls to this new function
• No behavioral or storage layout changes; fully backward-compatible

[changeset-bot]

🦋 Changeset detected

Latest commit: 750a60b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openzeppelin-solidity	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[gonzaotc]

Approved, I consider allowing storage slot overridability while keeping the formula pure a good tradeoff between flexibility and security, as mentioned in #5681 (comment). Additionally, we will work on the transpiler to ensure this same pattern is correctly applied across the upgradeable contracts.

[Amxx]

While this looks good, I'd like to consider a different approach. See #5681 (comment)

[Amxx]

Suggested change

	Add `_reentrancyGuardStorageSlot()` to `ReentrancyGuardTransient` as a `pure virtual` function to allow slot overrides for diamond-compatible modular usage. Related to #5681.
	`ReentrancyGuardTransient`: Add `_reentrancyGuardStorageSlot()`, a `pure virtual` function, that can be overriden to allow slot customization.

[Amxx]

Should that be

• _reentrancyGuardStorageSlot()
• _reentrancyGuardTransientSlot()
• _reentrancyGuardTransientStorageSlot()

Here, the contract only uses transient, but what if a contract combined transient and normal storage ? Would we want the two types to use the same slot, or would we allow separating the two ?