likely bug in comment/directive parsing

[440bx]

get this: _always_

it's just one word, it shouldn't be hard to understand.

[Lansdowne]

The open brace in Pascal is a special character that indicates the start of a block comment. 

Whenever an open brace is found, the compiler should interpret that as an attempt of opening a comment (that's what the open brace is for), therefore an open brace found inside a comment should be seen as an attempt of creating a nested comment, which is something not supported (at least not in standard Pascal.)

The attempt of supporting nested comments is a mistake with highly undesirable consequences.

@440bx

THAT is something I wholly agree with.
Rip it out, nobody uses it or relies on it anyway.

I also never found any use for it, looks more like a hobby project.

But as I wrote: who the hell allowed nested comments anyway.

Petty project?

I use nested comments very regularly.  Although not often a { } nested inside another  { } comment.  Most often it is a // comment inside a { }. That could occasionally be inside a (*  *) comment.

The // comment is to explain the line of code.  Then I might decided to comment out the section which includes that line, perhaps being redundant but kept in case it's needed in future.  Then the whole procedure containing all that section gets commented out temporarily while testing.

Also, while I don't have much use for compiler directives, but it does seem that the wording
{$MODESWITCH NESTEDCOMMENTS OFF }
is ambiguous.
Does it mean nested comments are not allowed (a warning/error is issued), or does it mean nested comments are not checked for?

[Martin_fr]

The presence of a { inside a comment that was started with a { should _always_ be considered an error.

Noted your opinion. I reserve the right to have a different opinion.

Out of interest, How should or do the following similar items behave?

// inside a // comment (the closing for this is the newline=> so they have a closing term and it differs from the open symbol)
Comments in C, C++, Java, Python, JS?
Comments and CDATA in HTML/XML?

Or how many examples are there were other languages behave according to your description
That is, when the closing symbol differs from the opening.

[paweld]

The presence of a { inside a comment that was started with a { should _always_ be considered an error.

I disagree with this because I often include JSON (which are analyzed by a given method) in {} comment block

[440bx]

I reserve the right to have a different opinion.

That's perfectly fine.

Out of interest, How should or do the following similar items behave?

// inside a // comment (the closing for this is the newline=> so they have a closing term and it differs from the open symbol)
Comments in C, C++, Java, Python, JS?
Comments and CDATA in HTML/XML?

Or how many examples are there were other languages behave according to your description
That is, when the closing symbol differs from the opening.

Honestly, I could not care less. 

What I care about is that in Pascal, it is a fact, in the standard, that an opening brace starts a comment.  Another fact is that Pascal does not support nested comments.  Therefore, the appearance of another open brace in a comment that was started with an opening brace is an error because nested comments are NOT allowed.

And for the record, the fact that the open brace appears in a comment that was started with another open brace is no reason to interpret it any differently.  Using your own examples, when a line comment is started with // the carriage return and line feed don't lose their meaning, they are still interpreted as starting a new line in spite of them being in a comment AND the same thing is true when the comment is started with an open brace.  Should the compiler ignore CR and LF until it finds a closing comment ?.. I hope the answer is no.  For the same reason it should NOT treat an open brace as part of the comment.

To make it crystal clear: it is wrong and misguided to claim/presume that the open brace should lose its meaning when it appears in a comment that was started with an open brace.  The reason for this is: Pascal does NOT support nested comments therefore the open brace character cannot be used in a comment that was started with an open brace.    Pretty simple stuff.

[Martin_fr]

Out of interest, How should or do the following similar items behave?

Honestly, I could not care less. 

What I care about is that in Pascal, it is a fact, in the standard, that an opening brace starts a comment.  Another fact is that Pascal does not support nested comments.

Ok to start with: I do not say that those other languages should serve as a standard, or we need to be like them (I would rather not...). I listed them all, because I was interested if the (your) concept itself, has much of an establishment. I could imagine that there is one or even some examples of something behaving like this.
But the question is not one or two, the question is about a well visible percentage in the overall available spread. That then would be an indicator for how useful that may be thought by others.

Not that - for your own wish list - you would need any such approval by others, but then if it was absent, if it was "just you", then it would be somewhat of an expectation to have it applied to an entire community.


As far as I can see, at least some of them don't have nested comments, and then they do ignore reoccurring opening comment starters. Just like fpc does.

Therefore, the appearance of another open brace in a comment that was started with an opening brace is an error because nested comments are NOT allowed.

That makes it sound as if it was on inherent property of comment handling. If that is what you mean, then I do strongly disagree.

I do agree, that it is one way it can be done (by choice of whoever choses the algorithm).
But it is no more right or wrong than the current way (and vice versa).

So to me, what you describe is simply a feature request.
To me, we have a valid and correct implementation. One of many possible. Actually two of many possible. You wish for a third.

[440bx]

Obviously, you are in your right to disagree.

The reason the open brace should not be allowed in a comment is because Pascal does not allow nested comments.  That means open brace is not allowed in a comment because if it were it would be starting a nested comment and nested comments, as previously mentioned, are _not_ allowed.  Just logic: no nested comments allowed = no { in comments.  That's it.  That simple.

Of course, what some would like, you among them, is to make the meaning of the open brace context sensitive.  There is only one context where multiple open braces are allowed and that's in strings because in a string, an open brace has no specific meaning (it certainly does not start a comment within the string... does it ?.)    On the other hand, in a string, if you want a single quote character you need to have two (2) single quote characters to inform the compiler that it should _not_ assign that quote the meaning it normally has.

Therefore, if an open brace should be allowed in a comment started with an open brace then, a possibility, would be to require two (2) open braces to remove their meaning just as it is done with the single quote.

or, for consistency, we should modify FPC to treat quotes the same way it treats open braces... SCNR.

Is this horse dead yet ?... or is it necessary to send this poor horse to Ukraine ?

The whole nested comment thing in FPC is a mess.  Another, code first, think later (and later is yet to happen...)

[Martin_fr]

You somehow managed to miss out some of my points. Anyway, I am not repeating them. Enough to say that some of your "conclusions" only work, if you ignore them.

And well, I know you feel the same about my statement. But I know not how to explain it, such as to expect it to resolve our difference in perception.

Since all the info is there, it can be left to each reader here after to decide what they find more conclusive.

[dseligo]

The presence of a { inside a comment that was started with a { should _always_ be considered an error.

I disagree with this because I often include JSON (which are analyzed by a given method) in {} comment block

Same here.

And then I use (* for outer comments because warning 'Comment level 2 found' annoys me.

Code: Pascal  [Select][+][-]

1. (*
2.   This is some JSON:
3.     { value = "abc" }
4. *)

[creaothceann]

The reason the open brace should not be allowed in a comment is because Pascal does not allow nested comments.  That means open brace is not allowed in a comment because if it were it would be starting a nested comment and nested comments, as previously mentioned, are _not_ allowed.  Just logic: no nested comments allowed = no { in comments.

By default Pascal does not even know about nested comments, and therefore doesn't bother scanning for them. An open brace in a comment does not matter because that character is considered to be part of the comment.

When the scanner encounters a // comment it simply ignores anything until EOL or EOF. A { comment causes the scanner to ignore anything until }. Likewise for (* and *).

[440bx]

I'm not going to argue this thing anymore but, I very strongly disagree with those viewpoints.

The compiler should _always_ consider the presence of an open brace as the start of a block comment.  The only exception is when the open brace occurs in a string.

[PascalDragon]

The presence of a { inside a comment that was started with a { should _always_ be considered an error.

If NESTEDCOMMENTS is disabled in non-ISO modes then the only character in a comment started with { that has any significance is }, thus any { is irrelevant for the scanner. Both Delphi and TP behave the same here.
The same is also true for comments started with (* which will lead to the scanner ignoring any (*.
In ISO-modes it's in so far different that a comment started with { can be terminated by either } or *) (similar for comments started with (*).

[440bx]

Explain why it is that when NESTEDCOMMENTS is OFF and there are nested comments the compiler does NOT emit a message or a note about the presence of a nested comment it has explicitly been told should NOT be allowed ?  I cannot see any _reasonable_ explanation for that not to be considered a bug.

In the case of TP and likely Delphi, because they do not ever attempt to allow nested comments, I can see that a _fragile_ argument could be made that the presence of a { in a comment could be considered just another character.  I think it's a very poor choice but, I can see the rationale.

HOWEVER, in a compiler that accepts nested comments then the { should _never_ be allowed in a block comment started with a { because the compiler cannot unambiguously determine if the { is an attempt of creating a nested comment, which is something it allows under some circumstances or just another character.

IOW, FPC cannot deterministically establish whether the presence of a { is an error or not.  That's why it should always disallow a { when nested comments are off.  It cannot know if the { is the result of a programmer's mistake or just another character therefore it should err on the safe side and disallow the character.  At the very least, it should emit a warning about the presence of a {.  I emphasize, that's the very _least_ it should do.

[PascalDragon]

Explain why it is that when NESTEDCOMMENTS is OFF and there are nested comments the compiler does NOT emit a message or a note about the presence of a nested comment it has explicitly been told should NOT be allowed ?  I cannot see any _reasonable_ explanation for that not to be considered a bug.

You have an incorrect understanding of what an enabled NESTEDCOMMENTS does. It simply ensures that any opening { (or (*)) needs to be balanced by a corresponding } (or *)). Without NESTEDCOMMENTS the first } simply ends a { comment (and the first *) a (* comment).

FPC does not emit any message if it encounters a { inside a { comment, because the further { are simply ordinary characters.

The current behavior is intended. There will be no change.

[creaothceann]

why it is that when NESTEDCOMMENTS is OFF and there are nested comments

When NestedComments is off, there are no nested comments.