[Issue 24215] std.traits.isBasicType!Enum should be false

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24215

--- Comment #3 from Dlang Bot  ---
dlang/phobos pull request #8841 "Revert "Fix Issue 24215 - isBasicType!Enum
should be false"" was merged into master:

- fa0307e09155b414c4718ea62557024d09b349af by Paul Backus:
  Revert "Fix Issue 24215 - isBasicType!Enum should be false"

  This reverts commit 98326c477f0f9555ca6ed3671fa4359a680e4c31.

https://github.com/dlang/phobos/pull/8841

--


[Issue 20166] among should have an overload for fixed-length arrays

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20166

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Nick Treleaven  ---
Marking as WONTFIX because `among` says use `canFind` to search a range.

--


[Issue 11111] std.algorithm.canFind should support Needles...

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=1

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Dlang Bot  ---
@ntrel created dlang/phobos pull request #8845 "Fix Issue 1 -
std.algorithm.canFind should support Needles..." fixing this issue:

- Fix Issue 1 - std.algorithm.canFind should support Needles...

  The requirement that each needle must be a range is arbitrary, so remove
  it.
  Note: This overload of `canFind` calls `find(haystack, needles)` which
  calls `startsWith`, which accepts mixed element and range needles.

https://github.com/dlang/phobos/pull/8845

--


[Issue 11111] std.algorithm.canFind should support Needles...

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=1

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #5 from Nick Treleaven  ---
> I don't think we have any version of find that accepts a variable amount of 
> needles

dlang.org/phobos/std_algorithm_searching.html#findAmong

--


[Issue 24230] New: Infinite loop in core.cpuid.getCpuInfo0B in Solaris/x86 kernel zone

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24230

  Issue ID: 24230
   Summary: Infinite loop in core.cpuid.getCpuInfo0B in
Solaris/x86 kernel zone
   Product: D
   Version: D2
  Hardware: x86_64
OS: Solaris
Status: NEW
  Severity: critical
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

Any program that pulls in core.cpuid results in an infinite loop when running
inside a Solaris kernel zone.

https://github.com/dlang/dmd/blob/d24a8859b090911a2a48cbbd7666ff7e448acfc8/druntime/src/core/cpuid.d#L672-L696


Quote from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
---
Running getCpuInfo0B side-by-side in the kernel zone and on bare metal shows:

kernel zone bare metal

  level 0

  a 0   1
  b 1   2

  level 1

  a 0   5
  b 1   28

  level 2

  a 0   0
  b 1   0

and so on for each higher level.  So inside a kernel zone, a!=0 || b!=0 remains
true, explaining the loop.

If I'm reading the spec (Intel® 64 and IA-32 Architectures
Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B,
3C, 3D, and 4, Order Number: 325462-081US, September 2023, Vol. 2A,
3-225, p.821) correctly, this is a bug in the kernel zone software:

A sub-leaf returning an invalid domain always returns 0 in EAX and EBX.

OTOH I don't see why getCpuInfo0B needs to loop here since it's only interested
in levels 0 and 1 anyway.
---

--


[Issue 24230] Infinite loop in core.cpuid.getCpuInfo0B in Solaris/x86 kernel zone

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24230

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@ibuclaw created dlang/dmd pull request #15778 "fix Issue 24230 - Infinite loop
in core.cpuid.getCpuInfo0B in Solaris/x86 kernel zone" fixing this issue:

- fix Issue 24230 - Infinite loop in core.cpuid.getCpuInfo0B in Solaris/x86
kernel zone

https://github.com/dlang/dmd/pull/15778

--


[Issue 11111] std.algorithm.canFind should support Needles...

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=1

Nick Treleaven  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--


[Issue 24187] ImportC: _Float32 not defined

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24187

--- Comment #14 from Walter Bright  ---
It's fixed in the reduced sample you provided. Can you try that with the
compiler?

--


[Issue 24200] ImportC: .di file collected macro conflicts with Special Token

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24200

--- Comment #3 from Walter Bright  ---
(In reply to dave287091 from comment #2)
> I think it’d be acceptable to just not emit them into the .di file. The
> __VERSION__ one especially as clang pre-defines that one and no one will
> want to use them. No one will want the conflicting macros anyway, but they
> currently prevent the .di file from being parsed.

I'm a bit reluctant to do that - silently removing things that don't work. The
user should be aware of what is not working so they can make appropriate
changes.

I'll think about it some more.

--


[Issue 24124] ImportC: building stb_image.h has errors in gcc

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24124

--- Comment #3 from Walter Bright  ---
Supporting gcc's instrinsic builtins would be a major project to add to dmd. If
your project needs them, pragmatically you'll need to use gdc/ldc.

--


[Issue 24124] ImportC: gcc simd intrinsics not supported by dmd

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24124

Walter Bright  changed:

   What|Removed |Added

Summary|ImportC: building   |ImportC: gcc simd
   |stb_image.h has errors in   |intrinsics not supported by
   |gcc |dmd

--


[Issue 24124] ImportC: gcc simd intrinsics not supported by dmd

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24124

--- Comment #4 from Dlang Bot  ---
@WalterBright created dlang/dmd pull request #15779 "Issue 24124 - ImportC: gcc
simd intrinsics not supported by dmd" mentioning this issue:

- Issue 24124 - ImportC: gcc simd intrinsics not supported by dmd

https://github.com/dlang/dmd/pull/15779

--


[Issue 24124] ImportC: gcc simd intrinsics not supported by dmd

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24124

--- Comment #5 from Walter Bright  ---
BTW, dmd supports all the x86 SIMD instructions in the inline assembler.

--


[Issue 24111] [ImportC] fatal error C1034: stdio.h: no include path set

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24111

--- Comment #3 from Walter Bright  ---
I don't really know how dmd can account for failure to install VisualStudio.
The error message is coming from VS, not dmd.

--


[Issue 24187] ImportC: _Float32 not defined

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24187

--- Comment #15 from mw  ---
I tried already, you can see from my previous post.

$ dmd --version
DMD64 D Compiler v2.106.0-beta.1

--


[Issue 24111] [ImportC] fatal error C1034: stdio.h: no include path set

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24111

--- Comment #4 from Richard Cattermole  ---
(In reply to Walter Bright from comment #3)
> I don't really know how dmd can account for failure to install VisualStudio.
> The error message is coming from VS, not dmd.

Visual Studio is installed.

The PATH variables are not setup, and therefore it appears to the toolchain as
though it hasn't been.

"x64 Native Tools Command Prompt for VS 2022.bat", basically dmd needs to
detect that bat file and automatically apply it before calling the cpp.

--


[Issue 24124] ImportC: gcc simd intrinsics not supported by dmd

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24124

mhh  changed:

   What|Removed |Added

 CC||maxha...@gmail.com

--- Comment #6 from mhh  ---
Guillaume has implemented most of the library of intel intrinsics in his
library if they are genuinely required (I have been saying this should be
pinched for druntime for a while alas he isn't keen)

--


[Issue 24111] [ImportC] fatal error C1034: stdio.h: no include path set

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24111

--- Comment #5 from Dlang Bot  ---
@kinke created dlang/dmd pull request #15780 "VSOptions: Prepare for setting
the INCLUDE env var for importC" mentioning this issue:

- VSOptions: Prepare for setting the INCLUDE env var for importC

  Upstreaming from LDC, to pave the way for fixing Issue 24111.

https://github.com/dlang/dmd/pull/15780

--


[Issue 24231] New: Can't emplace immutable nested class

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24231

  Issue ID: 24231
   Summary: Can't emplace immutable nested class
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: snarwin+bugzi...@gmail.com

As of DMD 2.105.3, the following program fails to compile.

---
void main()
{
import core.lifetime;

class O
{
int n = 123;
class I
{
int fun() => n;
}
}
auto buf = new void[](__traits(classInstanceSize, O.I));
emplace!(immutable(O.I))(buf, new immutable(O));
}
---

The error message is:

---
/usr/include/dmd/druntime/import/core/lifetime.d(116): Error: cannot modify
`immutable` expression `chunk.this`
/usr/include/dmd/druntime/import/core/lifetime.d(209): Error: template instance
`core.lifetime.emplace!(immutable(I), immutable(O))` error instantiating
test.d(14):instantiated from here: `emplace!(immutable(I),
immutable(O))`
---

This is caused by emplace attempting to set the .outer field of the emplaced
class instance to the value of its second argument (new immutable(O)). The
assignment fails, because the emplaced instance is immutable, and its fields
cannot be written to.

--


[Issue 24124] ImportC: gcc simd intrinsics not supported by dmd

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24124

--- Comment #7 from Walter Bright  ---
(In reply to mhh from comment #6)
> Guillaume has implemented most of the library of intel intrinsics in his
> library if they are genuinely required (I have been saying this should be
> pinched for druntime for a while alas he isn't keen)

Can you link to it here, please?

--


[Issue 24124] ImportC: gcc simd intrinsics not supported by dmd

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24124

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from Walter Bright  ---
1. dmd does not support gcc simd intrinsics, and is not likely to

2. the library in question has a #define for disabling use of those intrinsics,
and it's a 3rd party library

Hence, I'm going to resolve this as WONTFIX.

--


[Issue 24069] ImportC does not parse function pointer as parameter without name

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24069

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
Huh, I've never seen that before. Didn't even know it was legal. Not sure it
is.

--


[Issue 24230] Infinite loop in core.cpuid.getCpuInfo0B in Solaris/x86 kernel zone

2023-11-06 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=24230

Dlang Bot  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Dlang Bot  ---
dlang/dmd pull request #15778 "fix Issue 24230 - Infinite loop in
core.cpuid.getCpuInfo0B in Solaris/x86 kernel zone" was merged into stable:

- a52b48111411b0a88858f44db84cf6f3dfb8a1ca by Iain Buclaw:
  fix Issue 24230 - Infinite loop in core.cpuid.getCpuInfo0B in Solaris/x86
kernel zone

https://github.com/dlang/dmd/pull/15778

--