[Issue 22927] importC: 'struct already exists' with forward reference and function with same name
https://issues.dlang.org/show_bug.cgi?id=22927 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #13931 "fix Issue 22927 - importC: 'struct already exists' with forward refer…" fixing this issue: - fix Issue 22927 - importC: 'struct already exists' with forward reference and function with same name https://github.com/dlang/dmd/pull/13931 --
[Issue 22955] importC: wrong alignof for D struct with specified alignment
https://issues.dlang.org/show_bug.cgi?id=22955 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #13930 "fix Issue 22955 - importC: wrong alignof for D struct with specified …" fixing this issue: - fix Issue 22955 - importC: wrong alignof for D struct with specified alignment https://github.com/dlang/dmd/pull/13930 --
[Issue 22961] importC: K main function rejected
https://issues.dlang.org/show_bug.cgi?id=22961 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #13927 "Fix 22961 - Don't reject valid K main's in C files" was merged into master: - 9c367327d706b1ba4708b395f97a37bd4ab22d3b by MoonlightSentinel: Fix 22961 - Don't reject valid K main's in C files K functions are implicitly variadic and hence triggered the error if the declaration actually specified parameters (even if when their types are correct). This patch changes the check s.t. it allows implicitly variadic K functions in C files but still reports an error for explicit `...`. https://github.com/dlang/dmd/pull/13927 --
[Issue 22960] importC: K functions assume variadic calling convention
https://issues.dlang.org/show_bug.cgi?id=22960 --- Comment #4 from du...@neet.fi --- i thought this might be hard to explain the issue is that all K functions have this in the body: % dmd -c -vasm file2.c other: : 55 push RBP 0001: 48 8B EC mov RBP,RSP 0004: 48 81 EC D0 00 00 00 sub RSP,0D0h 000b: 48 89 B5 38 FF FF FF mov -0C8h[RBP],RSI 0012: 48 89 95 40 FF FF FF mov -0C0h[RBP],RDX 0019: 48 89 8D 48 FF FF FF mov -0B8h[RBP],RCX 0020: 4C 89 85 50 FF FF FF mov -0B0h[RBP],R8 0027: 4C 89 8D 58 FF FF FF mov -0A8h[RBP],R9 002e: 0F B6 C0 movzx EAX,AL 0031: C1 E0 02 shl EAX,2 0034: 4C 8D 1D 2A 00 00 00 lea R11,[02Ah][RIP] 003b: 49 29 C3 sub R11,RAX 003e: 48 8D 45 DF lea RAX,-021h[RBP] 0042: 41 FF E3 jmp R11D 0045: 0F 29 78 F1 movaps-0Fh[RAX],XMM7 0049: 0F 29 70 E1 movaps-01Fh[RAX],XMM6 004d: 0F 29 68 D1 movaps-02Fh[RAX],XMM5 0051: 0F 29 60 C1 movaps-03Fh[RAX],XMM4 0055: 0F 29 58 B1 movaps-04Fh[RAX],XMM3 0059: 0F 29 50 A1 movaps-05Fh[RAX],XMM2 005d: 0F 29 48 91 movaps-06Fh[RAX],XMM1 0061: 0F 29 40 81 movaps-07Fh[RAX],XMM0 0065: C7 40 01 08 00 00 00 mov dword ptr 1[RAX],8 006c: C7 40 05 30 00 00 00 mov dword ptr 5[RAX],030h 0073: 4C 8D 5D 10 lea R11,010h[RBP] 0077: 4C 89 58 09 mov 9[RAX],R11 007b: 48 2D AF 00 00 00sub EAX,0AFh 0081: 48 89 80 C0 00 00 00 mov 0C0h[RAX],RAX 0088: C9 leave 0089: C3 ret the jump there depends on the value of AL and will malfunction if it has a value other than 0-8 K functions are interchangeable with normal ones in gcc and clang, but not in dmd because of the dependence on AL/RAX being set to a valid value before calling (as is done when calling a variadic function) some libraries like zlib (and its bindings in phobos) depend on K functions being callable the same way as normal ones gcc/clang don't emit the code to save registers in K functions, and if va_start/etc can't be used inside one then there's no reason to --
[Issue 22962] New: issues.dlang.org: SSL peer certificate or SSH remote key was not OK on handle
https://issues.dlang.org/show_bug.cgi?id=22962
Issue ID: 22962
Summary: issues.dlang.org: SSL peer certificate or SSH remote
key was not OK on handle
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
---
import std.net.curl;
void main() { "https://issues.dlang.org".get; }
// std.net.curl.CurlException@std/net/curl.d(4402): SSL peer certificate or SSH
remote key was not OK on handle 56397DB61CE0
---
Exception is thrown when running on Ubuntu 21.10, but not when on 20.04. As
the same version of ca-certificates is installed on both set-ups, that might
mean the issue arises due to a change between openssl 1.1.1f and 1.1.1l.
The only problematic thing I can see at a glance is that this site's certs
aren't correctly installed. SSLlabs reports:
- Chain issues: Incorrect order, Extra certs.
--
[Issue 22496] importC: Error: illegal combination of type specifiers
https://issues.dlang.org/show_bug.cgi?id=22496 --- Comment #9 from Lance Bachmeier --- I closed it because it turned out to not be a bug. It's not wrong behavior because GCC extensions are not supported. They're supposed to be working on handling GCC extensions, so if this is still a problem once they release that support, that would really be a different issue anyway. --
[Issue 22496] importC: Error: illegal combination of type specifiers
https://issues.dlang.org/show_bug.cgi?id=22496
--- Comment #8 from Carsten Schlote ---
For everyone ending up here, due to this bug:
Using 'gcc -D_WCHAR_H -E -o output.i input.{c|h}' fixed the problem for me, as
it prevents 'wchar.h' to be included, which contained the problematic special
keywords of GCC.
Of course, this will only work, if you do not need wchar features in your
imported C sources.
--
[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing
https://issues.dlang.org/show_bug.cgi?id=17934 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #9 from Nick Treleaven --- (In reply to Mike Franklin from comment #7) > What about having `scope` apply to return values of functions, so `list()` > could be written as `scope List list() @trusted`? That might work there, but what about when a method wants to specify that the return value is `scope`? The `scope` attribute would be interpreted as applying to the `this` reference, when we might need a smaller scope. I really wish `this` parameter qualifiers were only allowed after the parameter list to avoid ambiguities. --
[Issue 22496] importC: Error: illegal combination of type specifiers
https://issues.dlang.org/show_bug.cgi?id=22496 Carsten Schlote changed: What|Removed |Added CC||carsten.schl...@gmx.net --- Comment #7 from Carsten Schlote --- Why is this closed? LDC can handle the _restricted keyword, DMD not. I'm currently using ImportC instead of handcrafted bindings, but actually I can't use DMD, when using the GCC -E option. --
[Issue 22961] importC: K main function rejected
https://issues.dlang.org/show_bug.cgi?id=22961 --- Comment #2 from moonlightsenti...@disroot.org --- Introduced by https://github.com/dlang/dmd/pull/13749 --
[Issue 22961] importC: K main function rejected
https://issues.dlang.org/show_bug.cgi?id=22961 moonlightsenti...@disroot.org changed: What|Removed |Added CC||moonlightsentinel@disroot.o ||rg Severity|normal |regression --
[Issue 22961] importC: K main function rejected
https://issues.dlang.org/show_bug.cgi?id=22961 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @MoonlightSentinel created dlang/dmd pull request #13927 "Fix 22961 - Don't reject valid K main's in C files" fixing this issue: - Fix 22961 - Don't reject valid K main's in C files K functions are implicitly variadic and hence triggered the error if the declaration actually specified parameters (even if when their types are correct). This patch changes the check s.t. it allows implicitly variadic K functions in C files but still reports an error for explicit `...`. https://github.com/dlang/dmd/pull/13927 --
[Issue 22960] importC: K functions assume variadic calling convention
https://issues.dlang.org/show_bug.cgi?id=22960
--- Comment #3 from Iain Buclaw ---
DMD's undoing here is that it set's up a va_list in the prologue, but k
functions are pseudo-variadic, so it can get away without having va_list.
In fact, it's an error to construct a va_list object in a k function in gcc:
---
void other(x)
int x;
{
__builtin_va_list argp;
__builtin_va_start(argp, x);
}
// file2.c: In function ‘other’:
// file2.c:5:3: error: ‘va_start’ used in function with fixed arguments
---
--
[Issue 22960] importC: K functions assume variadic calling convention
https://issues.dlang.org/show_bug.cgi?id=22960 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to Walter Bright from comment #1) > I don't really understand this. > > int printf(); > > is variadic. All K+R functions are variadic. I guess the difference is whether the body of `other` has code generated as-if it is variadic. Yes, variadic in the sense of "we accept any number of arguments to be called to us". But not variadic in that those extraneous arguments are ever read by the callee. --
[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing
https://issues.dlang.org/show_bug.cgi?id=17934 --- Comment #8 from Dlang Bot --- @dkorpel created dlang/dmd pull request #13926 "Revert "fix Issue 17934 - [scope] scopeness entrypoint for unique/ref…" mentioning this issue: - Revert "fix Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted missing" This reverts commit 18ad1685dcdca65070f7a1d89efa4410a5936895. https://github.com/dlang/dmd/pull/13926 --
[Issue 22960] importC: K functions assume variadic calling convention
https://issues.dlang.org/show_bug.cgi?id=22960 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- I don't really understand this. int printf(); is variadic. All K+R functions are variadic. --
[Issue 22935] importC: offsetof with array element gives 'dereference of invalid pointer'
https://issues.dlang.org/show_bug.cgi?id=22935 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #13925 "fix Issue 22935 - importC: offsetof with array element gives 'derefer…" fixing this issue: - fix Issue 22935 - importC: offsetof with array element gives 'dereference of invalid pointer' https://github.com/dlang/dmd/pull/13925 --
