Fix: Resolve compilation failure in F14Table.h due to two-phase lookup
Hi, this PR fixes a compilation issue in folly/container/detail/F14Table.h.
Bug Description
When building Folly with a modern g++ toolchain, the compilation fails with multiple errors related to occupiedMask.
Environment:
- OS: Ubuntu 24.04
- g++ version: 13.3.0
- CPU: Intel(R) Xeon(R) E-2286M CPU @ 2.40GHz
Key Error Message:
/root/folly/folly/container/detail/F14Table.h:821:37: error: there are no arguments to 'occupiedMask' that depend on a template parameter, so a declaration of 'occupiedMask' must be available [-fpermissive]
821 | return DenseMaskIter{&tags_[0], occupiedMask()};
| ^~~~~~~~~~~~
Root Cause
The error is a classic C++ two-phase name lookup problem. Inside the F14Chunk<ItemType> template, functions like occupiedIter() call occupiedMask() without any qualification. Because occupiedMask is a member function of F14Chunk, its existence depends on the template parameter ItemType. According to the rules, the compiler needs to be explicitly told that occupiedMask is a dependent name, which g++ 13.3.0 correctly enforces.
The Fix
The solution is to explicitly qualify the calls to occupiedMask with this->. This informs the compiler that occupiedMask is a member of the template instance and its lookup should be deferred to the instantiation phase.
This change is applied to all calls to occupiedMask within F14Chunk in folly/container/detail/F14Table.h.
How to Test
The fix can be verified by successfully compiling the folly_base target in the described environment (Ubuntu 24.04, g++ 13.3.0) where the build was previously failing. All existing tests should continue to pass.
Thanks for your review!During compilation with certain toolchains (e.g., g++), the build fails with an "'occupiedMask' was not declared in this scope" error inside the F14Chunk template class.
This is caused by C++'s two-phase name lookup rules for templates, where non-dependent names are resolved during the initial template parsing. The compiler fails to find 'occupiedMask' as it is a member of a dependent base class.
This commit resolves the build failure by explicitly qualifying the member function calls with 'this->', correctly hinting to the compiler that 'occupiedMask' is a dependent name that should be looked up during template instantiation.
Hi @ihb2032!
Thank you for your pull request and welcome to our community.
Action Required
In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.
Process
In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.
Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.
If you have received this in error or have any questions, please contact us at [email protected]. Thanks!
Hi, I'd like to gently follow up on this PR. It appears the CI checks are awaiting approval. Could a maintainer please help approve and run the CI workflows? Thank you!