Missing include file resourceArea.hpp

[Jesper Wilhelmsson]

Den 17/3/16 kl. 22:19, skrev David Holmes:
> Sorry for top-posting but if the implicit include is from allocation.hpp then I
> think that is perfectly fine as resourceArea is a part of allocation - no need
> to flatten this out further.

I can live with that. Less than half the files in this change include 
allocation.hpp or allocation.inline.hpp.

>
> If the implicit include is from an obscure source then by all means fix.
>
> Otherwise we are on the slippery slope of converting to a system where
> everything includes everything explicitly - which is pointless.

I don't necessarily think this is pointless, but we don't have to agree on 
everything :)
/Jesper

>
> David
>
> On 18/03/2016 1:30 AM, Jesper Wilhelmsson wrote:
>> Den 17/3/16 kl. 16:08, skrev Thomas Schatzl:
>>> Hi,
>>>
>>> On Thu, 2016-03-17 at 11:00 -0400, Joseph Provino wrote:
>>>> Hi David, yes, it's included indirectly and it all builds just fine.
>>>>
>>>> I'm okay with just closing this as won't fix since everything is
>>>> working
>>>> as it is now.
>>>
>>>   of course everything works right now, and everything needed is
>>> included at least indirectly over a few steps. Otherwise the sources
>>> would naturally not build.
>>>
>>> The problem arises when refactoring, and due to that removing includes
>>> (or just removing obsolete includes) and suddenly things stop compiling
>>> and you start getting really weird errors in completely unrelated files
>>> .
>>>
>>> Now if people oppose to such a change, I won't object, but I do have
>>> been working on fixing missing includes for too many hours already.
>>>
>>
>> Everything is not working as it is now.
>>
>> I have been in the situation where suddenly things don't build due to
>> missing includes in completely unrelated source files when cleaning up.
>> I have also seen integration failures between hs-rt and main for similar
>> reasons where two completely unrelated changes that worked fine on their
>> own caused build failures after a merge.
>>
>> Also I do not understand why we should avoid cleaning up or making the
>> code more correct. If the job wasn't done and someone asked you to do
>> it, sure, in that case it would be perfectly fine to say that you don't
>> think this is a priority and you don't want to spend time on it. But as
>> the work has already been done I don't see why we should not take it in.
>> Is there a potential risk involved that I do not see?
>>
>> I have reviewed the change and it looks good to me.
>> /Jesper
>>
>>
>>> Thanks,
>>>    Thomas
>>>