CI: Enable error on warnings for the extra warnings builds as an experiment. FAQ tweaks

This commit is contained in:
ocornut 2020-03-09 18:55:22 +01:00
parent aef057e975
commit e137db2df7
3 changed files with 27 additions and 13 deletions

View File

@ -171,22 +171,22 @@ jobs:
- name: Build example_null (extra warnings, gcc 32-bit)
run: |
make -C examples/example_null clean
CXXFLAGS="$CXXFLAGS -m32" make -C examples/example_null EXTRA_WARNINGS=1
CXXFLAGS="$CXXFLAGS -m32 -Werror" make -C examples/example_null EXTRA_WARNINGS=1
- name: Build example_null (extra warnings, gcc 64-bit)
run: |
make -C examples/example_null clean
CXXFLAGS="$CXXFLAGS -m64" make -C examples/example_null EXTRA_WARNINGS=1
CXXFLAGS="$CXXFLAGS -m64 -Werror" make -C examples/example_null EXTRA_WARNINGS=1
- name: Build example_null (extra warnings, clang 32-bit)
run: |
make -C examples/example_null clean
CXXFLAGS="$CXXFLAGS -m32" CXX=clang++ make -C examples/example_null EXTRA_WARNINGS=1
CXXFLAGS="$CXXFLAGS -m32 -Werror" CXX=clang++ make -C examples/example_null EXTRA_WARNINGS=1
- name: Build example_null (extra warnings, clang 64-bit)
run: |
make -C examples/example_null clean
CXXFLAGS="$CXXFLAGS -m64" CXX=clang++ make -C examples/example_null EXTRA_WARNINGS=1
CXXFLAGS="$CXXFLAGS -m64 -Werror" CXX=clang++ make -C examples/example_null EXTRA_WARNINGS=1
- name: Build example_null (single file build)
run: |

View File

@ -161,22 +161,35 @@ Interactive widgets (such as calls to Button buttons) need a unique ID.
Unique ID are used internally to track active widgets and occasionally associate state to widgets.
Unique ID are implicitly built from the hash of multiple elements that identify the "path" to the UI element.
- Unique ID are often derived from a string label:
```c
Button("OK"); // Label = "OK", ID = hash of (..., "OK")
Button("Cancel"); // Label = "Cancel", ID = hash of (..., "Cancel")
```
- ID are uniquely scoped within windows, tree nodes, etc. which all pushes to the ID stack. Having
two buttons labeled "OK" in different windows or different tree locations is fine.
We used "..." above to signify whatever was already pushed to the ID stack previously:
- Unique ID are often derived from a string label and at minimum scoped within their host window:
```c
Begin("MyWindow");
Button("OK"); // Label = "OK", ID = hash of ("MyWindow", "OK")
Button("OK"); // Label = "OK", ID = hash of ("MyWindow" "OK")
Button("Cancel"); // Label = "Cancel", ID = hash of ("MyWindow", "Cancel")
End();
```
- Other elements such as tree nodes, etc. also pushes to the ID stack:
```c
Begin("MyWindow");
if (TreeNode("MyTreeNode"))
{
Button("OK"); // Label = "OK", ID = hash of ("MyWindow", "MyTreeNode", "OK")
TreePop();
}
End();
```
- Two items labeled "OK" in different windows or different tree locations won't collide:
```
Begin("MyFirstWindow");
Button("OK"); // Label = "OK", ID = hash of ("MyFirstWindow", "OK")
End();
Begin("MyOtherWindow");
Button("OK"); // Label = "OK", ID = hash of ("MyOtherWindow", "OK")
End();
```
We used "..." above to signify whatever was already pushed to the ID stack previously:
- If you have a same ID twice in the same location, you'll have a conflict:
```c
Button("OK");

View File

@ -203,6 +203,7 @@ From November 2014 to December 2019, ongoing development has also been financial
Dear ImGui is using software and services provided free of charge for open source projects:
- [PVS-Studio](https://www.viva64.com/en/b/0570/) for static analysis.
- [GitHub actions](https://github.com/features/actions) for continuous integration systems.
- [OpenCppCoverage](https://github.com/OpenCppCoverage/OpenCppCoverage) for code coverage analysis.
Credits
-------