[Issue 22105] New: std.container.array.Array.length setter creates values of init-less types
https://issues.dlang.org/show_bug.cgi?id=22105
Issue ID: 22105
Summary: std.container.array.Array.length setter creates values
of init-less types
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
test.d ///
import std.container.array;
struct NonZero
{
private int n;
@disable this();
this(int n) { assert(n != 0); this.n = n; }
invariant { assert(n != 0); }
@property int value() const { return n; }
}
void main()
{
Array!NonZero a;
a.length = 5;
assert(a[0].n != 0);
}
///
This should not be allowed.
--
[Issue 21100] The internal data of std.container.array.Array cannot be referenced.
https://issues.dlang.org/show_bug.cgi?id=21100 Vladimir Panteleev changed: What|Removed |Added CC||dlang-bugzilla@thecybershad ||ow.net --- Comment #1 from Vladimir Panteleev --- You can use ([0])[0 .. arr.length]. --
[Issue 22103] importC: Parser accepts wrong syntax for array declarators
https://issues.dlang.org/show_bug.cgi?id=22103 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ibuclaw created dlang/dmd pull request #12816 "fix Issue 22103 - importC: Parser accepts wrong syntax for array declarators" fixing this issue: - fix Issue 22103 - importC: Parser accepts wrong syntax for array declarators https://github.com/dlang/dmd/pull/12816 --
[Issue 22104] New: importC: Parser accepts arrays with incomplete element types
https://issues.dlang.org/show_bug.cgi?id=22104 Issue ID: 22104 Summary: importC: Parser accepts arrays with incomplete element types Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ibuc...@gdcproject.org This is wrong code in C, but dmd CParser accepts it as valid. --- int array1[][4]; // NG: Requires explicit initializer int array2[4][]; // NG: Incomplete element type. // Multidimensional array must have bounds for all // dimensions except the first. int testfn(int p[4][]); // NG: Incomplete element type. // Proper way to "complete" type is to use `[*]` --- --
[Issue 22103] importC: Parser accepts wrong syntax for array declarators
https://issues.dlang.org/show_bug.cgi?id=22103 Iain Buclaw changed: What|Removed |Added Keywords||accepts-invalid, ImportC, ||rejects-valid CC||ibuc...@gdcproject.org --
[Issue 22103] New: importC: Parser accepts wrong syntax for array declarators
https://issues.dlang.org/show_bug.cgi?id=22103
Issue ID: 22103
Summary: importC: Parser accepts wrong syntax for array
declarators
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
Syntax in 6.7.6 is:
---
direct-declarator [ type-qualifier-list(opt) assignment-expression(opt) ]
direct-declarator [ static type-qualifier-list(opt) assignment-expression ]
direct-declarator [ type-qualifier-list static assignment-expression ]
direct-declarator [ type-qualifier-list(opt) * ]
---
But CParser instead parses C code as if it is instead:
---
direct-declarator [ assignment-expression(opt) ] type-qualifier-list(opt)
direct-declarator [ static assignment-expression(opt) ]
type-qualifier-list(opt)
direct-declarator [ * assignment-expression(opt) ] type-qualifier-list(opt)
---
E.g: This code is wrong, but dmd compiles it as valid.
---
void test(int arr[4] const, int val);
int main()
{
int array[4] const;
test(array, 4);
return 0;
}
---
Conversely, this code is correct, but dmd rejects it.
---
void test(int arr[restrict 4], int val);
int main()
{
int array[4];
test(array, 4);
return 0;
}
---
Implementation detail (C11 6.7.6.2-1): The optional type-qualifiers and the
keyword `static` shall appear only in a declaration of a function parameter
with an array type, and then only in the outermost array type derivation.
Meaning , this code should be rejected:
---
void badparam1(int arr[4][restrict]);
void badparam2(int arr[4][static 2]);
int var[static 4];
typedef int carray[const];
---
etc...
--
[Issue 22102] importC: Error: function is used as a type
https://issues.dlang.org/show_bug.cgi?id=22102 Iain Buclaw changed: What|Removed |Added Keywords||rejects-valid --
[Issue 22102] importC: Error: function is used as a type
https://issues.dlang.org/show_bug.cgi?id=22102 --- Comment #1 from Iain Buclaw --- Similar to issue 21992. While the rewrite could be handled by DeclarationExp semantic. There's no way to know that the original declaration had parenthesis around the variable name. e.g: If `e.declaration.type` resolves as a function declaration, how do we know whether the original code was `fn(p);` or `fn p;`? It's probably safer to first assume CallExp in CParser, as that's the most common usage of the ambiguous syntax. If `fn` is then found to be a type, rewrite it into a DeclarationExp. --
[Issue 22102] importC: Error: function is used as a type
https://issues.dlang.org/show_bug.cgi?id=22102 Iain Buclaw changed: What|Removed |Added Keywords||ImportC CC||ibuc...@gdcproject.org --
[Issue 22102] New: importC: Error: function is used as a type
https://issues.dlang.org/show_bug.cgi?id=22102
Issue ID: 22102
Summary: importC: Error: function is used as a type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
Reduced test:
---
void test(int *p)
{
}
int main()
{
int array[5];
test(array);
return 0;
}
---
The issue is that the parser can't disambiguate between `type(var)` the
declaration and `fncall(var)` the expression.
--
[Issue 21974] importC: Error: undefined identifier '__builtin_va_list'
https://issues.dlang.org/show_bug.cgi?id=21974 --- Comment #2 from Iain Buclaw --- Current workaround is to add `typedef` declarations in the "wrapper" sources. --
[Issue 22100] Support chained assignment of Nullable
https://issues.dlang.org/show_bug.cgi?id=22100 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #8158 "Fix Issue 22100 - Support chained assignment of Nullable" was merged into master: - e96d7a061426af80e47da6576dd5ab55b2feac85 by Vladimir Panteleev: Fix Issue 22100 - Support chained assignment of Nullable https://github.com/dlang/phobos/pull/8158 --
[Issue 20245] DIP1000: Should infer scope when taking address of ref
https://issues.dlang.org/show_bug.cgi?id=20245 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #4 from Dlang Bot --- @dkorpel created dlang/dmd pull request #12812 "Fix issue 20245 - address of ref should be scope" fixing this issue: - fix issue 20245 - address of ref should be scope https://github.com/dlang/dmd/pull/12812 --
[Issue 11521] Collision of templates instantiated with different same-named locals
https://issues.dlang.org/show_bug.cgi?id=11521 moonlightsenti...@disroot.org changed: What|Removed |Added Status|NEW |RESOLVED CC||moonlightsentinel@disroot.o ||rg Resolution|--- |FIXED --- Comment #4 from moonlightsenti...@disroot.org --- Fixed in 2.096.1 --
[Issue 22101] Nullable.get(fallback) cannot be used with non-@safe/pure/nothrow types
https://issues.dlang.org/show_bug.cgi?id=22101 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #8159 "Fix Issue 22101 - Nullable.get(fallback) cannot be used with non-@saf…" was merged into master: - 7d666a26c052a66fffb7c609c964a91525d3f3c2 by Vladimir Panteleev: Fix Issue 22101 - Nullable.get(fallback) cannot be used with non-@safe/pure/nothrow types https://github.com/dlang/phobos/pull/8159 --
[Issue 20248] Module constructors in executable called twice, never in loaded shared library
https://issues.dlang.org/show_bug.cgi?id=20248 kinke changed: What|Removed |Added CC||ki...@gmx.net --- Comment #1 from kinke --- This 'works' with LDC v1.27 (but DMD v2.097 still fails): 0x55debef38074 0x55debef34090 HI 0x7fdfb6c12064 0x7fdfb6c10870 I think this is more likely related to compiler differences wrt. relocation model, not a druntime divergence. --
[Issue 22101] Nullable.get(fallback) cannot be used with non-@safe/pure/nothrow types
https://issues.dlang.org/show_bug.cgi?id=22101 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @CyberShadow created dlang/phobos pull request #8159 "Fix Issue 22101 - Nullable.get(fallback) cannot be used with non-@saf…" fixing this issue: - Fix Issue 22101 - Nullable.get(fallback) cannot be used with non-@safe/pure/nothrow types https://github.com/dlang/phobos/pull/8159 --
[Issue 22101] New: Nullable.get(fallback) cannot be used with non-@safe/pure/nothrow types
https://issues.dlang.org/show_bug.cgi?id=22101
Issue ID: 22101
Summary: Nullable.get(fallback) cannot be used with
non-@safe/pure/nothrow types
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P3
Component: phobos
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
// test.d //
import std.typecons;
struct S
{
~this() {}
}
void main()
{
Nullable!S s;
s.get(S());
}
Outputs:
.../phobos/std/typecons.d(3091,24): Error: `pure` function
`std.typecons.Nullable!(S).Nullable.get!().get` cannot call impure destructor
`test.S.~this`
.../phobos/std/typecons.d(3091,24): Error: `@safe` function
`std.typecons.Nullable!(S).Nullable.get!().get` cannot call `@system`
destructor `test.S.~this`
test.d(5,2):`test.S.~this` is declared here
.../phobos/std/typecons.d(3091,24): Error: destructor `test.S.~this` is not
`nothrow`
.../phobos/std/typecons.d(3091,24): Error: `nothrow` function
`std.typecons.Nullable!(S).Nullable.get!().get` may throw
test.d(11,7): Error: template instance
`std.typecons.Nullable!(S).Nullable.get!()` error instantiating
--
