Bounty for -minimal compiler flag

1100110 0b1100110 at gmail.com
Fri Feb 14 20:13:48 PST 2014


On 2/14/14, 20:40, Daniel Murphy wrote:
> "Denis Koroskin"  wrote in message
> news:wjdvvungwvpemwmxlbst at forum.dlang.org...
>
>> I'll throw in $300 extra (maybe more), but can you please first
>> formalize the requirements (list of flags, and what each flag
>> should mean, required unittests to pass etc).
>
> Required unittests are very helpful, specifying switch names less so.
>
>> I also think it's best to split into a few tasks (e.g. a task per
>> feature or compiler flag). This way it is:
>> - easier to verify correctness/completeness
>> - many people can work without interfering with each other
>> - easier to implement and grab a bounty
>
> Yes.


Ok, In discussing all of this I just realize I looped all the way back 
around to pretty much Walter's original post.

I'm thinking about setting Bounties on these to start off with.
But I'll be digging through the source code tomorrow to make sure.

(the suggested switch names are just for clarity)

1. Disable Garbage Collector   (suggestion: -nogc)
Currently it's pretty difficult to know what allocates and what does 
not.  There should be a way to completely disable it, and error on 
attempted GC allocations. I would also like a method to warn on GC 
allocations (-vgc maybe?), but that is optional.

2. Disable Exceptions          (suggestion: -noexceptions)
There should be a way to completely disable Exceptions, and ensure that 
none are thrown.

3. Disable ModuleInfo          (suggestion: -nomoduleinfo)
There should be a way to disable any features that rely on ModuleInfo.

4. Disable Object              (suggestion: -noobject)
And anything that depends on it.

5. Disable linking of druntime (suggestion: -nodruntime)

Really I need to learn more about all of this to make sure what I'm 
proposing will accomplish the end goal of being able to completely 
disable druntime.  Is RTTI necessary, or should it be added to the list 
of things to disable?

You convinced me that keeping assert would be for the best, so that 
should be added under suggestions.  Classes would be nice, but there's 
always C++ classes.

I think it's very important to not change the semantics of D in any way. 
  The end goal is to have a solid, core subset of the language, 
therefore it's important that any code that compiles with these flags 
would also compile without them.

Jeez, the more I look into this, the more I realize how little I know 
about it all.


More information about the Digitalmars-d-announce mailing list