Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 02, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
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. |
June 02, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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
|
June 02, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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
|
June 02, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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
|
June 03, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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
|
June 05, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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.
|
June 05, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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
|
June 05, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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
|
June 05, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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
|
June 05, 2010 [D-runtime] current SVN broken | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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
|
Copyright © 1999-2021 by the D Language Foundation