The parser was only checking that the passed setting matched the
beginning of the expected keyword, instead of checking for the full
length. This way, users could write "#warning e" instead of the
expected "#warning enable" and still have it work.
When no parameter followed the "#warning" pragma, because the end
iterator would be located before the begin iterator, basic_string's
constructor would throw std::length_error. Check for this case
beforehand so we can throw the expected C4ParseError instead.
operator void* is a quick and dirty workaround for the lack of
explicit operator bool in old C++ standards. Since we can use
explicit operator bool now, we don't need the operator void*
anymore.
Incidentally, that operator also allowed C4Set to equality compare
C4Property entries, which is unintuitive. Replace it with an
explicit specialization of C4Set::Equals.
C4Set used to set its removed elements to nullptr. This requires
some special handling from non-pointer entries like C4Property.
Overwriting the element with a zero-initialized one removes this
requirement, leading to improved type safety on the part of
C4Property.
As the timer tends to run more than once, you'd also very likely get the
error more than once. The timer also often determines the effect
lifetime, making a broken effect live forever.
This was especially annoying with one-off Schedule() invokations
that wouldn't even stop throwing errors after finishing the
designated number of repeats. Although fixing just that script
function would have been possible, I believe that a more general
solution for all effects is useful.
We already notified the user on warning/error that the mistake
happened in a different script than the one we were currently
compiing. It's not too difficult to figure out whether that other
script was added due to an #include or an #appendto directive, so we
can just show the user which one it is.
We also don't show warnings in #include'd scripts anymore, since
they get compiled individually anyway and all warnings will show up
there. This way we don't duplicate warnings several times.
When we introduce block scoping, using variables declared in a more
narrow scope from a block with wider scope will fail. Warn about
these so people can avoid it and fix their code.
While I do not agree with the idea of using straight assignments in
the condition of a for loop, people are divided on the argument and
lots of old code uses it.
FatalError(Format(...)) was necessary previously. Actually it seems not
like a huge thing, but being able to format the string directly in
FatalError is a lot more convenient.
This introduces a new diagnostic (suspicious_assignment) which
issues when an the compiler finds an assignment either where a
condition is expected or as the parameter to return.
The crypto "library" only consists of a single function at the
moment because that's all that users have asked for so far. It is
also highly experimental. We will make an attempt to keep the public
interface (i.e. the interface provided by Library_Crypto.c) stable,
but it might still change if necessary. The internal interface
(provided via the global _Crypto proplist) is not for public
consumption and will probably change at some point.
var a = {B=1}; var b = new a {B=1}; would include "B" twice in the list of properties.
This lead to an actual issue when calculating component value for repairing buildings
Objects will be incinerated by incendiary material (which before was only possible by using ContactIncinerate).
local MaterialIncinerate = true; - object will burn in lava not from other burning objects.
Having the ctor defaulted confuses MSVC 2015 and makes it not use the
templated ctor below even for calls with a parameter list,
thus skipping required initialization.
A follow-up on a previous PR GH-41. The discussion in the forum can be
viewed at http://forum.openclonk.org/topic_show.pl?pid=33086.
Run clang-tidy (without auto, pass-by-value and using checks) to fix the
header files not modified in the previous PR.
Summary of the changes:
- C++11 member initialization.
- nullptr instead of 0 for pointers.
- override for functions declared virtual in base class.
- default trivial special member functions
Consolidate the include statements scattered across the code in accordance
with the comment in C4Include.h. The advantages are listed in the same
comment.
Furthermore, it follows llvm-include-order which is the logical
extrapolation of the project's style guideline wherever possible
(C4Include.h being the most-frequent exception).
The optimizer is going to remove dead code anyway, and has the
additional advantage of doing syntax checking, so the code won't
silently break when someone changes something.
Instead of "Compiler" and "Decompiler", which make me look up what's
even going on each time I see them, use the standard terms "serializer"
and "deserializer".
Nicolas Hake