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.

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.

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.

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.

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.

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

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-----

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

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

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