[Issue 15483] static if prevents inlining

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15483

--- Comment #1 from thomas.bock...@gmail.com ---
Perhaps related: https://issues.dlang.org/show_bug.cgi?id=15159

--


[Issue 15483] New: static if prevents inlining

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15483

  Issue ID: 15483
   Summary: static if prevents inlining
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thomas.bock...@gmail.com

module app;

void main() {
import std.stdio;

inlineme1(true);

inlineme2(true); // Error: function app.inlineme2 cannot inline function
}

@safe pragma(inline, true) {
bool inlineme1(bool left)
{
if(left)
return true;

return false;
}

bool inlineme2(bool left)
{
if(left)
return true;

static if(false)
{
/*
Even though it does absolutely nothing,
the mere presence of this block prevents inlining
of this function.
*/
}

return false;
}
}

This issue has been giving me a lot of trouble while working on checkedint, for
which inlining is critical to getting good performance.

I keep writing template functions which, if I instantiate the template by hand,
will inline fine, but refuse to do so if I let the compiler instantiate it for
me. I really don't want to be stuck using string mixins everywhere...

--


[Issue 15159] Static nested function prevent inlining

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15159

thomas.bock...@gmail.com changed:

   What|Removed |Added

 CC||thomas.bock...@gmail.com

--- Comment #1 from thomas.bock...@gmail.com ---
Perhaps related: https://issues.dlang.org/show_bug.cgi?id=15483

--


[Issue 15483] static if prevents inlining

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15483

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||performance
 CC||hst...@quickfur.ath.cx

--


[Issue 14255] Since DMD is used to build idgen, one can't have dmd.conf for dev and system wide.

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14255

--- Comment #7 from hst...@quickfur.ath.cx ---
https://github.com/D-Programming-Language/dmd/pull/5325

--


[Issue 14255] Since DMD is used to build idgen, one can't have dmd.conf for dev and system wide.

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14255

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--


[Issue 14255] Since DMD is used to build idgen, one can't have dmd.conf for dev and system wide.

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14255

--- Comment #6 from hst...@quickfur.ath.cx ---
Got bitten by this today. I have an old version of dmd for bootstrapping
purposes in /usr/src/d/install, and git checkout of dmd in /usr/src/d/dmd. This
setup used to work fine, except that recently, due to changes in
druntime/phobos, they no longer compile with the bootstrap version of dmd.

So the solution is to put a dmd.conf in /usr/src/d/install so that the old
compiler uses its own version of druntime/phobos, which it can compile. Now
/usr/src/d/dmd successfully compiles... except that now it can't link anything,
because it can't find the right dmd.conf, so it fails to find the correct
version of object.d.

Solution: put another dmd.conf in /usr/src/d/dmd so that the new compiler can
find the right paths, right? Yes, it works... however, now dmd cannot be
recompiled, because when posix.mak is running in /usr/src/d/dmd/src, it tries
to invoke HOST_DMD, and the old compiler picks up ./dmd.conf instead of the
correct one in /usr/src/d/install.  Worse, attempting to remedy this by
specifying -conf doesn't work, because posix.mak assumes HOST_DMD contains only
the pathname to the host dmd executable; any extra parameters appended to
HOST_DMD causes the existence check to fail and it refuses to run.

So now I'm stuck. The only way out I can see is to put dmd.conf in /etc or
$HOME, but that overrides the system-wide dmd.conf. So this is not workable
either.

I need a way to tell posix.mak to run HOST_DMD with additional flags. Is there
a way to do this??

--


[Issue 12233] Attempting to use TypeInfo.init results in a compiler error due to lack of 'this'.

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12233

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/04700217971964fdc8edb1798eaa669ec37fa7e9
rename TypeInfo's init method to initializer

"init" clashes with the type property of the same name.

Adding an alias called "init" to give people a chance to update their
code.

Further deprecation plan:
* 2.071: Do nothing. Keep both init and initializer functional for a while.
* 2.072: Deprecate the alias.
* 2.073: Replace the alias with an `@disable`d method.
* 2.074: Remove the init method, fixing issue 12233.

--


[Issue 15482] New: new uuid.d forbids to link statically with other libraries

2015-12-29 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15482

  Issue ID: 15482
   Summary: new uuid.d forbids to link statically with other
libraries
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

phobos_x64.lib(uuid.obj) : error LNK2005: CLSID_DirectInput already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: CLSID_DirectInputDevice already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_Button already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_ConstantForce already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_CustomForce already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_Damper already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_1394 already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_1394DEBUG already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_61883 already defined
in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_ADAPTER already defined
in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_APMSUPPORT already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_AVC already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_BATTERY already defined
in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_BLUETOOTH already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_CDROM already defined
in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_COMPUTER already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_DECODER already defined
in sdl_x64.lib(SDL_dxjoystick.obj)


And so on.
Why we ever export uuids from uuid.d ?

--