[Issue 23694] compilable/ctests2.c:51:9: error: initializer element is not constant
https://issues.dlang.org/show_bug.cgi?id=23694 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dlang.org pull request #3535 "fix Issue 23694 and Issue 23700 Document ImportC CTFE" was merged into master: - f89e67a7d88bc5792d2dec37620ab49180edc60a by Walter Bright: fix Issue 23694 and Issue 23700 Document ImportC CTFE https://github.com/dlang/dlang.org/pull/3535 --
[Issue 23694] compilable/ctests2.c:51:9: error: initializer element is not constant
https://issues.dlang.org/show_bug.cgi?id=23694 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @WalterBright created dlang/dlang.org pull request #3535 "fix Issue 23694 and Issue 23700 Document ImportC CTFE" fixing this issue: - fix Issue 23694 and Issue 23700 Document ImportC CTFE https://github.com/dlang/dlang.org/pull/3535 --
[Issue 23700] ImportC: Missing examples of ImportC leveraging CTFE
https://issues.dlang.org/show_bug.cgi?id=23700 --- Comment #6 from Walter Bright --- https://github.com/dlang/dlang.org/pull/3535 --
[Issue 23700] ImportC: Missing examples of ImportC leveraging CTFE
https://issues.dlang.org/show_bug.cgi?id=23700 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23694 --
[Issue 23694] compilable/ctests2.c:51:9: error: initializer element is not constant
https://issues.dlang.org/show_bug.cgi?id=23694 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23700 --
[Issue 23701] ImportC: __int64 is not documented as supported Visual C extension
https://issues.dlang.org/show_bug.cgi?id=23701 --- Comment #3 from Walter Bright --- I take that back. importc.h has a #define for it: #define __int64 long long --
[Issue 23727] ImportC support imaginary real numbers
https://issues.dlang.org/show_bug.cgi?id=23727 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #14902 "fix Issue 23727 - ImportC support imaginary real numbers" fixing this issue: - fix Issue 23727 - ImportC support imaginary real numbers https://github.com/dlang/dmd/pull/14902 --
[Issue 23727] New: ImportC support imaginary real numbers
https://issues.dlang.org/show_bug.cgi?id=23727 Issue ID: 23727 Summary: ImportC support imaginary real numbers Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: blocker Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com Successfully compiling gcc's complex.h requires supporting the `1.0iF` syntax. --
[Issue 23727] ImportC support imaginary real numbers
https://issues.dlang.org/show_bug.cgi?id=23727 Walter Bright changed: What|Removed |Added Keywords||ImportC --
[Issue 3720] Taking address of member functions possible without an instance
https://issues.dlang.org/show_bug.cgi?id=3720 --- Comment #24 from Bolpat --- @Zombine(In reply to ZombineDev from comment #18) > […] > > 2. After deprecation period is finished, reintroduce the > &. but with different semantics: retunring a > delegate with context pointer set to null. Why? If I want a delegate with a null pointer context and member function mfunc, today I can do ```d alias T = the-aggregate-type; auto dg = &(cast(T*)null).mfunc; ``` As an added benefit, it is absolutely clear what happens. If that is not defined behavior because of supposed null pointer dereference, we can just make it a special-case and allow it. --
[Issue 3720] Taking address of member functions possible without an instance
https://issues.dlang.org/show_bug.cgi?id=3720 dlang+iss...@me.tracemymail.com changed: What|Removed |Added CC|dlang+issues@me.tracemymail | |.com| --
[Issue 13511] std.traits.hasElaborateEquality!T
https://issues.dlang.org/show_bug.cgi?id=13511 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Component|dmd |phobos --
[Issue 13786] Test coverage for dmd is inadequate
https://issues.dlang.org/show_bug.cgi?id=13786 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #4 from RazvanN --- Is this still relevant? @Walter can we close this? --
[Issue 13786] Test coverage for dmd is inadequate
https://issues.dlang.org/show_bug.cgi?id=13786 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from RazvanN --- Tentatively closing. --
[Issue 13772] template capture error
https://issues.dlang.org/show_bug.cgi?id=13772 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |REMIND --- Comment #2 from RazvanN --- This bug report is incomprehensible. Please reopen if you have a better description. --
[Issue 13810] ICE in e2ir does not assert
https://issues.dlang.org/show_bug.cgi?id=13810 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 23702] compilable/test23616.c:3:20: error: missing binary operator before token "("
https://issues.dlang.org/show_bug.cgi?id=23702 --- Comment #4 from Iain Buclaw --- (In reply to Walter Bright from comment #3) > __has_extension is yet another C compiler extension (not ImportC's > invention). It's not GCC's invention either. Whose it is? It should be documented on the ImportC page. --
[Issue 23697] ImportC: No examples of invalid forward references in C code accepted by ImportC
https://issues.dlang.org/show_bug.cgi?id=23697
--- Comment #6 from Iain Buclaw ---
Missing definition of `T` in second example:
```
struct S s;
int* p = &s.t.x;
struct S { int a; struct T t; };
struct T { int b; int x; };
```
--
[Issue 23721] runnable/test22513.c:18:28: error: field ‘t’ has incomplete type
https://issues.dlang.org/show_bug.cgi?id=23721 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED CC||ibuc...@gdcproject.org Resolution|--- |DUPLICATE --- Comment #2 from Iain Buclaw --- *** This issue has been marked as a duplicate of issue 23697 *** --
[Issue 23697] ImportC: No examples of invalid forward references in C code accepted by ImportC
https://issues.dlang.org/show_bug.cgi?id=23697 --- Comment #5 from Iain Buclaw --- *** Issue 23721 has been marked as a duplicate of this issue. *** --
[Issue 23697] ImportC: No examples of invalid forward references in C code accepted by ImportC
https://issues.dlang.org/show_bug.cgi?id=23697
--- Comment #4 from Iain Buclaw ---
Another example of forward reference code that is accepted by ImportC, rejected
by standard C.
```
struct S s;
int* p = &s.t.x;
struct S { int a; struct T t; };
```
Giving both as examples on the ImportC documentation page would be good enough.
--
[Issue 23720] runnable/test22513.c:16:12: error: invalid use of undefined type ‘struct S’
https://issues.dlang.org/show_bug.cgi?id=23720 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Iain Buclaw --- *** This issue has been marked as a duplicate of issue 23697 *** --
[Issue 23697] ImportC: No examples of invalid forward references in C code accepted by ImportC
https://issues.dlang.org/show_bug.cgi?id=23697 --- Comment #3 from Iain Buclaw --- *** Issue 23720 has been marked as a duplicate of this issue. *** --
[Issue 23720] runnable/test22513.c:16:12: error: invalid use of undefined type ‘struct S’
https://issues.dlang.org/show_bug.cgi?id=23720 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to Walter Bright from comment #1) > ImportC allows forward references as an extension. Then it would be good to have it as another example for https://dlang.org/spec/importc.html#forward-references --
[Issue 23715] ImportC: No rejection of _Thread_local variables declared at function scope without "static" as per C11 6.2.4-5
https://issues.dlang.org/show_bug.cgi?id=23715 Iain Buclaw changed: What|Removed |Added Summary|compilable/testcstuff1.c:27 |ImportC: No rejection of |3:23: error: function-scope |_Thread_local variables |'tli' implicitly auto and |declared at function scope |declared '_Thread_local'|without "static" as per C11 ||6.2.4-5 --
[Issue 23717] runnable/bitfields.c:192:5: error: unknown type name S; use struct keyword to refer to the type
https://issues.dlang.org/show_bug.cgi?id=23717 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #14899 "fix Issue 23717 - runnable/bitfields.c:192:5: error: unknown type nam…" was merged into master: - 3d3f11e2cbbb9047e145197ec8dd70798ad993b7 by Walter Bright: fix Issue 23717 - runnable/bitfields.c:192:5: error: unknown type name S; use struct keyword to refer to the typ https://github.com/dlang/dmd/pull/14899 --
[Issue 23715] compilable/testcstuff1.c:273:23: error: function-scope 'tli' implicitly auto and declared '_Thread_local'
https://issues.dlang.org/show_bug.cgi?id=23715
Iain Buclaw changed:
What|Removed |Added
CC||ibuc...@gdcproject.org
--- Comment #2 from Iain Buclaw ---
(In reply to Walter Bright from comment #1)
> Shouldn't _Thread_local override the auto default?
It does not, and the C11 spec makes this clear:
This paragraph under C11 6.2.4 - Storage durations of objects
"""
C11 6.2.4-5:
An object whose identifier is declared with no linkage and without the
storage-class specifier `static` has *automatic storage duration*, as do some
compound literals. The result of attempting to indirectly access an object with
automatic storage duration from a thread other than the one with which the
object is associated is implementation-defined.
"""
So, top-level `_Thread_local` variables of course get either external or
internal linkage (depending on `static`). Local variables *always* have no
linkage unless declared `static`.
The correct test (that is also accepted by gcc/clang) would be:
```
void test2()
{
static _Thread_local int tli;
}
```
ImportC parser still needs fixing to reject invalid uses of `_Thread_local`.
--
[Issue 23712] ImportC: Unclear documentation of what type is inferred from integer literals (type of '9223372036854775808' is undefined)
https://issues.dlang.org/show_bug.cgi?id=23712 --- Comment #3 from Iain Buclaw --- (In reply to Iain Buclaw from comment #2) > Seems that it is undefined behaviour in C, as the test fails under gcc, but > passes for clang. > > https://godbolt.org/z/3hnjzMhfM Note that both *do* give warnings about it though, to make it abundantly clear this is not strictly deterministic code. --
[Issue 23712] ImportC: Unclear documentation of what type is inferred from integer literals (type of '9223372036854775808' is undefined)
https://issues.dlang.org/show_bug.cgi?id=23712 Iain Buclaw changed: What|Removed |Added Component|dmd |dlang.org --
[Issue 23712] ImportC: Unclear documentation of what type is inferred from integer literals (type of '9223372036854775808' is undefined)
https://issues.dlang.org/show_bug.cgi?id=23712 Iain Buclaw changed: What|Removed |Added Summary|compilable/testcstuff1.c:98 |ImportC: Unclear |:1: error: static assertion |documentation of what type |failed: |is inferred from integer |sizeof(9223372036854775808) |literals (type of |== 8|'9223372036854775808' is ||undefined) --
[Issue 23712] compilable/testcstuff1.c:98:1: error: static assertion failed: sizeof(9223372036854775808) == 8
https://issues.dlang.org/show_bug.cgi?id=23712 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to Walter Bright from comment #1) > Shouldn't it be promoted to a long, rather than an unsigned? That is certainly what our parser does as this is how D works. Seems that it is undefined behaviour in C, as the test fails under gcc, but passes for clang. https://godbolt.org/z/3hnjzMhfM Should we add a `u` suffix to that literal? Probably, as I'm not comfortable us testing undefined behaviour in the testsuite - even though it is *precisely defined* for us in the D parser. Maybe just document that we have a deterministic way of interpreting ambiguous integer literals in ImportC and be done with it. --
[Issue 23701] ImportC: __int64 is not documented as supported Visual C extension
https://issues.dlang.org/show_bug.cgi?id=23701 Iain Buclaw changed: What|Removed |Added Component|dmd |dlang.org Summary|compilable/test23214.c:3:26 |ImportC: __int64 is not |: error: expected ‘=’, ‘,’, |documented as supported |‘;’, ‘asm’ or |Visual C extension |‘__attribute__’ before | |‘uintptr_t’ | --
[Issue 23701] compilable/test23214.c:3:26: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘uintptr_t’
https://issues.dlang.org/show_bug.cgi?id=23701 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to Walter Bright from comment #1) > __int64 is a Microsoft C extension. Which needs documenting then https://dlang.org/spec/importc.html#visualc-extensions --
[Issue 23700] ImportC: Missing examples of ImportC leveraging CTFE
https://issues.dlang.org/show_bug.cgi?id=23700 --- Comment #5 from Iain Buclaw --- (In reply to Walter Bright from comment #4) > Indeed, CTFE is an ImportC extension. It's very useful for writing test > cases like these. Updated title, the page really should give some quick examples. --
[Issue 23700] ImportC: Missing examples of ImportC leveraging CTFE
https://issues.dlang.org/show_bug.cgi?id=23700 Iain Buclaw changed: What|Removed |Added Component|dmd |dlang.org Summary|compilable/test22842.c:64:2 |ImportC: Missing examples |4: error: expression in |of ImportC leveraging CTFE |static assertion is not | |constant| --
[Issue 23699] ImportC: Unclear documentation that struct/union/enum introduce implicit typedefs in ImportC
https://issues.dlang.org/show_bug.cgi?id=23699
--- Comment #3 from Iain Buclaw ---
The term used by C++ is "elaborated type specifier", which is used to
distinguish between types and regular identifiers.
For example, the following code is accepted by both C++ and ImportC
```
struct s { int a; };
void g(int s) {
struct s* p = (struct s*)malloc(sizeof(struct s));
p->a = s;
}
```
Whereas this is rejected by both C++ and ImportC, for the same reason.
```
struct s { int a; };
void g(int s) {
s* p = (s*)malloc(sizeof(s));
p->a = s;
}
```
--
[Issue 23699] ImportC: Unclear documentation that struct/union/enum introduce implicit typedefs in ImportC
https://issues.dlang.org/show_bug.cgi?id=23699 Iain Buclaw changed: What|Removed |Added Component|dmd |dlang.org Summary|compilable/test22807.c:10:1 |ImportC: Unclear |0: error: unknown type name |documentation that |‘OldFashionedHeader’|struct/union/enum introduce ||implicit typedefs in ||ImportC --
[Issue 23699] compilable/test22807.c:10:10: error: unknown type name ‘OldFashionedHeader’
https://issues.dlang.org/show_bug.cgi?id=23699 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to Walter Bright from comment #1) > ImportC deals with tag name spaces like C++ does. I.e. they are distinct > only if there is both a tag name declaration and a regular name declaration > both in the same scope. > > It shouldn't cause any more trouble than using a C++ compiler to compile C > code. There is a passing reference to this under Tag Symbols https://dlang.org/spec/importc.html#tag-symbols It sort of gets lost in the ether as a lot of the focus of that section points to the ImportC limitations, rather than extensions. --
[Issue 23698] ImportC: __stdcall is not documented as supported MSVC/DMC extensions
https://issues.dlang.org/show_bug.cgi?id=23698 Iain Buclaw changed: What|Removed |Added Component|dmd |dlang.org Summary|compilable/test22727.c:5:10 |ImportC: __stdcall is not |: error: expected ‘;’ |documented as supported |before ‘int’|MSVC/DMC extensions --
[Issue 23697] ImportC: No examples of invalid forward references in C code accepted by ImportC
https://issues.dlang.org/show_bug.cgi?id=23697 Iain Buclaw changed: What|Removed |Added Component|dmd |dlang.org Summary|compilable/test22705.c:4:1: |ImportC: No examples of |error: unknown type name|invalid forward references |‘Ta’|in C code accepted by ||ImportC --
[Issue 23698] compilable/test22727.c:5:10: error: expected ‘;’ before ‘int’
https://issues.dlang.org/show_bug.cgi?id=23698 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to Walter Bright from comment #1) > __stdcall is a Microsoft and Digital Mars C extension. Then it needs documenting under both MSVC and/or DMC sections of the importC page. https://dlang.org/spec/importc.html#visualc-extensions --
[Issue 23697] compilable/test22705.c:4:1: error: unknown type name ‘Ta’
https://issues.dlang.org/show_bug.cgi?id=23697
Iain Buclaw changed:
What|Removed |Added
CC||ibuc...@gdcproject.org
--- Comment #2 from Iain Buclaw ---
(In reply to Walter Bright from comment #1)
> ImportC, as an extension, allows forward referencing. As it relies on D for
> the semantic analysis, this is natural. It doesn't cause any harm, though.
>
> I recommend gcc just ignore this test.
The point is just to identify where we're deviating from standard C. Because
if we're not testing ImportC against actual C code, how can we call it a C
compiler?
I think having an example of such forward reference on the documentation page
would be enough to satisfy this isssue:
https://dlang.org/spec/importc.html#forward-references
Just give friendly names to the first example in this issue.
```
Ta *pa;
struct Sa { int x; };
typedef struct Sa Ta;
```
--
[Issue 22916] [dip1000] copy of ref return still treated as scope variable
https://issues.dlang.org/show_bug.cgi?id=22916 Dlang Bot changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Dlang Bot --- dlang/dmd pull request #14871 "Fix 22916 - copy of ref return still treated as scope variable" was merged into master: - 21375505508e2cc03395988de9702305c030378f by Dennis Korpel: Fix 22916 - copy of ref return still treated as scope variable https://github.com/dlang/dmd/pull/14871 --
[Issue 23693] ImportC: Unclear documentation of #line and linemarker support
https://issues.dlang.org/show_bug.cgi?id=23693 Iain Buclaw changed: What|Removed |Added Component|dmd |dlang.org Summary|compilable/testcstuff3.i:7: |ImportC: Unclear |1: error: stray '#' in |documentation of #line and |program |linemarker support --
[Issue 23693] compilable/testcstuff3.i:7:1: error: stray '#' in program
https://issues.dlang.org/show_bug.cgi?id=23693 --- Comment #3 from Iain Buclaw --- (In reply to Walter Bright from comment #2) > ImportC has to work with the output of C preprocessors other than gcc's. > There's not much I can do about that. I recommend gcc simply not run those > tests. The point of this is to find code that is not valid C. Be it because the standard says it's not supported, or it's a vendor-specific extension of C that we're testing in the wrong way. After all if they reject the way we're testing their own extensions, maybe we should reject them too. The ImportC documentation is pretty scant on actually saying what is accepted. https://dlang.org/spec/importc.html#preprocessor-directives Perhaps obvious enough to close this as wontfix (though I'd prefer to fix the GCC linemarker tests so they are *valid* examples of lines the preprocessor will pipe to ImportC). But not obvious enough that they are accepted even if there's been no preprocessing done on the input file. Maybe a couple examples of what forms of #line directive and linemarker are supported - same as the #pragma paragraph. --
[Issue 23692] ImportC: __pragma and __declspec are not documented as supported Visual C extensions
https://issues.dlang.org/show_bug.cgi?id=23692 --- Comment #3 from Iain Buclaw --- (In reply to Walter Bright from comment #2) > (In reply to Iain Buclaw from comment #1) > > 1. It would appear that `__pragma` and `__declspec` are MSVC extensions. > > That's correct. Just like ImportC adds extensions to try to get gcc .h files > to compile. OK, updated title and switched component over to dlang.org. --
[Issue 23692] ImportC: __pragma and __declspec are not documented as supported Visual C extensions
https://issues.dlang.org/show_bug.cgi?id=23692 Iain Buclaw changed: What|Removed |Added Component|dmd |dlang.org Summary|compilable/test22724.i:4:10 |ImportC: __pragma and |: error: unknown type name |__declspec are not |'pack' |documented as supported ||Visual C extensions --
[Issue 23691] compilable/test22294.i:16:1: error: unknown type name 'this'
https://issues.dlang.org/show_bug.cgi?id=23691 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #2 from Iain Buclaw --- (In reply to Walter Bright from comment #1) > The use of ^Z to indicate end of file is commonplace on Windows. It dates > back to DOS because the size of a file was the size it was on disk, so ^Z > was used to terminate it. So it's valid for a Windows C compiler, but not Linux? I doubt that there's any defined way to mark the end of a source file in C, so maybe mention this alternative form of `__EOF__` under https://dlang.org/spec/importc.html#visualc-extensions ? --
