-
Notifications
You must be signed in to change notification settings - Fork 113
Pragmas Error Emissions
Through the #pragma directive, the errors and warnings emitted by OD can be configured to suit your codebase.
For the current default pragma settings and an up-to-date list of all pragmas, see here
There are many undocumented, strange behaviours within the BYOND implementation of DM and its engine. This project aims to replicate this behaviour as best as we can, in order to maximize your ability to migrate onto our software.
However, much of this behaviour results in code operating in a way that is not what the programmer intended, and not all codebases require all the cursed behaviour in order to successfully run. This creates a design problem: Do we prefer creating an engine that prioritizes parity over sanity, or sanity over parity?
The answer, is "both." Many of the possible errors emittable by the compiler can be enabled or disabled arbitrarily through #pragma directives:
#pragma ErrorDirective warning // Turns #error directives into simple warnings
#error "*deathgasp" // This only creates a warning on-compile.Every possible warning has a name and a code, and can be referenced either way within one of these directives.
The default configuration file is aimed at providing a reasonable version of DM, balancing parity and sanity. Only behaviour that is clearly unintentional is raised as an error. Configuration files for builds that prefer parity, or prefer sanity, are coming soon:tm:.
The following is a (hopefully!) exhaustive list of every error code and its use. If it is incomplete, you can help by expanding it.
Errors with codes less than 1000 are fatal. They cannot be disabled through #pragma directives. Errors of this genre usually are fundamental errors in the grammar of the source code given, making reasonable compilation impossible. In C++ lingo, any code that hits one of these errors is "ill-formed."
This code is the default for errors which have yet to be assigned a proper error code. They are always fatal, and the only information available is the error message you receive upon this error occurring.
This code is emitted when an unexpected Token is reached.
This is emitted when a directive that doesn't exist is used:
#clowns disable // OD0002, directive doesn't existThis code is emitted for keywords that are reserved and cannot be reasonably unreserved.
var/if = 7; // OD0200 - if is hard-reserved and cannot be the name of a variableA generic error to imply that something is missing, such as a variable.
var/y = 5;
x = 3; // OD0404 - the variable x has yet to be definedThis fires when a proc's override is defined, but not the original proc.
/proc/foo() // original
/foo() // override
/poo() // OD0405 - no definition for /proc/poo() foundThis fires if you attempt to override a static, which is ill-formed in DM.
/foo
var/static/x = 5
/foo/bar
x = 6 // OD0406 - cannot override a staticThis is a reserved error for when OpenDream finally implements the HTCPC protocol.
For keywords that SHOULD be reserved, but don't have to be. 'null' and 'defined', for instance.
/proc/foo(null, defined, foobar) // OD2000 - null and defined are soft-reserved and shouldn't be used here. This is valid DM, though.
return null; // Who knows what the heck this returnsThe same variable is defined several times.
var/x = 3;
var/x = 5; // OD2100 - x is already defined!Too many arguments are passed to a native proc. Usually a compiletime or runtime in BYOND.
var/x = sin(5,3,2,1) // OD2200 - Too many args! Agh!A proc attempts to call a parent that does not exist, so the operation does nothing.
/proc/foo()
. = ..() // OD2205 - Pointless call to parentA call to a builtin proc doesn't actually do anything, or does something you may not expect it to.
/obj/var/static/x = 6
/proc/foo()
var/obj/O = new
O.x = 22
var/x = initial(O.x) // OD2206 - Calling initial on a static returns its current value; x becomes 22 here.A range (such as within the case statement of a switch block) is malformed, featuring perhaps-unintended nulls, which will be coerced to 0.
/proc/foo()
var/x = 0
switch(x)
if(null to 22) // OD2300 - Range is malformed, will end up being equivalent 0 to 22
CRASH("I happen!");A range (such as within the case statement of a switch block) is invalid, as it features non-constant values, or strings. If not an error, strings and other non-numeric objects will be transmuted into zeroes. Most of these cases do actually compile in BYOND, so this is a non-fatal error.
/proc/huh()
var/x = "c"
switch(x)
if("a" to "z") // OD2301 - this will become 0 to 0
CRASH("No crash happens!")A set statement has a definition which is invalid, likely because it is non-const. If not an error, the statement will be made equivalent to the last statement run. Since string interpolations like "A string with a [MACRO_CONSTANT]" are non-constant, this can result in unexpected behaviour:
#define WORD "hello"
/verb/hello
set name = "hello there"
set desc = "You use this verb to say [WORD]!" //OD2302 - The description will be set to "hello there"A text macro (\ref, \a, \him, etc) was missing a required interpolated expression.
var/message = "\a vendomat" //OD2500 - This will produce a slightly malformed stringFires if a control-flow keyword is used without its corresponding block. Does not fire for empty functions.
/proc/test()
if(TRUE) // OD3100 - Empty block detected
else
CRASH("The concept of truth has failed")