BYOND Version:512.1488
Operating System:Windows 10 Home 64-bit
Web Browser:Firefox 70.0
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
The Dream Maker's compiler fails to read the file specified in an #include if the file specification ends with the line terminator character(s).

Numbered Steps to Reproduce Problem:
1. Create two .dm files. Don't include both from the .dme.
2. Include one of the .dm files in the other.
3. Include the dm file containing the include.
4. Make sure that the file end chars are on the same line and there are no comments after it.

Code Snippet (if applicable) to Reproduce Problem:
// File
#include ""<CR/LF>

// File
// Do something...

Expected Results:
Compiler treats the line terminator as whitespace

Actual Results:
Compiler treats the line terminator as an actual character part of the "" argument.

Does the problem occur:
Every time? Or how often?
Always as long the line terminator is not on its own line or separated by a comment between the #include and the terminator.
In other games?
In other user accounts?
On other computers?
Unknown for Linux

When does the problem NOT occur?
See workarounds

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)

// First solution
#include "" // blah blah <CR/LF>

// Second solution
#include ""

Additional note: I was using the Dream Maker to write these include files and code. Results may differ between OS and IDEs/editors due to different standards regarding line terminators.
I'm a little confused. Don't all include lines end with line breaks, unless they're at the very end of the file? I feel like I'm missing something semantically.
Newlines are often exclusively LF ("\n"), but plaintext files on Windows are often terminated with CR ("\r") added. So it ends with the sequence CR-LF ("\r\n").

The problem here is the CR character, "\r"
Something here isn't passing the sniff test for me because \r is handled all sorts of places in the parser. Can you shoot me a .zip of a project that demonstrates this?
Turns out that my assumption that the character \r was the culprit was wrong.

I managed to make a sample project where the error is reproducible. But I decided to open the file where the error occurs for extra validation.

To my surprise, there were no CR/LF at where the problem line. Just null. Adding the CR/LF at end of the line makes the problem go away.

Secondly, the problem seems appear only for files that are in a sub-directory.

I was unable to figure out a good way to host a .zip so I am hosting the source files as a Github repo, if that works.

Besides, my apologizes for making you waste your time on a wrong assumption of mine.