I've just had a slight problem compiling Lazarus where FPC was reporting this:

main.pp(5001,1) Fatal: Syntax error, "BEGIN" expected but "shl" found

The reason was that I'd not spotted that Subversion had inserted a like like

<<<<< Mine:

preceding a function. Is this something that the compiler could detect and warn about?

On Dec 2, 2012 11:47 AM, "Mark Morgan Lloyd" <

wrote: I've just had a slight problem compiling Lazarus where FPC was reporting

this:

main.pp(5001,1) Fatal: Syntax error, "BEGIN" expected but "shl" found

<< is shl in c. I guess fpc accepts this syntax, too?

Henry

It seems it just did?
What error message do you expect?

Mattias

Something that recognises that a message like <<<<<<< .mine originates from the project's chosen VCS, and that <<<<<<< is distinct from shl.

This is the same as the discussion about whether FPC could support "#" at the first line for shebanging for instantfpc. In short: in will not happen. It's your own responsibility to keep versioned files conflict free and yes, I had this problem myself already as well.

Regards,
Sven

Yes, "<<" and ">>" are converted in scanner stage to "shl" and "shr" which will give me headaches once I want to support nested specializations (basically the same problem that C++ had):

TTest<TTest<TObject>> // !!!

Regards,
Sven

Ouch. I suggest to turn it off by default, with a new modeswitch to turn back on if required.

This problem will be tackled once I'm working on nested specializations ;)

Regards,
Sven

> What error message do you expect? Something that recognises that a message like <<<<<<< .mine originates from the project's chosen VCS, and that <<<<<<< is distinct from shl.

+1

A concatenation of the *binary* "<" or "<<" operators, into "<<<<...", doesn't make sense (syntactically), so that the scanner could generate an appropriate error token (or message). Just as in handling "." .. "..." tokens, where more than 3 consecutive dots also are definite syntax errors. AFAIR a check for an fourth dot is not performed by the scanner, and seems not required because the resulting parser error message is sufficient. But a check for a third "<" definitely should be added to the scanner, so that a more specific error message can be issued.

DoDi

Hans-Peter Diettrich wrote

message is sufficient. But a check for a third "<" definitely should be added to the scanner, so that a more specific error message can be issued.

Not worth the effort, in my opinion. I understood the error message immediately.

Henry