www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - DMD "preprocessed"-source output?

reply "Nick Sabalausky" <a a.a> writes:
I don't suppose DMD has any way to output a copy of what the source files 
look like after things like mixins, CTFE and versions are applied? (Sort of 
like running a C compiler with a "preprocess-only" flag). I don't see 
anything like this in the listed command-line params, but maybe I missed it.

I have a program (that makes heavy use of mixins and CTFE and such) that 
gives wildly different output between two different versions of DMD/Tango 
(Tango's documented "breaking changes" don't appear to be the culprit and 
nothing in DMD's changelog or the latest bugzilla entries seem to 
immediately stick out). I'm sure I can track it down, but it would help to 
narrow things down if I could run the "preprocessed" results from both 
environments through a file diff. 
Oct 04 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 05 Oct 2008 04:14:34 +0400, Nick Sabalausky <a a.a> wrote:

 I don't suppose DMD has any way to output a copy of what the source files
 look like after things like mixins, CTFE and versions are applied? (Sort  
 of
 like running a C compiler with a "preprocess-only" flag). I don't see
 anything like this in the listed command-line params, but maybe I missed  
 it.

 I have a program (that makes heavy use of mixins and CTFE and such) that
 gives wildly different output between two different versions of DMD/Tango
 (Tango's documented "breaking changes" don't appear to be the culprit and
 nothing in DMD's changelog or the latest bugzilla entries seem to
 immediately stick out). I'm sure I can track it down, but it would help  
 to
 narrow things down if I could run the "preprocessed" results from both
 environments through a file diff.

D doesn't have a dedicated preprocessor and I believe all the mixins and stuff is applied and parsed of fly during AST construction, just like inlining is done on AST instead of codegen phase.
Oct 05 2008
next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Oct 5, 2008 at 8:28 AM, Denis Koroskin <2korden gmail.com> wrote:
 On Sun, 05 Oct 2008 04:14:34 +0400, Nick Sabalausky <a a.a> wrote:

 I don't suppose DMD has any way to output a copy of what the source files
 look like after things like mixins, CTFE and versions are applied? (Sort
 of
 like running a C compiler with a "preprocess-only" flag). I don't see
 anything like this in the listed command-line params, but maybe I missed
 it.

 I have a program (that makes heavy use of mixins and CTFE and such) that
 gives wildly different output between two different versions of DMD/Tango
 (Tango's documented "breaking changes" don't appear to be the culprit and
 nothing in DMD's changelog or the latest bugzilla entries seem to
 immediately stick out). I'm sure I can track it down, but it would help to
 narrow things down if I could run the "preprocessed" results from both
 environments through a file diff.

D doesn't have a dedicated preprocessor and I believe all the mixins and stuff is applied and parsed of fly during AST construction, just like inlining is done on AST instead of codegen phase.

Yes, but that doesn't necessarily preclude it from being able to i.e. output the post-meta code using the same mechanism that outputs headers. One of the problems I do see with it, however, is template names - at least on Windows, DMD will attempt to compress and then ultimately MD5-hash long template names to work around limitations in the OMF object format it uses. These would not be valid D identifiers.
Oct 05 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 05 Oct 2008 18:31:47 +0400, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:

 On Sun, Oct 5, 2008 at 8:28 AM, Denis Koroskin <2korden gmail.com> wrote:
 On Sun, 05 Oct 2008 04:14:34 +0400, Nick Sabalausky <a a.a> wrote:

 I don't suppose DMD has any way to output a copy of what the source  
 files
 look like after things like mixins, CTFE and versions are applied?  
 (Sort
 of
 like running a C compiler with a "preprocess-only" flag). I don't see
 anything like this in the listed command-line params, but maybe I  
 missed
 it.

 I have a program (that makes heavy use of mixins and CTFE and such)  
 that
 gives wildly different output between two different versions of  
 DMD/Tango
 (Tango's documented "breaking changes" don't appear to be the culprit  
 and
 nothing in DMD's changelog or the latest bugzilla entries seem to
 immediately stick out). I'm sure I can track it down, but it would  
 help to
 narrow things down if I could run the "preprocessed" results from both
 environments through a file diff.

D doesn't have a dedicated preprocessor and I believe all the mixins and stuff is applied and parsed of fly during AST construction, just like inlining is done on AST instead of codegen phase.

Yes, but that doesn't necessarily preclude it from being able to i.e. output the post-meta code using the same mechanism that outputs headers. One of the problems I do see with it, however, is template names - at least on Windows, DMD will attempt to compress and then ultimately MD5-hash long template names to work around limitations in the OMF object format it uses. These would not be valid D identifiers.

Agree. There could also be some kind of mapping from compressed to original form, so that's hardly an issue. Besides, identifier compression shouldn't take place unless object file is about to be generated, right?
Oct 05 2008
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Nick Sabalausky escribió:
 I don't suppose DMD has any way to output a copy of what the source files 
 look like after things like mixins, CTFE and versions are applied? (Sort of 
 like running a C compiler with a "preprocess-only" flag). I don't see 
 anything like this in the listed command-line params, but maybe I missed it.
 
 I have a program (that makes heavy use of mixins and CTFE and such) that 
 gives wildly different output between two different versions of DMD/Tango 
 (Tango's documented "breaking changes" don't appear to be the culprit and 
 nothing in DMD's changelog or the latest bugzilla entries seem to 
 immediately stick out). I'm sure I can track it down, but it would help to 
 narrow things down if I could run the "preprocessed" results from both 
 environments through a file diff. 

Just for fun, I'll make a view in Descent that will show you exactly that. I believe DMD has all the information to output that, but not a switch. It'll also help me detect easier if there's a bug in CTFE or template instantiation (in Descent's port). Note that this will turn things like: const int x = 1 + 2 + 3 + 4; into const int x = 10; and: const int x = someFuncThatCanBeEvaluatedAtCompileTime(2); into: const int x = 20; I don't know if this is good or bad... I'll let you know when I'll have it done.
Oct 05 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 05 Oct 2008 19:01:41 +0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 Nick Sabalausky escribió:
 I don't suppose DMD has any way to output a copy of what the source  
 files look like after things like mixins, CTFE and versions are  
 applied? (Sort of like running a C compiler with a "preprocess-only"  
 flag). I don't see anything like this in the listed command-line  
 params, but maybe I missed it.
  I have a program (that makes heavy use of mixins and CTFE and such)  
 that gives wildly different output between two different versions of  
 DMD/Tango (Tango's documented "breaking changes" don't appear to be the  
 culprit and nothing in DMD's changelog or the latest bugzilla entries  
 seem to immediately stick out). I'm sure I can track it down, but it  
 would help to narrow things down if I could run the "preprocessed"  
 results from both environments through a file diff.

Just for fun, I'll make a view in Descent that will show you exactly that. I believe DMD has all the information to output that, but not a switch. It'll also help me detect easier if there's a bug in CTFE or template instantiation (in Descent's port). Note that this will turn things like: const int x = 1 + 2 + 3 + 4; into const int x = 10; and: const int x = someFuncThatCanBeEvaluatedAtCompileTime(2); into: const int x = 20; I don't know if this is good or bad... I'll let you know when I'll have it done.

The best thing whould be to view the code transformation step by step (using some slider at the bottom of view): // Step 1: const int x = mixin!("someFuncThatCanBeEvaluatedAtCompileTime(1 + 2 + 3 + 3)"); // Step 2: const int x = someFuncThatCanBeEvaluatedAtCompileTime(1 + 2 + 3 + 3); // Step 3: const int x = someFuncThatCanBeEvaluatedAtCompileTime(10); // Step 4: const int x = 42; This would be awesome, but I guess it's hardly possible :(
Oct 05 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Denis Koroskin escribió:
 On Sun, 05 Oct 2008 19:01:41 +0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 
 Nick Sabalausky escribió:
 I don't suppose DMD has any way to output a copy of what the source 
 files look like after things like mixins, CTFE and versions are 
 applied? (Sort of like running a C compiler with a "preprocess-only" 
 flag). I don't see anything like this in the listed command-line 
 params, but maybe I missed it.
  I have a program (that makes heavy use of mixins and CTFE and such) 
 that gives wildly different output between two different versions of 
 DMD/Tango (Tango's documented "breaking changes" don't appear to be 
 the culprit and nothing in DMD's changelog or the latest bugzilla 
 entries seem to immediately stick out). I'm sure I can track it down, 
 but it would help to narrow things down if I could run the 
 "preprocessed" results from both environments through a file diff.

Just for fun, I'll make a view in Descent that will show you exactly that. I believe DMD has all the information to output that, but not a switch. It'll also help me detect easier if there's a bug in CTFE or template instantiation (in Descent's port). Note that this will turn things like: const int x = 1 + 2 + 3 + 4; into const int x = 10; and: const int x = someFuncThatCanBeEvaluatedAtCompileTime(2); into: const int x = 20; I don't know if this is good or bad... I'll let you know when I'll have it done.

The best thing whould be to view the code transformation step by step (using some slider at the bottom of view): // Step 1: const int x = mixin!("someFuncThatCanBeEvaluatedAtCompileTime(1 + 2 + 3 + 3)"); // Step 2: const int x = someFuncThatCanBeEvaluatedAtCompileTime(1 + 2 + 3 + 3); // Step 3: const int x = someFuncThatCanBeEvaluatedAtCompileTime(10); // Step 4: const int x = 42; This would be awesome, but I guess it's hardly possible :(

It's possible. Another idea that I have is to be able to debug compile-time evaluation. So you would right click an expression, select "Debug Compile-Time Evaluation", and you'd be able to step through the evaluation, seeing values as they are transformed. That's a bit harder than the former idea. I wonder if somebody would find this useful... It seems like a really entertaining thing to implement. :-)
Oct 05 2008
parent reply BCS <ao pathlink.com> writes:
Reply to Ary,

 It's possible. Another idea that I have is to be able to debug
 compile-time evaluation. So you would right click an expression,
 select "Debug Compile-Time Evaluation", and you'd be able to step
 through the evaluation, seeing values as they are transformed. That's
 a bit harder than the former idea. I wonder if somebody would find
 this useful... It seems like a really entertaining thing to implement.
 :-)
 

Please Man, I'm begg'in you! Do it!
Oct 05 2008
parent reply Hoenir <mrmocool gmx.de> writes:
BCS schrieb:
 Reply to Ary,
 
 It's possible. Another idea that I have is to be able to debug
 compile-time evaluation. So you would right click an expression,
 select "Debug Compile-Time Evaluation", and you'd be able to step
 through the evaluation, seeing values as they are transformed. That's
 a bit harder than the former idea. I wonder if somebody would find
 this useful... It seems like a really entertaining thing to implement.
 :-)

Please Man, I'm begg'in you! Do it!

Any news?
Nov 19 2008
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Hoenir wrote:
 BCS schrieb:
 Reply to Ary,

 It's possible. Another idea that I have is to be able to debug
 compile-time evaluation. So you would right click an expression,
 select "Debug Compile-Time Evaluation", and you'd be able to step
 through the evaluation, seeing values as they are transformed. That's
 a bit harder than the former idea. I wonder if somebody would find
 this useful... It seems like a really entertaining thing to implement.
 :-)

Please Man, I'm begg'in you! Do it!

Any news?

Sorry, exams time. :(
Nov 19 2008