ID:86021
 
Resolved
Fixed in 460
BYOND Version:457
Operating System:Windows XP Home
Web Browser:Firefox 3.5.5
Status: Resolved (460)

This issue has been resolved.
Descriptive Problem Summary:
When trying to #define a macro with an argument, if you use the # character as part of a complicated string, DM will refuse compilation and return the error "error: # has no argument".

Code Snippet (if applicable) to Reproduce Problem:
#define BUGGY(X) world << {""#5""}
BUGGY(null)

// An example of actual usage:

#define LINE(MSG) world << {"<span style="color:#800">[__FILE__]:[__LINE__] [MSG]</span>"};
LINE("This will result in an error")


Expected Results:
Compiles fine, and outputs "#5" to the world whenever encountered.

Actual Results:
Compilation stops with error:
"error: # has no argument"

Does the problem occur:
Every time? Or how often? Every time
On other computers? Not attempted

When does the problem NOT occur?
When any part of the above macro definition is missing. The #, a number, the quotes, and the text document {""} all need to be part of the string, and the macro must be defined as taking an argument.

Did the problem NOT occur in any earlier versions?
Not attempted in older versions.
Heres something weird

loading Terminal.dme
Code\Tile.dm:1:error: unknown directive 5 7

Terminal.dme:21:error: # has no argument

Terminal.dmb - 0 errors, 0 warnings

The count shows 0 errors, 0 warnings

and after doing a few tests it does not seem to count preprocessor errors.


And you get whole new errors is you stack the #

#define BUGGY(X) world << {""######""}
Code\Tile.dm:9:error: unterminated text (expecting ")
Code\Tile.dm:9:error: bad repeat count


After extensive testing I figured out what kind of argument it wanted

#define BUGGY(X) world << {""#X""}

Apparently using "#var" inserts the value into the macro like [X] would
No, it's not quite like "[X]". Try this:

#define TEST(X) #X

mob/verb/Test()
src << TEST(1+2)
src << "[1+2]"

It's a bit undocumented, but it replaces itself with what was typed for that parameter, as a string.
Then maybe the bug is more along the lines of this not being escape-able? With a \
Also lack of documentation...
Edit:
And a lack of counting preprocessor errors.
Bug fix: The preprocessor did not recognize the expanded string format {"..."} when defining a macro.