[[noreturn]] is supported on all the compilers we support. Still need to decide
the exact minimum versions and figure out what to do with DEPRECATED and FALLTHROUGH,
so leaving those for now.
And since we require VS 2015 and up we can enable C99 unconditionally.
This also covers handling of legacy DescriptionWML for [set_menu_item],
and tweaks its handling in the other cases (mainly [multiplayer_side]).
I added the next_dev_version constant intending to use it, but then
decided not to do so; however I left it in in case someone finds it useful.
* Dropped unused CVideo class member references.
* Replaced the lone usecase of the CVideo member in loadgame with the singleton and removed said member.
* Removed CVideo references from a bunch of addon management functions.
* Cleaned up a *lot* of now-unnecessary forward CVideo declarations.
This a two part commit. First:
----------------------------------------------------------------------------------------------------
Added and deployed two new helper macros for the standard implementations of the static execute
and display functions. I also made use of a variadic template in order greatly simplify code
maintenance. Now, even if the dialog's ctor parameters change, no one has to worry about updating
the associated execute/display functions (though of course, this only applies if the helper macros
are used). \o/
I did not deploy the macro in cases where there were multiple overloads or the functions did more
than just show their dialogs. I might add an additional __VA_ARGS_ parameter to the macros later.
Do note for the end_credits dialog I moved the default empty-string parameter from the display
function to the ctor.
Second:
----------------------------------------------------------------------------------------------------
Another change is that modal_dialog::show and modeless_dialog::show no longer take CVideo arguments.
Since the video argument couldn't be included in the parameter pack (maintaining the argument would
have meant making it the first one, which would be just as much work), and using CVideo::get_singleton
in the macros would require adding video.hpp includes in a whole bunch of files, I simply removed the
argument. I had been intending to do this for a while anyway.
This therefor also removes the CVideo argument from:
* All dialog display/execute functions.
* modal_dialog::show
* modal_dialog::build_window
* modeless_dialog::show
* modeless_dialog::build_window
* wml_exception::show
* gui2::show_message
* gui2::show_error_message
* gui2::show_transient_message
* gui2::show_transient_error_message
* gui2::show_wml_message
* gui2::build
* gui2:🪟:window
* gui2::dialogs::tip::show
* Various GUI2-related Lua functions. The video_dispatch helper was also removed.
* Any functions that took a CVideo argument for the sole purpose of passing it to one of the above.
Ya know, all these damn CVideo arguments didn't actually do anything, besides an occasional check to
CVideo::faked. At the end of the pipeline, they just got assigned to the video_ member of gui2::window.
Huge code bloat for nothing.
Turns out I mistook @celticminstrel's opinion that we should use include guards over pragma (737916e).
Since all major compilers support `#pragma once`, there's no reason not to use it.
For future mergability reasons, this excludes src/spirit_po and src/xBRZ. It also excludes src/boost-patched.
This file seemed to be some sort of reimplementation of <cassert> except
with some "feature" of trying to force the debugger to hit a breakpoint.
However, any decent debugger already hits a breakpoint with a standard
assert(), and this file really only served to make it harder to see the
actual error when using a Windows console.
Some instances of these macros were replaced with assert(), others with
VALIDATE() which instead throws an exception (and possibly puts up a
dialog, if the exception is caught before main()).
A few other related changes that got mixed in:
- Several error conditions now have a better error message (or indeed
any error message at all)
- Removed an unnecessary use of std::distance on a Boost iterator range.
- Removed a large chunk of code which did nothing but construct a widget
builder and then crash; the code was unreachable since an earlier loop
did the same thing (without crashing), and the comment seems to suggest
that it was a (seemingly no longer necessary) workaround for some buggy
compilers / linkers.
- noreturn added to the list of compatibilty C++11 features in global.hpp
(Of supported compilers, only VC12 lacks the new [[attribute]] syntax.)
- Fix detection of GCC in global.hpp
# Conflicts:
# src/gui/widgets/settings.cpp
In some contexts the compiler may warn since the wml_exception has no
attribute indicating it will never return. The answer is throwing a
dummy exception.
These macros allow to throw an wml_exception without any condition. This
can be used when a code path is reached that should be unreachable with
valid WML.
This how I originally designed the class and how it should behave. This
reverts 2011-01-26T07:30:35Z!guillaume.melquiond@gmail.com and reintroduces bug #17577. There are two
issues when used in combination with Lua:
- Our Lua wrapper crashes when catching this exception (to be fixed in my next
commit.)
- When our Lua wrapper no longer crashes the error message is lost. (I have an
idea how to fix it, but it is much easier to test when this change is
committed.)
Added the code here instead of in the config object, to avoid dragging
more stuff in the core libraries. The deprectated warnings are only used
for the game stuff, so no need to put it in the server as well.
Implemented sticky exceptions that can be rethrown at will.
Used them to ensure that quitting the game, loading a new game, and
leaving to title screen, work correctly when WML is being executed.
