www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - DMD 0.131: Version marker allowed but ineffectual

reply Burton Radons <burton-radons smocky.com> writes:
This code doesn't compile by complaining about the undefined type, but 
should compile to nothing if it is in fact correct code:

     version (none):

     intsridsfa itoerwuofjdsa;

Walter, I need to know how this is going to be resolved.
Sep 17 2005
next sibling parent reply zwang <nehzgnaw gmail.com> writes:
Burton Radons wrote:

 This code doesn't compile by complaining about the undefined type, but 
 should compile to nothing if it is in fact correct code:
 
     version (none):
 
     intsridsfa itoerwuofjdsa;
 
 Walter, I need to know how this is going to be resolved.



Statements in the "version(none)" block needs to be parsed though the 
compiler does not emit object code for them.
Sep 17 2005
parent Burton Radons <burton-radons smocky.com> writes:
zwang wrote:

 Burton Radons wrote:
 

 This code doesn't compile by complaining about the undefined type, but 
 should compile to nothing if it is in fact correct code:

     version (none):

     intsridsfa itoerwuofjdsa;

 Walter, I need to know how this is going to be resolved.


 
 
 
 Statements in the "version(none)" block needs to be parsed though the 
 compiler does not emit object code for them.


Look again.  Uncompiled optional code doesn't need to be semantically 
correct, only syntactually, and this code applies.  Another way to write 
the problem would be:

     int a = b;

     version (none):

     const int b = 0;

This also succeeds compilation, but either should fail or is invalid code.
Sep 17 2005
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
Looks to me that the issue is just that the : doesn't work with version()
statements.  If a {} block is used, it compiles fine.

On Sat, 17 Sep 2005 18:12:33 -0700, Burton Radons wrote:


 This code doesn't compile by complaining about the undefined type, but 
 should compile to nothing if it is in fact correct code:
 
      version (none):
 
      intsridsfa itoerwuofjdsa;
 
 Walter, I need to know how this is going to be resolved.
Sep 17 2005
parent John Demme <me teqdruid.com> writes:
Sorry to respond to myself, but forgot what I was gonna say:

I don't think version(anything): should compile.  The : is used to apply
an attribute to stuff below it, but version() is a statement, not an
attribute.  The fact that it sort of compiles with the : is misleading.

~John Demme

On Sat, 17 Sep 2005 22:20:35 -0400, John Demme wrote:


 Looks to me that the issue is just that the : doesn't work with version()
 statements.  If a {} block is used, it compiles fine.
 
 On Sat, 17 Sep 2005 18:12:33 -0700, Burton Radons wrote:
 

 This code doesn't compile by complaining about the undefined type, but 
 should compile to nothing if it is in fact correct code:
 
      version (none):
 
      intsridsfa itoerwuofjdsa;
 
 Walter, I need to know how this is going to be resolved.
Sep 17 2005
prev sibling parent reply =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Burton Radons schrieb:


 This code doesn't compile by complaining about the undefined type, but
 should compile to nothing if it is in fact correct code:
 
     version (none):
 
     intsridsfa itoerwuofjdsa;


http://dstress.kuehne.cn/nocompile/d/debug_11_A.d
http://dstress.kuehne.cn/nocompile/d/debug_11_B.d
http://dstress.kuehne.cn/nocompile/v/version_09_A.d
http://dstress.kuehne.cn/nocompile/v/version_09_B.d

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFDLmpy3w+/yD4P9tIRAoj8AKC15okpXZQqC24SErfq+ZxRFfU5twCgvxl/
SqKNrL+n5Tvfs2jd/JKQ13Q=
=9H9g
-----END PGP SIGNATURE-----
Sep 19 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Thomas,

is there a _very_ specific reason why clicking on the links below, one 
does not simply get the contents on screen in the browser?

One would assume that this is what most people want, i.e. just take a 
quick peek on exactly how you wrote a particular test.

Now I have to tell the browser what to do with the file.

(And we all know this is a mimetype issue, nothing more complicated.)

Of course I could fix this at the client end -- on every computer I use. 
And all other people affected could do it too.

Or you could put a definition for .d files on your web server.

georg

Thomas Kühne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Burton Radons schrieb:
 
 

This code doesn't compile by complaining about the undefined type, but
should compile to nothing if it is in fact correct code:

    version (none):

    intsridsfa itoerwuofjdsa;


 
 
 http://dstress.kuehne.cn/nocompile/d/debug_11_A.d
 http://dstress.kuehne.cn/nocompile/d/debug_11_B.d
 http://dstress.kuehne.cn/nocompile/v/version_09_A.d
 http://dstress.kuehne.cn/nocompile/v/version_09_B.d
 
 Thomas
 
 -----BEGIN PGP SIGNATURE-----
 
 iD8DBQFDLmpy3w+/yD4P9tIRAoj8AKC15okpXZQqC24SErfq+ZxRFfU5twCgvxl/
 SqKNrL+n5Tvfs2jd/JKQ13Q=
 =9H9g
 -----END PGP SIGNATURE-----
Sep 20 2005
parent =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Georg Wrede schrieb:


 is there a _very_ specific reason why clicking on the links below, one
 does not simply get the contents on screen in the browser?


Yes, the browser's configuration for the mime type "text/x-dsrc"
or in general "text/something-not-yet-encountered".


 One would assume that this is what most people want, i.e. just take a
 quick peek on exactly how you wrote a particular test.

 Now I have to tell the browser what to do with the file.

 (And we all know this is a mimetype issue, nothing more complicated.)

 Of course I could fix this at the client end -- on every computer I use.
 And all other people affected could do it too.

 Or you could put a definition for .d files on your web server.


With the exception of a few encoding tests all *.d files are served with
the mime type "text/x-dsrc". "text/x-dsrc" has been codified since
2004-12-10 (https://bugs.freedesktop.org/show_bug.cgi?id=676#2).

Thomas
-----BEGIN PGP SIGNATURE-----

iD8DBQFDMsvy3w+/yD4P9tIRAjA8AKDFJHgGYF765cDYMv4WWk3f8i0hfgCfXObQ
MWeXt+VkNdb2M7dskn4Df48=
=AjxJ
-----END PGP SIGNATURE-----
Sep 22 2005
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Thomas Kühne wrote:

[added to dstress]

This bug is not confirmed on WinXP32, because the expected error is 
given, that the `:' is unexpected.

Are there any tags for the entries in dstress to see for which 
environment they are buggy?

-manfred
Sep 21 2005
parent =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manfred Nowak schrieb:

 Thomas Kühne wrote:
 
 [added to dstress]
 
 This bug is not confirmed on WinXP32, because the expected error is 
 given, that the `:' is unexpected.


Just to make sure, are we talking about the following test cases?
http://dstress.kuehne.cn/nocompile/d/debug_11_A.d
http://dstress.kuehne.cn/nocompile/d/debug_11_B.d
http://dstress.kuehne.cn/nocompile/v/version_09_A.d
http://dstress.kuehne.cn/nocompile/v/version_09_B.d

If so, I didn't get any error message with DMD 0.132 running on
WindowsXP(German editon) and Windows 2000(Chinese edition).


 Are there any tags for the entries in dstress to see for which 
 environment they are buggy?


There are no tags. Once in a while I rerun the test suite and put the
results online:
http://dstress.kuehne.cn/www/dstress.html
http://dstress.kuehne.cn/raw_results

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFDMsC63w+/yD4P9tIRAp6nAJ0b5gz1cpl1OCKjcPKWfw1xqOKYOwCgwsmc
VFFLzVqMUUeZ109kVqP7F3Q=
=bY9R
-----END PGP SIGNATURE-----
Sep 22 2005