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".
Compilation without an associated ScriptHost happens in a call to eval,
in which case we'll fall back to the default warning settings (because
we don't have a location which we could get settings from).
Fixes#1891.
Yeah. Aul looks up function parameters before local variables when
trying to resolve an identifier. Usually this doesn't matter, but you'll
notice it if you have a local variable and a parameter with the same
name, because the variable should be initialized to nil yet you get the
value of the parameter.
This commit introduces a new Aul directive "#warning", which can be used
to enable or disable warnings for a particular piece of code.
"#warning enable" enables all warnings.
"#warning disable" disables all warnings.
"#warning enable empty_parameter_in_call" selectively enables one
specific warning while not affecting any other.
All warnings that used to be controlled by Developer.ExtraWarnings
remain disabled by default.