scoped compiler options (cf C++ pragma push/pop)

Timothee Cour thelastmammoth at gmail.com
Wed Jun 5 04:10:42 PDT 2013


A)
a number of C++ compilers support temporarily modifying compiler flags in a
given scope, via push/pop operations:

eg:

----
//normal code
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wc++98-compat"
//special code
#pragma GCC diagnostic pop
//normal code
----

(many other use cases).

I'd like to have that in D to have finer grained setting of compiler &&
conditional compilation flags.

Proposed syntax for D: use

----
//normal code
scope{
version=myversion;
import std.file;
extern(C):
//special code
}
//normal code
//std.file is no longer in scope, version(myversion) no longer holds, code
no longer extern(C)
----

Note, it turns out the above syntax compiles in D2.063 (is that a BUG?),
even though it seems undocumented and appears to currently have no behavior
(ie in code above currently dmd will allow it but version=myversion will
take effect till after the closing bracket).

B)
I'd like to be able to set compiler flags inside a given scope as to
selectively enable/disable certain compiler options, for example allowing
deprecated features only in a given scope, or have a debug build with
bounds checking and asserts enabled except for a certain part of the code
that would otherwise make the debug code too slow, or even having a
check_integer_overflow compiler flag (see recent threads) that would be
disabled for code that relies on overflow behavior.

Proposed syntax:
----
//normal code
pragma(scope,dmd,"-noboundscheck -d -vtls"){ //dmd because flags could be
compiler specific
  import std.algorithm;
  //code using *custom* options, including for functions inside
std.algorithm and its dependencies
}
//normal code
void main(){
  import std.algorithm;
  //code using *normal* options, including for functions inside
std.algorithm and its dependencies
}
----

The behavior of that would be to apply given compiler options recursively
for any code inside the scope. The compiler could then compile several
versions of a given modules (one per compiler option it appears with).
Using a caching mechanism would avoid redoing un-necessary work. The name
mangling for custom code would contain a hash of the compiler options.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130605/57191e09/attachment-0001.html>


More information about the Digitalmars-d mailing list