www.digitalmars.com         C & C++   DMDScript  

D.gnu - ARM Cortex-M - Static array dyamically allocated

reply "Mike" <none none.com> writes:
I finally got a GDC cross-compiler built for the ARM Cortex-M, 
and it seems to generated executable code (code that can be 
executed).  I'm working on getting a *very* minimal D runtime so 
I can run a simple semihosted hello world program as I did with 
LDC here 
(http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22). 
  Please see the code there if you would like more context.

In my program, on this statement...

uint[3] message =
       [
	2, 			      //stderr
	cast(uint)"hello\r\n".ptr,    //ptr to string
	7                             //size of string
       ];

...GDC seems to generate a call to _d_arraycopy, which I've 
implemented, and another call to _d_arrayliteralTX, which I don't 
want to implement because it does a dynamic memory allocation.

I argue that this code should call neither _d_arraycopy, nor 
_d_arrayliteralTX because I believe everything should be known at 
compile time.

Is this a bug, by design, a temporary convenience?  Please advise 
and offer your suggestions?

Host: ArchLinux 64
arm-none-eabi-gdc (GCC) 4.8.2

Compilation: arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4 
-mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c 
-ffunction-sections -fno-exceptions -fdata-sections start.d 
object.d
Link: arm-none-eabi-ld -nodefaultlibs -nostdlib -nophoboslib 
-nostartfiles --gc-sections object.o start.o -o start.elf

Thanks,
Mike
Dec 18 2013
next sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
 Is this a bug, by design, a temporary convenience?  Please 
 advise and offer your suggestions?


IMHO it is not a bug. Even static arrays are dynamically 
allocated and then convert to static.

You can write this:

uint[3] message;
message[0] = 2;
message[1] = cast(uint)"hello\r\n".ptr;
message[2] = 7;
Dec 18 2013
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 18 December 2013 14:29, Daniel Kozak <kozzi11 gmail.com> wrote:

 Is this a bug, by design, a temporary convenience?  Please advise and
 offer your suggestions?



 IMHO it is not a bug. Even static arrays are dynamically allocated and then
 convert to static.


Not anymore, they are not.  It makes no sense to dynamically allocate
static arrays as they are passed around by value anyway...
Dec 18 2013
parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Wednesday, 18 December 2013 at 14:31:31 UTC, Iain Buclaw wrote:

 On 18 December 2013 14:29, Daniel Kozak <kozzi11 gmail.com> 
 wrote:

 Is this a bug, by design, a temporary convenience?  Please 
 advise and
 offer your suggestions?



 IMHO it is not a bug. Even static arrays are dynamically 
 allocated and then
 convert to static.


 Not anymore, they are not.  It makes no sense to dynamically 
 allocate
 static arrays as they are passed around by value anyway...



Wow, I miss this change :). Good to know.
Dec 18 2013
prev sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
 IMHO it is not a bug. Even static arrays are dynamically 
 allocated and then convert to static.


I mean everytime when you write [something, something else, ...] 
even if all members are known at compile time, it will create 
dynamic array.
Dec 18 2013
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 18 December 2013 14:14, Mike <none none.com> wrote:

 I finally got a GDC cross-compiler built for the ARM Cortex-M, and it seems
 to generated executable code (code that can be executed).  I'm working on
 getting a *very* minimal D runtime so I can run a simple semihosted hello
 world program as I did with LDC here
 (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22).
 Please see the code there if you would like more context.

 In my program, on this statement...

 uint[3] message =
       [
         2,                            //stderr
         cast(uint)"hello\r\n".ptr,    //ptr to string
         7                             //size of string
       ];

 ...GDC seems to generate a call to _d_arraycopy, which I've implemented, and
 another call to _d_arrayliteralTX, which I don't want to implement because
 it does a dynamic memory allocation.

 I argue that this code should call neither _d_arraycopy, nor
 _d_arrayliteralTX because I believe everything should be known at compile
 time.

 Is this a bug, by design, a temporary convenience?  Please advise and offer
 your suggestions?

 Host: ArchLinux 64
 arm-none-eabi-gdc (GCC) 4.8.2

 Compilation: arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4
 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c -ffunction-sections
 -fno-exceptions -fdata-sections start.d object.d
 Link: arm-none-eabi-ld -nodefaultlibs -nostdlib -nophoboslib -nostartfiles
 --gc-sections object.o start.o -o start.elf

 Thanks,
 Mike


Hi Mike,

This has been fixed to not call any library routines, but has not been
backported to the 4.8 branch yet.

This is something that will be done before New Years (if my list of
things to do does not grow even more...)
Dec 18 2013
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 18 Dec 2013 14:29:57 +0000
schrieb Iain Buclaw <ibuclaw gdcproject.org>:


 
 Hi Mike,
 
 This has been fixed to not call any library routines, but has not been
 backported to the 4.8 branch yet.
 
 This is something that will be done before New Years (if my list of
 things to do does not grow even more...)


I already have a personal branch with 2.064 backported to the gcc-4.8
branch:

https://github.com/jpf91/GDC/commits/arm-old

The changes are minimal, 3 commits reverted and this:
https://github.com/jpf91/GDC/commit/43e258300e8cecb961013630544027ab4bc5dd60

The main question is if we can simply use mark_decl_referenced as I did
there. If you think that's OK I can update the gcc-4.8 branch (of
course without the revert commits and instead doing proper
merges.)
Dec 18 2013
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 18 December 2013 15:17, Johannes Pfau <nospam example.com> wrote:

 Am Wed, 18 Dec 2013 14:29:57 +0000
 schrieb Iain Buclaw <ibuclaw gdcproject.org>:


 Hi Mike,

 This has been fixed to not call any library routines, but has not been
 backported to the 4.8 branch yet.

 This is something that will be done before New Years (if my list of
 things to do does not grow even more...)


 I already have a personal branch with 2.064 backported to the gcc-4.8
 branch:

 https://github.com/jpf91/GDC/commits/arm-old

 The changes are minimal, 3 commits reverted and this:
 https://github.com/jpf91/GDC/commit/43e258300e8cecb961013630544027ab4bc5dd60

 The main question is if we can simply use mark_decl_referenced as I did
 there. If you think that's OK I can update the gcc-4.8 branch (of
 course without the revert commits and instead doing proper
 merges.)


Maybe set force_output (instead of forced_by_abi) manually.
Dec 18 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 18 December 2013 15:17, Johannes Pfau <nospam example.com> wrote:

 Am Wed, 18 Dec 2013 14:29:57 +0000
 schrieb Iain Buclaw <ibuclaw gdcproject.org>:


 Hi Mike,

 This has been fixed to not call any library routines, but has not been
 backported to the 4.8 branch yet.

 This is something that will be done before New Years (if my list of
 things to do does not grow even more...)


 I already have a personal branch with 2.064 backported to the gcc-4.8
 branch:

 https://github.com/jpf91/GDC/commits/arm-old


Some remarks.

From:
https://github.com/jpf91/GDC/commit/f49267938b870f2c3e1712689db730a7ca6695b5

You probably want to keep the change:

#undef DEF_FUNCTION_TYPE_7

From: https://github.com/jpf91/GDC/commit/f4f7a7d770836f83a798dea6bc134f8dd270a516

Only the changes to d-system.h (and possibly d-lang.cc) broke the
build on gcc-4.8.  The rest are non-breaking changes that are
backwards compatible.

Regards
Iain
Dec 18 2013
prev sibling parent reply "Mike" <none none.com> writes:
On Wednesday, 18 December 2013 at 15:17:34 UTC, Johannes Pfau 
wrote:

 I already have a personal branch with 2.064 backported to the 
 gcc-4.8
 branch:

 https://github.com/jpf91/GDC/commits/arm-old


Thanks Iain and Johannes,

I've built Johannes's arm-old branch, but I can't yet get to the 
linker stage to test my original problem.  Instead, I'm now 
getting a new set of strange errors.  See below:

object.d:10: error: class Object only object.d can define this 
reserved class name
object.d:46: error: class TypeInfo only object.d can define this 
reserved class name
object.d:51: error: class TypeInfo_Array only object.d can define 
this reserved class name
object.d:61: error: class TypeInfo_Class only object.d can define 
this reserved class name
object.d:114: error: class TypeInfo_Interface only object.d can 
define this reserved class name
object.d:119: error: class TypeInfo_Struct only object.d can 
define this reserved class name
object.d:146: error: class TypeInfo_Pointer only object.d can 
define this reserved class name
object.d:151: error: class TypeInfo_Const only object.d can 
define this reserved class name
object.d:156: error: class TypeInfo_Typedef only object.d can 
define this reserved class name
object.d:163: error: class TypeInfo_Enum only object.d can define 
this reserved class name
object.d:10: error: class Object only object.d can define this 
reserved class name
object.d:46: error: class TypeInfo only object.d can define this 
reserved class name
object.d:51: error: class TypeInfo_Array only object.d can define 
this reserved class name
object.d:61: error: class TypeInfo_Class only object.d can define 
this reserved class name
object.d:114: error: class TypeInfo_Interface only object.d can 
define this reserved class name
object.d:119: error: class TypeInfo_Struct only object.d can 
define this reserved class name
object.d:146: error: class TypeInfo_Pointer only object.d can 
define this reserved class name
object.d:151: error: class TypeInfo_Const only object.d can 
define this reserved class name
object.d:156: error: class TypeInfo_Typedef only object.d can 
define this reserved class name
object.d:163: error: class TypeInfo_Enum only object.d can define 
this reserved class name

Two questions:
1) These are defined in my object.d, so why is it saying only 
object.d can define these types?
2) Why is there exactly two instances of each error message?

Again, here's my build line:
arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4 
-mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c 
-ffunction-sections -fno-exceptions -fdata-sections start.d 
object.d
Dec 20 2013
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
On Friday, 20 December 2013 at 15:03:52 UTC, Mike wrote:


 Two questions:
 1) These are defined in my object.d, so why is it saying only 
 object.d can define these types?
 2) Why is there exactly two instances of each error message?

 Again, here's my build line:
 arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4 
 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c 
 -ffunction-sections -fno-exceptions -fdata-sections start.d 
 object.d


Object.d seems to be a special case in many ways.
When building minlibd I was not able to have an empty or my own 
object.d and it had to be named object_.d
I do not remember any more what all the problems were.

Object.d (or .di) is always imported even if it is not mentioned. 
In this case gdc may find another object.d from the standard 
library. Current directory is not searched unless you put -I. to 
the command line. There may now be two conflicting files.
Dec 20 2013
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
On Friday, 20 December 2013 at 19:14:43 UTC, Timo Sintonen wrote:

 On Friday, 20 December 2013 at 15:03:52 UTC, Mike wrote:


 Two questions:
 1) These are defined in my object.d, so why is it saying only 
 object.d can define these types?
 2) Why is there exactly two instances of each error message?

 Again, here's my build line:
 arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4 
 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c 
 -ffunction-sections -fno-exceptions -fdata-sections start.d 
 object.d


 Object.d seems to be a special case in many ways.
 When building minlibd I was not able to have an empty or my own 
 object.d and it had to be named object_.d
 I do not remember any more what all the problems were.

 Object.d (or .di) is always imported even if it is not 
 mentioned. In this case gdc may find another object.d from the 
 standard library. Current directory is not searched unless you 
 put -I. to the command line. There may now be two conflicting 
 files.


Actually, the situation may also be the opposite:
object.d is found in the current directory and imported twice, 
but the current directory is not in the include search path and 
so the file is not accepted as a valid library file.
Dec 20 2013
parent reply "Mike" <none none.com> writes:
On Friday, 20 December 2013 at 20:18:43 UTC, Timo Sintonen wrote:

 Object.d seems to be a special case in many ways.
 When building minlibd I was not able to have an empty or my 
 own object.d and it had to be named object_.d
 I do not remember any more what all the problems were.

 Object.d (or .di) is always imported even if it is not 
 mentioned. In this case gdc may find another object.d from the 
 standard library. Current directory is not searched unless you 
 put -I. to the command line. There may now be two conflicting 
 files.


 Actually, the situation may also be the opposite:
 object.d is found in the current directory and imported twice, 
 but the current directory is not in the include search path and 
 so the file is not accepted as a valid library file.


Thanks Timo,

You're right: object.d and/or object.di are imported 
automatically from the current directory with or without the -I. 
option.  Therefore, removing object.d from my compile line got 
rid of the duplicate messages, but one instance still remains.

Here's my new compile line:
arm-none-eabi-gdc -I. -march=armv7e-m -mcpu=cortex-m4 
-mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c 
-ffunction-sections -fno-exceptions -fdata-sections start.d

notice I've removed object.d, but the file still exists in the 
same folder as start.d

I tried:
1) adding the -I. to the compile line to make my object.d 
*official*
2) moving my object.d to my default include folder
3) renaming object.d to object.di and repeating 1. and 2.
4) renaming object.d to object_.d and repeating 1. and 2.

All of these still produce the same error messages.  The 
interesting thing is I was able to compile my code with my build 
from the *official* GDC 4.8 branch; but Johannes's arm-old 
backport gives me the object.d errors.  So, something must have 
changed since the 4.8 branch.

If object.d is special, please let me know how its handled.  Is 
this actually a question for the DMD folks?

Thanks,
Mike
Dec 20 2013
parent reply "Mike" <none none.com> writes:
On Saturday, 21 December 2013 at 00:07:17 UTC, Mike wrote:

 On Friday, 20 December 2013 at 20:18:43 UTC, Timo Sintonen 
 wrote:

 Object.d seems to be a special case in many ways.
 When building minlibd I was not able to have an empty or my 
 own object.d and it had to be named object_.d
 I do not remember any more what all the problems were.

 Object.d (or .di) is always imported even if it is not 
 mentioned. In this case gdc may find another object.d from 
 the standard library. Current directory is not searched 
 unless you put -I. to the command line. There may now be two 
 conflicting files.


 Actually, the situation may also be the opposite:
 object.d is found in the current directory and imported twice, 
 but the current directory is not in the include search path 
 and so the file is not accepted as a valid library file.


 Thanks Timo,

 You're right: object.d and/or object.di are imported 
 automatically from the current directory with or without the 
 -I. option.  Therefore, removing object.d from my compile line 
 got rid of the duplicate messages, but one instance still 
 remains.

 Here's my new compile line:
 arm-none-eabi-gdc -I. -march=armv7e-m -mcpu=cortex-m4 
 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c 
 -ffunction-sections -fno-exceptions -fdata-sections start.d

 notice I've removed object.d, but the file still exists in the 
 same folder as start.d

 I tried:
 1) adding the -I. to the compile line to make my object.d 
 *official*
 2) moving my object.d to my default include folder
 3) renaming object.d to object.di and repeating 1. and 2.
 4) renaming object.d to object_.d and repeating 1. and 2.

 All of these still produce the same error messages.  The 
 interesting thing is I was able to compile my code with my 
 build from the *official* GDC 4.8 branch; but Johannes's 
 arm-old backport gives me the object.d errors.  So, something 
 must have changed since the 4.8 branch.

 If object.d is special, please let me know how its handled.  Is 
 this actually a question for the DMD folks?

 Thanks,
 Mike


I should probably add that if I remove my object.d file from the 
file system, I get:

cc1d: error: cannot find source code for runtime library file 
'object.d'
cc1d: note: dmd might not be correctly installed. Run 'dmd -man' 
for installation instructions.

I compiled gdc with the without the default phobos/runtime 
library, so my default include and lib folders are empty.

object.d: Can't compile with it; can't compile without it.
Dec 20 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 21, 2013 at 02:58:49AM +0100, Mike wrote:
[...]

 I should probably add that if I remove my object.d file from the
 file system, I get:
 
 cc1d: error: cannot find source code for runtime library file
 'object.d'
 cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for
 installation instructions.
 
 I compiled gdc with the without the default phobos/runtime library,
 so my default include and lib folders are empty.
 
 object.d: Can't compile with it; can't compile without it.


Well, then write your own object.d and edit dmd.conf (or the GDC
equivalent -- is there one?) to point to it. There's probably a bunch of
stuff you need to define (like class Object, etc.), but you can probably
stub out most of them.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze
Dec 20 2013
parent "Mike" <none none.com> writes:
On Saturday, 21 December 2013 at 03:07:45 UTC, H. S. Teoh wrote:

 On Sat, Dec 21, 2013 at 02:58:49AM +0100, Mike wrote:
 [...]

 I should probably add that if I remove my object.d file from 
 the
 file system, I get:
 
 cc1d: error: cannot find source code for runtime library file
 'object.d'
 cc1d: note: dmd might not be correctly installed. Run 'dmd 
 -man' for
 installation instructions.
 
 I compiled gdc with the without the default phobos/runtime 
 library,
 so my default include and lib folders are empty.
 
 object.d: Can't compile with it; can't compile without it.


 Well, then write your own object.d and edit dmd.conf (or the GDC
 equivalent -- is there one?) to point to it. There's probably a 
 bunch of
 stuff you need to define (like class Object, etc.), but you can 
 probably
 stub out most of them.


 T


Please read the entire thread.
Dec 20 2013
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 21 Dec 2013 02:58:49 +0100
schrieb "Mike" <none none.com>:


 On Saturday, 21 December 2013 at 00:07:17 UTC, Mike wrote:
 
 I should probably add that if I remove my object.d file from the 
 file system, I get:
 
 cc1d: error: cannot find source code for runtime library file 
 'object.d'
 cc1d: note: dmd might not be correctly installed. Run 'dmd -man' 
 for installation instructions.
 
 I compiled gdc with the without the default phobos/runtime 
 library, so my default include and lib folders are empty.
 
 object.d: Can't compile with it; can't compile without it.


Hi Mike,

the arm-old branch has a new frontend version (2.064), the official
gdc-4.8 branch is at (2.063) but I'll push an update today.

Anyway, dmd 2.064 behaves the same way, it seems dmd 2.064 is pickier
with object.d files. But what fixed it for me: Add a 'module object;'
line to your object.d file.
Dec 21 2013
parent reply "Mike" <none none.com> writes:
On Saturday, 21 December 2013 at 08:51:11 UTC, Johannes Pfau 
wrote:

 Am Sat, 21 Dec 2013 02:58:49 +0100
 schrieb "Mike" <none none.com>:


 On Saturday, 21 December 2013 at 00:07:17 UTC, Mike wrote:
 
 I should probably add that if I remove my object.d file from 
 the file system, I get:
 
 cc1d: error: cannot find source code for runtime library file 
 'object.d'
 cc1d: note: dmd might not be correctly installed. Run 'dmd 
 -man' for installation instructions.
 
 I compiled gdc with the without the default phobos/runtime 
 library, so my default include and lib folders are empty.
 
 object.d: Can't compile with it; can't compile without it.


 Hi Mike,

 the arm-old branch has a new frontend version (2.064), the 
 official
 gdc-4.8 branch is at (2.063) but I'll push an update today.

 Anyway, dmd 2.064 behaves the same way, it seems dmd 2.064 is 
 pickier
 with object.d files. But what fixed it for me: Add a 'module 
 object;'
 line to your object.d file.


That was it.  Thank you so much (I probably should have though of 
that myself).

My Minimal semihosted ARM Cortex-M Hello World is compiling with 
GDC and *executing* on my hardware.  If feel silly saying so, but 
I'm so excited to see the words "hello" appear on my screen.

I'll update the D Wiki today with my code.  Thanks everyone for 
the help.
Dec 21 2013
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
On Saturday, 21 December 2013 at 09:35:33 UTC, Mike wrote:

 On Saturday, 21 December 2013 at 08:51:11 UTC, Johannes Pfau 
 wrote:

 Am Sat, 21 Dec 2013 02:58:49 +0100
 schrieb "Mike" <none none.com>:


 On Saturday, 21 December 2013 at 00:07:17 UTC, Mike wrote:
 
 I should probably add that if I remove my object.d file from 
 the file system, I get:
 
 cc1d: error: cannot find source code for runtime library file 
 'object.d'
 cc1d: note: dmd might not be correctly installed. Run 'dmd 
 -man' for installation instructions.
 
 I compiled gdc with the without the default phobos/runtime 
 library, so my default include and lib folders are empty.
 
 object.d: Can't compile with it; can't compile without it.


 Hi Mike,

 the arm-old branch has a new frontend version (2.064), the 
 official
 gdc-4.8 branch is at (2.063) but I'll push an update today.

 Anyway, dmd 2.064 behaves the same way, it seems dmd 2.064 is 
 pickier
 with object.d files. But what fixed it for me: Add a 'module 
 object;'
 line to your object.d file.


 That was it.  Thank you so much (I probably should have though 
 of that myself).

 My Minimal semihosted ARM Cortex-M Hello World is compiling 
 with GDC and *executing* on my hardware.  If feel silly saying 
 so, but I'm so excited to see the words "hello" appear on my 
 screen.

 I'll update the D Wiki today with my code.  Thanks everyone for 
 the help.


Yes, it had to be something simple because library files are not 
different from other program files.

But then, what is the default module name of that file?
Gdc does not have a default search path and if I add -I. the 
current dir should be the search root.
Should the module name then default to the file name?
Is there a way to query and print the full module name at compile 
time?
Dec 21 2013
parent reply "Mike" <none none.com> writes:
On Saturday, 21 December 2013 at 10:14:18 UTC, Timo Sintonen 
wrote:

 Hi Mike,

 the arm-old branch has a new frontend version (2.064), the 
 official
 gdc-4.8 branch is at (2.063) but I'll push an update today.

 Anyway, dmd 2.064 behaves the same way, it seems dmd 2.064 is 
 pickier
 with object.d files. But what fixed it for me: Add a 'module 
 object;'
 line to your object.d file.


 That was it.  Thank you so much (I probably should have though 
 of that myself).

 My Minimal semihosted ARM Cortex-M Hello World is compiling 
 with GDC and *executing* on my hardware.  If feel silly saying 
 so, but I'm so excited to see the words "hello" appear on my 
 screen.

 I'll update the D Wiki today with my code.  Thanks everyone 
 for the help.


 Yes, it had to be something simple because library files are 
 not different from other program files.


I was wondering about that.  I couldn't tell if the library files 
received some extra treatment or not.


 But then, what is the default module name of that file?


Yep, just added "module object;" at the top of object.d.  I guess 
that's how it knows its the *real* object.d.


 Gdc does not have a default search path and if I add -I. the 
 current dir should be the search root.


I believe I have made false assumption that GDC looks in root 
"include" folder of my toolchain for .di files and the root "lib" 
folder for .a files.  I may be jumping to conclusions.



 Should the module name then default to the file name?
 Is there a way to query and print the full module name at 
 compile time?


Good questions, I'd like to know these myself. Iain? Johannes?
Dec 21 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 21 Dec 2013 11:34:29 +0100
schrieb "Mike" <none none.com>:


 

 Should the module name then default to the file name?
 Is there a way to query and print the full module name at 
 compile time?


 
 Good questions, I'd like to know these myself. Iain? Johannes?


It usually should default to the file name. I don't know why it doesn't
work for the object.d file, maybe a bug or maybe intentional. You
could file a bug against dmd or ask this question in the main
newsgroup.

You can get the module name using __MODULE__, to print it just use
pragma(msg, __MODULE__);
Dec 21 2013
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 21 December 2013 11:29, Johannes Pfau <nospam example.com> wrote:

 Am Sat, 21 Dec 2013 11:34:29 +0100
 schrieb "Mike" <none none.com>:


 Should the module name then default to the file name?
 Is there a way to query and print the full module name at
 compile time?


 Good questions, I'd like to know these myself. Iain? Johannes?


 It usually should default to the file name. I don't know why it doesn't
 work for the object.d file, maybe a bug or maybe intentional. You
 could file a bug against dmd or ask this question in the main
 newsgroup.



Answer is quite simply, the module name is only inferred after
parsing, until then, the parser does not know this is the object
module unless explicitly defined. Hence the errors.
Dec 21 2013
prev sibling parent "Mike" <none none.com> writes:
On Wednesday, 18 December 2013 at 14:30:12 UTC, Iain Buclaw wrote:

 This has been fixed to not call any library routines, but has 
 not been
 backported to the 4.8 branch yet.

 This is something that will be done before New Years (if my 
 list of
 things to do does not grow even more...)


Iain,

Prior to this change my implementation was snowballing with stuff 
that was just going to get stripped out by the linker in the end. 
Now the only extra code I need for my simple "Hello World" is 2 
lousy lines.

module object;
alias immutable(char)[]  string;

This is a huge win for me as I don't intend to port the entire D 
runtime, and I'm hoping the toolchain will only require me to add 
what's absolutely necessary for my code.

Thanks,
Mike
Dec 21 2013