Skip to content
spookydonut edited this page Apr 4, 2020 · 14 revisions

This is a page for explaining what various errors mean in more depth

Lint directives


General

unknown linter setting SOMETHING

You're using a set SpacemanDMM_SOMETHING = 1 directive that either doesn't exist or only exists in a newer version of SpacemanDMM.

Can't define procs BLANK outside their initial definition

The BLANK directive is only supported in the base/root definition of a proc and you're trying to do it in a child/override of the proc.


should not sleep

PROCNAME sets SpacemanDMM_should_not_sleep but also sets waitfor = 0

Should not sleep procs are meant to not use any blocking calls, but using set waitfor = 0 is intended for procs that do use blocking calls, these two things are not compatible.

PROCNAME sets SpacemanDMM_should_not_sleep but calls blocking built-in(s)

Fairly straight forward, should not sleep procs aren't allowed to call blocking built-ins such as sleep() or input(), it will list where and what is called that are considering blocking calls.

PROCNAME sets SpacemanDMM_should_not_sleep but calls blocking proc {}

Similar to the previous one except this is where the proc calls a user-defined proc that fails the above test.


should be pure

PROCNAME does impure operations

This proc does something that has a lasting effect such as setting non-local vars or sending user output, it will list where each purity-breaking operation is.

PROCNAME sets SpacemanDMM_should_be_pure but calls a {} that does impure operations

As above, calling a user-defined proc that breaks purity.

call to pure proc PROCNAME discards return value

Since pure procs have no lasting effects, calling one without doing something with the return value is pointless.


private/protected

field VARNAME on TYPE is declared as private

field VARNAME on TYPE is declared as protected

TYPE overrides private var VARNAME

proc overrides private parent, prohibited by PROCNAME

PROCNAME1 attempting to call private proc PROCNAME1, types do not match

PROCNAME1 attempting to call protected proc PROCNAME2


should not override / final

TYPE overrides final var VARNAME

proc overrides parent, prohibited by PROCNAME


should call parent

proc never calls parent, required by PROCNAME


proc settings

unknown setting SETTING

Something is using set __SETTING__ and SETTING isnt in the byond documentation.

set SETTING must be 0/1/TRUE/FALSE

set SETTING must have a string value

set invisibility must be 0-100


Unreachable code detection

possible unreachable code here

This code likely can't be reached because it's after a return or a control structure excludes it

loop condition is always true / loop condition is always false

control flow condition is a constant evalutation

control flow condition is a static term

do while terminates without ever reaching condition

The do while loop always calls return/break/continue without it ever being possible to complete a single loop

unreachable if block, preceeding if/elseif condition(s) are always true

if condition is always true / if condition is always false

unreachable else block, preceeding if/elseif condition(s) are always true

for range loop body is never reached due to invalid range

You have a range loop and have likely done something like an inverted step that prevents the loop ever running


dreamchecker

ambiguous __BLANK__ on left side of an in

You likely have !something in alist which is parsed/compiled as (!something) in alist, add brackets to fix this -> !(something in alist)

The same also applies to foo && bar in alist and similar

undefined var: VARNAME

failed to resolve path PATH

A prefab is failing to resolve, this software does not support .procname syntax due to lengthy reasoning, in most cases changing it to .proc/procname will resolve the issue. This searches from the current path of the proc upwards.

If that doesn't work you will need to explicitly define where the procpath or similar is, eg /mob.proc/someproc

This can also occur when calling new with an invalid prefab/path

undefined proc: PROCNAME on TYPE

proc has no parent: PROCNAME

Calling parent ..() on a parentless proc does nothing.

no type hint available on implicit new()

This is raised when you call new with no type provided and no typehint on the var is provided either, for example var/foo = new

couldn't find TYPE/proc/New

This occurs when using new on a type and that type for some reason does not have a /New() proc, excluding /list

Mostly applies to built-in types that don't inherit from /datum

undefined field: VARNAME on TYPE

field access requires static type: VARNAME / proc call requires static type: PROCNAME

This is a type safety check to avoid the careless/silent use of : (runtime search operator) over . (compile time search operator)

In certain situations even when you use ., byond will silently use :

// 1
foo.field // this uses .
// 2
proc/foo()
    return new /a/type
[...]
foo().field // this uses :
// 3
var/list/foo = list(new /a/type)
[...]
foo[1].field // this uses :

So dreamchecker will raise a warning where it cannot find type information on the thing you are trying to access a var/proc on. It will give you a link to the var/proc definition so you can explicitly provide a typehint. eg add a type annotation after /list here

So to fix the above examples you could do the following;

// 2
proc/foo()
    set SpacemanDMM_return_type = /a/type // see dreamchecker readme for a macro

// 3
var/list/a/type/foo = list(new /a/type)

undefined proc: PROCNAME on TYPE

Attempting ++/-- on a TYPE which does not overload ++/--

If you don't overload ++/-- on a type by doing eg /a/type/proc/operator++() then using ++/-- on a var of that type will change the reference to 1/-1 which is likely a massive bug.

This can also trigger if you provide a typehint on a list where you shouldn't. If only the key for that list is of the type, then it doesn't need that typehinted for that list.


Filters

filter(type="{}") '{}' parameter must have one value, found bitwise OR

Some filter parameters can't have more than one flag at a time.

filter() flag fields cannot have unary ops

filter(type="{}") called with invalid '{}' flag '{}'

Check the dm reference to make sure you are using the right flags with the right filter.

filter(type="{}") called with invalid '{}' value '{:?}'

You can't set some filters' flag type var to 0

filter(type="{}"), extremely invalid value passed to '{}' field

This is a catch-all error, please let spookydonut#6995 on discord know if you get this and provide examples

filter() called without mandatory keyword parameter 'type'

filter() called with non-string type keyword parameter value '{:?}'

filter() called with invalid type keyword parameter value '{}'

filter(type="{}") called with invalid keyword parameter '{}'


Proc arguments

bad keyword argument ARGNAME to PROCNAME

You are trying to use a keyword argument that doesn't exist, for example;

/proc/foo(one, two)
[...]
foo(three=3)

This can also occur if the keyword argument is defined on an override of that proc, but not where that override would be used, for example;

/mob/proc/foo(one, two)

/mob/proc/test()
    foo(three=3)

/mob/living/foo(one, two, three)

To fix this, add the missing keyword argument to that proc.

proc called with non-kwargs after kwargs: PROCNAME()

You can't use positional arguments after keyword arguments, foo(three=3, 2). This will compile but will runtime.

an override of PROCNAME is missing keyword args / NUM overrides of PROCNAME are missing keyword args


Parsing

inconsistent indentation: {} % {} != 0

Your indentation needs to be a multiple of the first indent encountered, so if you first indent with 2 spaces all further indentation for that proc needs to be a multiple of 2, 5 spaces would result in this error

inconsistent multiple indentation: {} > 1

You also need to step your indentation one multiple at a time, you can't go from 2 space to 6 spaces.

still skipping comments at end of file

Reached the end of the file with an unclosed /*, check for a missing */

precision loss of integer constant: "{}" to {}

bad base-{} integer "{}": {}

bad float "{}": {}

unterminated resource literal

unterminated string literal

unterminated raw string

unterminated raw string terminator

empty raw string terminator

illegal byte 0x{:x}

if you write a character that can't be part of a token eg 0x$1

got EOF, expected one of: {}

got '{}', expected one of: {}

path started by '{}', should be unprefixed

path has no effect

path separated by '{}', should be '/'

nested absolute path: {} inside {}

relatively pathed type defined here

relatively pathed proc defined here

'var/' is unnecessary here

You don't need to use var/ in proc arguments

'static/' has no effect here

static does nothing in proc arguments

for-list must start with variable

for-in-list must start with variable

switch case cannot be empty

'var' must be followed by a name

var/tmp has no effect here

var/SpacemanDMM_final has no effect here

var/SpacemanDMM_private has no effect here

var/SpacemanDMM_protected has no effect here

'as' clause has no effect on local variables

missing else arm of conditional operator should be replaced with 'null'

applies to ternary where you don't have anything after the :

bad locate(X in Y), should be locate(X) in Y / bad 'locate(x, y, z) in'

locate() does weird/wrong things if you do this

'()' should be replaced with 'null'

empty ()

duplicate #include {:?}

macro {:?} used immediately before being {}:\n\https://secure.byond.com/forum/?post=2072419

only the last parameter of a macro may be variadic

malformed macro parameters, expected name

malformed macro parameters, expected comma

macro redefined: {}

macro undefined while not defined: {}

expanding {:?} would exceed max recursion depth of {} levels

can't stringify non-argument ident {:?}


input()

'as' clause should precede 'in' clause, and is being ignored

bad input type: '{}'


Object Tree

TYPE redeclares var VARNAME

not allowed to change {}/parent_type

bad parent_type: {}

bad parent type for {}: {}

proc looks like a var

duplicate definition of {}/{}

override of {}/{} precedes definition

DM really does reorder the declaration to appear before the override, but only when a /proc block appeared somewhere prior to the override. http://www.byond.com/forum/post/2441385 Correctly implementing the "existence of a /proc block" check would be too onerous, so let's assume the user wrote something that they expect DM to compile.

var must have a name / proc must have a name

var looks like a proc

proc name must be a single identifier (spurious {:?})

Clone this wiki locally