Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.

Bug report submitted with patch, but I've uncovered yet another:

@safe:
    // stuff

generates the header:

{
    // stuff
}

I'm starting to feel like druntime is the only project using header generation :-)

On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:

> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Patch submitted for this as well.  Import generation is still failing (core.sys.windows.windows), but if the reason is a compiler bug it's not obvious.

On Jun 2, 2010, at 3:33 PM, Sean Kelly wrote:

> Bug report submitted with patch, but I've uncovered yet another:
> 
> @safe:
>    // stuff
> 
> generates the header:
> 
> {
>    // stuff
> }
> 
> I'm starting to feel like druntime is the only project using header generation :-)
> 
> On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:
> 
>> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Okay, got it.  The problem (obvious in hindsight) is that we can't generate a header from a module that relies on version blocks that aren't the current configuration.  I think I'll change the header gen process to simply copy everything from core/sys instead of using header gen to move it.  At least this will allow all OSes to generate a complete import tree.

On Jun 2, 2010, at 4:13 PM, Sean Kelly wrote:

> Patch submitted for this as well.  Import generation is still failing (core.sys.windows.windows), but if the reason is a compiler bug it's not obvious.
> 
> On Jun 2, 2010, at 3:33 PM, Sean Kelly wrote:
> 
>> Bug report submitted with patch, but I've uncovered yet another:
>> 
>> @safe:
>>   // stuff
>> 
>> generates the header:
>> 
>> {
>>   // stuff
>> }
>> 
>> I'm starting to feel like druntime is the only project using header generation :-)
>> 
>> On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:
>> 
>>> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.
>>> _______________________________________________
>>> D-runtime mailing list
>>> D-runtime at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>> 
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Changed my mind.  I've decided it makes more sense to expect that it be possible to generate a full set of headers from any OS, so I'm going to wrap the contents of the sys modules in version blocks for that system, so windows headers will be in version(Windows), etc.

On Jun 2, 2010, at 4:21 PM, Sean Kelly wrote:

> Okay, got it.  The problem (obvious in hindsight) is that we can't generate a header from a module that relies on version blocks that aren't the current configuration.  I think I'll change the header gen process to simply copy everything from core/sys instead of using header gen to move it.  At least this will allow all OSes to generate a complete import tree.
> 
> On Jun 2, 2010, at 4:13 PM, Sean Kelly wrote:
> 
>> Patch submitted for this as well.  Import generation is still failing (core.sys.windows.windows), but if the reason is a compiler bug it's not obvious.
>> 
>> On Jun 2, 2010, at 3:33 PM, Sean Kelly wrote:
>> 
>>> Bug report submitted with patch, but I've uncovered yet another:
>>> 
>>> @safe:
>>>  // stuff
>>> 
>>> generates the header:
>>> 
>>> {
>>>  // stuff
>>> }
>>> 
>>> I'm starting to feel like druntime is the only project using header generation :-)
>>> 
>>> On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:
>>> 
>>>> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.
>>>> _______________________________________________
>>>> D-runtime mailing list
>>>> D-runtime at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>>> 
>>> _______________________________________________
>>> D-runtime mailing list
>>> D-runtime at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>> 
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Sean, looks like neither of your bug reports includes the patches you created.

On 6/3/2010 9:47 AM, Sean Kelly wrote:
> Changed my mind.  I've decided it makes more sense to expect that it be possible to generate a full set of headers from any OS, so I'm going to wrap the contents of the sys modules in version blocks for that system, so windows headers will be in version(Windows), etc.
> 
> On Jun 2, 2010, at 4:21 PM, Sean Kelly wrote:
> 
>> Okay, got it.  The problem (obvious in hindsight) is that we can't generate a header from a module that relies on version blocks that aren't the current configuration.  I think I'll change the header gen process to simply copy everything from core/sys instead of using header gen to move it.  At least this will allow all OSes to generate a complete import tree.
>>
>> On Jun 2, 2010, at 4:13 PM, Sean Kelly wrote:
>>
>>> Patch submitted for this as well.  Import generation is still failing (core.sys.windows.windows), but if the reason is a compiler bug it's not obvious.
>>>
>>> On Jun 2, 2010, at 3:33 PM, Sean Kelly wrote:
>>>
>>>> Bug report submitted with patch, but I've uncovered yet another:
>>>>
>>>> @safe:
>>>>  // stuff
>>>>
>>>> generates the header:
>>>>
>>>> {
>>>>  // stuff
>>>> }
>>>>
>>>> I'm starting to feel like druntime is the only project using header generation :-)
>>>>
>>>> On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:
>>>>
>>>>> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.

I attached a patch to bug 4263 that fixes at least the two issues you pointed out in bug 4262 and 4263.

Walter, the header.out file needs the tweak I sent to you earlier today in email due to it demonstrating the buggy behavior rather than the correct behavior for manifest enums.  The rest of the suite passes fine.

Later,
Brad

On 6/5/2010 2:32 AM, Brad Roberts wrote:
> Sean, looks like neither of your bug reports includes the patches you created.
> 
> On 6/3/2010 9:47 AM, Sean Kelly wrote:
>> Changed my mind.  I've decided it makes more sense to expect that it be possible to generate a full set of headers from any OS, so I'm going to wrap the contents of the sys modules in version blocks for that system, so windows headers will be in version(Windows), etc.
>>
>> On Jun 2, 2010, at 4:21 PM, Sean Kelly wrote:
>>
>>> Okay, got it.  The problem (obvious in hindsight) is that we can't generate a header from a module that relies on version blocks that aren't the current configuration.  I think I'll change the header gen process to simply copy everything from core/sys instead of using header gen to move it.  At least this will allow all OSes to generate a complete import tree.
>>>
>>> On Jun 2, 2010, at 4:13 PM, Sean Kelly wrote:
>>>
>>>> Patch submitted for this as well.  Import generation is still failing (core.sys.windows.windows), but if the reason is a compiler bug it's not obvious.
>>>>
>>>> On Jun 2, 2010, at 3:33 PM, Sean Kelly wrote:
>>>>
>>>>> Bug report submitted with patch, but I've uncovered yet another:
>>>>>
>>>>> @safe:
>>>>>  // stuff
>>>>>
>>>>> generates the header:
>>>>>
>>>>> {
>>>>>  // stuff
>>>>> }
>>>>>
>>>>> I'm starting to feel like druntime is the only project using header generation :-)
>>>>>
>>>>> On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:
>>>>>
>>>>>> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

They don't?  I attached them.  Oh well... I'll diff my current setup and attach it as a bulk patch.

On Jun 5, 2010, at 2:32 AM, Brad Roberts wrote:

> Sean, looks like neither of your bug reports includes the patches you created.
> 
> On 6/3/2010 9:47 AM, Sean Kelly wrote:
>> Changed my mind.  I've decided it makes more sense to expect that it be possible to generate a full set of headers from any OS, so I'm going to wrap the contents of the sys modules in version blocks for that system, so windows headers will be in version(Windows), etc.
>> 
>> On Jun 2, 2010, at 4:21 PM, Sean Kelly wrote:
>> 
>>> Okay, got it.  The problem (obvious in hindsight) is that we can't generate a header from a module that relies on version blocks that aren't the current configuration.  I think I'll change the header gen process to simply copy everything from core/sys instead of using header gen to move it.  At least this will allow all OSes to generate a complete import tree.
>>> 
>>> On Jun 2, 2010, at 4:13 PM, Sean Kelly wrote:
>>> 
>>>> Patch submitted for this as well.  Import generation is still failing (core.sys.windows.windows), but if the reason is a compiler bug it's not obvious.
>>>> 
>>>> On Jun 2, 2010, at 3:33 PM, Sean Kelly wrote:
>>>> 
>>>>> Bug report submitted with patch, but I've uncovered yet another:
>>>>> 
>>>>> @safe:
>>>>> // stuff
>>>>> 
>>>>> generates the header:
>>>>> 
>>>>> {
>>>>> // stuff
>>>>> }
>>>>> 
>>>>> I'm starting to feel like druntime is the only project using header generation :-)
>>>>> 
>>>>> On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:
>>>>> 
>>>>>> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Cool.. our two diffs looks fairly similar -- mine took away that tree of if/elses as a secondary cleanup, but they add the same two attributes in the same spot.

On 6/5/2010 2:22 PM, Sean Kelly wrote:
> They don't?  I attached them.  Oh well... I'll diff my current setup and attach it as a bulk patch.
> 
> On Jun 5, 2010, at 2:32 AM, Brad Roberts wrote:
> 
>> Sean, looks like neither of your bug reports includes the patches you created.
>>
>> On 6/3/2010 9:47 AM, Sean Kelly wrote:
>>> Changed my mind.  I've decided it makes more sense to expect that it be possible to generate a full set of headers from any OS, so I'm going to wrap the contents of the sys modules in version blocks for that system, so windows headers will be in version(Windows), etc.
>>>
>>> On Jun 2, 2010, at 4:21 PM, Sean Kelly wrote:
>>>
>>>> Okay, got it.  The problem (obvious in hindsight) is that we can't generate a header from a module that relies on version blocks that aren't the current configuration.  I think I'll change the header gen process to simply copy everything from core/sys instead of using header gen to move it.  At least this will allow all OSes to generate a complete import tree.
>>>>
>>>> On Jun 2, 2010, at 4:13 PM, Sean Kelly wrote:
>>>>
>>>>> Patch submitted for this as well.  Import generation is still failing (core.sys.windows.windows), but if the reason is a compiler bug it's not obvious.
>>>>>
>>>>> On Jun 2, 2010, at 3:33 PM, Sean Kelly wrote:
>>>>>
>>>>>> Bug report submitted with patch, but I've uncovered yet another:
>>>>>>
>>>>>> @safe:
>>>>>> // stuff
>>>>>>
>>>>>> generates the header:
>>>>>>
>>>>>> {
>>>>>> // stuff
>>>>>> }
>>>>>>
>>>>>> I'm starting to feel like druntime is the only project using header generation :-)
>>>>>>
>>>>>> On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:
>>>>>>
>>>>>>> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

It's good to know I've got somewhat of a grasp on how the compiler works, or at in good company if confused :-)

On Jun 5, 2010, at 2:36 PM, Brad Roberts wrote:

> Cool.. our two diffs looks fairly similar -- mine took away that tree of if/elses as a secondary cleanup, but they add the same two attributes in the same spot.
> 
> On 6/5/2010 2:22 PM, Sean Kelly wrote:
>> They don't?  I attached them.  Oh well... I'll diff my current setup and attach it as a bulk patch.
>> 
>> On Jun 5, 2010, at 2:32 AM, Brad Roberts wrote:
>> 
>>> Sean, looks like neither of your bug reports includes the patches you created.
>>> 
>>> On 6/3/2010 9:47 AM, Sean Kelly wrote:
>>>> Changed my mind.  I've decided it makes more sense to expect that it be possible to generate a full set of headers from any OS, so I'm going to wrap the contents of the sys modules in version blocks for that system, so windows headers will be in version(Windows), etc.
>>>> 
>>>> On Jun 2, 2010, at 4:21 PM, Sean Kelly wrote:
>>>> 
>>>>> Okay, got it.  The problem (obvious in hindsight) is that we can't generate a header from a module that relies on version blocks that aren't the current configuration.  I think I'll change the header gen process to simply copy everything from core/sys instead of using header gen to move it.  At least this will allow all OSes to generate a complete import tree.
>>>>> 
>>>>> On Jun 2, 2010, at 4:13 PM, Sean Kelly wrote:
>>>>> 
>>>>>> Patch submitted for this as well.  Import generation is still failing (core.sys.windows.windows), but if the reason is a compiler bug it's not obvious.
>>>>>> 
>>>>>> On Jun 2, 2010, at 3:33 PM, Sean Kelly wrote:
>>>>>> 
>>>>>>> Bug report submitted with patch, but I've uncovered yet another:
>>>>>>> 
>>>>>>> @safe:
>>>>>>> // stuff
>>>>>>> 
>>>>>>> generates the header:
>>>>>>> 
>>>>>>> {
>>>>>>> // stuff
>>>>>>> }
>>>>>>> 
>>>>>>> I'm starting to feel like druntime is the only project using header generation :-)
>>>>>>> 
>>>>>>> On Jun 2, 2010, at 2:37 PM, Sean Kelly wrote:
>>>>>>> 
>>>>>>>> Don't update unless you're inclined to fix the compiler bug that's causing problems (in short, "enum x = 1" declarations don't have a preceding "enum").  I'll post again once I've found a fix.
>>> _______________________________________________
>>> D-runtime mailing list
>>> D-runtime at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>> 
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime