Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Summary: The MSVC STL implementation of `std::atomic` has a non-trivial but `constexpr` default constructor, because it value initialises the member. On older versions of MSVC there was a bug in the compiler implementation where `constexpr` constructors would generate dynamic code and so a workaround was added to the STL to make the `std::atomic<T>` default constructor trivial (by removing value initialisation of `T`). This has been fine so far because the bug and workaround have remained. However, in a recent version of MSVC, the bug was fixed and the `std::atomic` constructor was returned to being non-trivial. With this change, `ManagedStatic` now has a non-trivial, non-constexpr, default constructor, since it attempts to zero initialise `Ptr`. This means that `ManagedStatic` is being dynamically initialised. This leads to the following initialisation order problem: `ManagedStatic` lazily initialises its `Ptr` member when it is first used. If `ManagedStatic` gets used before it has been initialised (say, in the constructor of some other static), then the `Ptr` member will first get set, and then subsequently zeroed out. This breaks the LLVM command line parser, which relies on `ManagedStatic`. It also breaks Hermes builds, because we run `hermesc` during the build process to compile the internal bytecode. The fix is to just add a `constexpr` constructor for `ManagedStatic` for new versions of MSVC, and non-MSVC compilers (for when they are using the MSVC STL). However, because of the issue with `constexpr` constructors on old versions of MSVC, keep the old behaviour there. This diff copies https://reviews.llvm.org/D80433 to LLVH. Reviewed By: tmikov Differential Revision: D25139806 fbshipit-source-id: 8f0b97a6f5824dca39acf3a1cb96a6fa4c7f6b02
- Loading branch information