Missing include file resourceArea.hpp

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

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.

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