Skip to content

Upgrade to CXX20#11423

Open
mitchute wants to merge 9 commits intodevelopfrom
cxx20
Open

Upgrade to CXX20#11423
mitchute wants to merge 9 commits intodevelopfrom
cxx20

Conversation

@mitchute
Copy link
Collaborator

Pull request overview

This can be a throw away PR if needed. Spending a bit of time exploring what is needed to upgrade beyond CXX17.

Description of the purpose of this PR

Pull Request Author

  • Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
  • Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
  • Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
  • Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
  • If any diffs are expected, author must demonstrate they are justified using plots and descriptions
  • If changes fix a defect, the fix should be demonstrated in plots and descriptions
  • If any defect files are updated to a more recent version, upload new versions here or on DevSupport
  • If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
  • If structural output changes, add to output rules file and add OutputChange label
  • If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies
  • If adding/removing any output files (e.g., eplustbl.*)
    • Update ..\scripts\Epl-run.bat
    • Update ..\scripts\RunEPlus.bat
    • Update ..\src\EPLaunch\ MainModule.bas, epl-ui.frm, and epl.vbp (VersionComments)
    • Update ...github\workflows\energyplus.py

Reviewer

  • Perform a Code Review on GitHub
  • If branch is behind develop, merge develop and build locally to check for side effects of the merge
  • If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
  • If feature, test running new feature, try creative ways to break it
  • CI status: all green or justified
  • Check that performance is not impacted (CI Linux results include performance check)
  • Run Unit Test(s) locally
  • Check any new function arguments for performance impacts
  • Verify IDF naming conventions and styles, memos and notes and defaults
  • If new idf included, locally check the err file and other outputs

@mitchute
Copy link
Collaborator Author

Anything worth reviewing up to this point is contained in bd870fd and 9d1519f

@mitchute mitchute self-assigned this Feb 19, 2026
@mitchute mitchute added Developer Issue Related to cmake, packaging, installers, or developer tooling (CI, etc) Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring labels Feb 19, 2026
@mitchute
Copy link
Collaborator Author

OK, I think we're building with CXX20 now.

17e6c17 can probably be ignored. This is just fully qualifying most of the format statements with EnergyPlus:: so they don't conflict with std::format that is now available. Similar changes in the remaining commits can also likely be ignored.

Assuming there is agreement to move forward here, I would propose this gets merged soon. We can then slowly begin to migrate EnergyPlus::format and fmt::format over to usestd::format which will require us to move away from the Fortran string format syntax. Diffs resulting from these transitions can then be dealt with in a piecemeal fashion.

@mitchute
Copy link
Collaborator Author

Other things to note: fmt-8.0.1 and Eigen were patched. The first doesn't matter really since I think want to get rid of it anyway, and Eigen will probably be updated when kiva eventually gets upgraded.

@jasondegraw
Copy link
Member

@mitchute It looks like most of the changes in "E+ proper" are to formatting operations. Is that correct? I guess the only question I have is if this would complicate anything on less-standard platforms.

@mitchute
Copy link
Collaborator Author

That’s correct.

By “less standard” are you referring to Red Hat or some other HPC environment?

@jasondegraw
Copy link
Member

@mitchute Yes, but also I recall that there was some cut-down environment that was getting used to build the code for Python packaging purposes. Not sure what all happened with that.

@mitchute
Copy link
Collaborator Author

@jasondegraw it looks like manylinux_2_28 uses GCC 14, which has full C++ 20 support. manylinux_2_28 is in ELTS, and given that there are a number of newer versions available, I'm not expecting any issues related to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Developer Issue Related to cmake, packaging, installers, or developer tooling (CI, etc) Refactoring Includes code changes that don't change the functionality of the program, just perform refactoring

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants