59117 - for loop scoping rules.

Status: VERIFIED WONTFIX

(SeaMonkey :: Build Config, enhancement, P3)

Description

[jim_nance]

Mozilla must build on compilers that do not support the new rules for scoping
of variables declared inside for loops.  Presently we are achieving this by
documenting it in the coding standards.  I read about a little trick that will
allow old compilers to implent the new rules.  You have to redefine for like
this:

#define for if(0); else for

If this is done, then variables declared inside the for() are scoped using the
modern rules.

I could see no down side to making mozilla use this trick, and it would be nice
for everyone to have a cosistent set of rules.  I modified configure.in so that
it defines this macro if the compiler does not support modern for loop scoping.
I tested it under linux by adding a flag that forced old style scoping and
building mozilla.  Patch is attached.

Comment 1

[jim_nance]

Attachment: configure.in patch

Comment 2

[cls]

scc is the proper person to review this compiler test.  It's too scary for me.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Where do we fail on such compilers?  I was under the impression that VC++ did
for-loop scoping differently (from the bustage rjc caused a few nights ago).

Comment 4

[jim_nance]

David,
    We dont fail anywhere right now.  We get around the problems with compiler
differences wrt for loops by documenting that code should work with both models.
This patch causes older compilers to use the new rules so that they are all
working the same way and its a standards compliant way to boot.  This should
allow us to drop the for() loop restriction from the coding standards if we
want to.

Comment 5

[Scott Collins]

Before we implement something like this ... what is the impact on generated code
on those compilers where this would come into play?  Do some profiling, then
let's make a go/no-go decision before 0.9.

Comment 6

[Scott Collins]

Another thing to note is that this is explicitly illegal according to the C++
standard:

  17.4.3.1.1 Macro names [lib.macro.names]

  ...

2 A translation unit that includes a header shall not contain any macros that
  define names declared or defined in that header.  Nor shall such a translation
  unit define macros for names lexically identical to keywords.

Comment 7

[Scott Collins]

it's a neat suggestion, but since it's explicitly in violation of the standard,
I don't think we can do it.  Marking WONTFIX.  Sorry.

Comment 8

[Jon Granrose]

verified wontfix.