[Issue 24773] Stable sort() invokes the destructor on uninitialized elements
https://issues.dlang.org/show_bug.cgi?id=24773 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #9049 "Fix Bugzilla 24773: don't invoke destructors on uninitialized elements in stable sort" was merged into master: - cfd577b28dead189f08bdf5d2b6c94b3352d0af5 by Sönke Ludwig: Fix Bugzilla 24773: Don't invoke destructors on uninitialized elements in stable sort Uses a regular initialized temporary array when sorting elements with an elaborate assignment to avoid undefined behavior when destructors, postblits or copy constructors are invoked during the array assignment. https://github.com/dlang/phobos/pull/9049 --
[Issue 24773] Stable sort() invokes the destructor on uninitialized elements
https://issues.dlang.org/show_bug.cgi?id=24773 --- Comment #1 from Dlang Bot --- @s-ludwig created dlang/phobos pull request #9049 "Bugzilla 24773 - don't invoke destructors on uninitialized elements in stable sort" mentioning this issue: - Bugzilla 24773 - don't invoke destructors on uninitialized elements in stable sort Uses a regular initialized temporary array when sorting elements with an elaborate assignment to avoid undefined behavior when destructors, postblits or copy constructors are invoked during the array assignment. https://github.com/dlang/phobos/pull/9049 --
[Issue 24773] New: Stable sort() invokes the destructor on uninitialized elements
https://issues.dlang.org/show_bug.cgi?id=24773
Issue ID: 24773
Summary: Stable sort() invokes the destructor on uninitialized
elements
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: slud...@outerproduct.org
The TimSort implementation creates a temporary uninitialized array for copying
ranges of elements to. While this works fine for POD values, element types with
an elaborate destructor/postblit/copy constructor will be invoked with
uninitialized data, possibly leading to crashes or data corruption.
Test case:
---
import std.algorithm;
struct S {
int i = 42;
~this() { assert(i == 42); }
}
void main()
{
auto array = new S[](400);
array.sort!((a, b) => false, SwapStrategy.stable);
}
---
--
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772
--- Comment #7 from Richard (Rikki) Andrew Cattermole
---
That does establish some casting should be valid.
I.e.
```d
import std.stdio;
void main() {
writeln(cast(size_t)cast(void*)new Object);
}
```
--
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 Tim changed: What|Removed |Added CC||tim.dl...@t-online.de --- Comment #6 from Tim --- (In reply to Richard (Rikki) Andrew Cattermole from comment #1) > The only thing you can do once you cast it is cause program corruption. > > Is there a benefit to being able to do this in ``@safe`` that I am not aware > of? One use case is printing the address of an object: ``` auto o = new Object(); writeln(cast(void*) o); ``` Addresses could also be compared for equality or used as keys in associative arrays. --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 --- Comment #5 from Richard (Rikki) Andrew Cattermole --- It is relevant because I am asking for justification of what you can do with it after casting which would also be @safe. Right now, we have no examples of this being a positive change, only negative ones. --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 --- Comment #4 from Georgy Markov --- (In reply to Richard (Rikki) Andrew Cattermole from comment #3) > > You have lost the type system guarantees, calling into unknown code. > > Which yes, if you passed the wrong arguments could have led to program > corruption. Irrelevant. The cause of possible memory corruption is function call, not pointer conversion. --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 --- Comment #3 from Richard (Rikki) Andrew Cattermole --- That code is unsafe. You have lost the type system guarantees, calling into unknown code. Which yes, if you passed the wrong arguments could have led to program corruption. --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772
--- Comment #2 from Georgy Markov ---
(In reply to Richard (Rikki) Andrew Cattermole from comment #1)
> The only thing you can do once you cast it is cause program corruption.
interface MyCOMInterface : IUnknown
{
/*...*/
}
MyCOMInterface comObject;
CoCreateInstance(
&clsid,
null,
CLSCTX_INPROC_SERVER,
&iid,
&cast(void*)comObject,
);
--
[Issue 24770] spam
https://issues.dlang.org/show_bug.cgi?id=24770 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |INVALID Summary|TWIN - TRANG CHỦ TẢI APP|spam |GAME TWIN68 CHÍNH THỨC 2024 | --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #1 from Richard (Rikki) Andrew Cattermole --- The only thing you can do once you cast it is cause program corruption. Is there a benefit to being able to do this in ``@safe`` that I am not aware of? --
[Issue 24772] New: Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772
Issue ID: 24772
Summary: Casting class references to void* should be @safe
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: safe
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ogion@gmail.com
Any pointer implicitly converts to void*. This is considered safe. Class
references are essentially pointers, but converting them to void* requires
implicit cast. This makes this conversion illegal in safe code, even though it
doesn’t violate memory safety.
class C {}
interface I {}
C c;
I i;
@safe void main()
{
auto cp = cast(void*)c; // Error: cast from `app.C` to `void*` not allowed
in safe code
auto ip = cast(void*)i; // Error: cast from `app.I` to `void*` not allowed
in safe code
}
--
[Issue 24771] New: apply qualifiers between `ref` and function name to return type
https://issues.dlang.org/show_bug.cgi?id=24771
Issue ID: 24771
Summary: apply qualifiers between `ref` and function name to
return type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
```d
struct S
{
int[] x;
ref const int[] f() => x;
}
```
In the above snipped, `const` applies to the implicit `this` parameter of `f`.
While prefix type qualifiers are widespread, qualifiers between `ref` and the
basic type part of the return type are probably unlikely in both human written
and generated code.
Maybe we could interpret this the same as `ref const(int[])` instead.
--
[Issue 24769] Add pragma compile on import
https://issues.dlang.org/show_bug.cgi?id=24769 --- Comment #5 from Richard (Rikki) Andrew Cattermole --- The -i switch suffers the same duplicate issues as the pragma, you should not have to be altering your compile command to remove this, nor tell the linker how to handle duplicates. Solving it for one, solves it for both. --
[Issue 24769] Add pragma compile on import
https://issues.dlang.org/show_bug.cgi?id=24769 --- Comment #4 from Richard (Rikki) Andrew Cattermole --- With dmd everything is weak, and will handle duplicates by-default. It is ldc and gdc which I have concerns with for duplicates. --
[Issue 24770] TWIN - TRANG CHỦ TẢI APP GAME TWIN68 CHÍNH THỨC 2024
https://issues.dlang.org/show_bug.cgi?id=24770 twin68vip5 changed: What|Removed |Added URL||https://twin68vip5.com/ --
[Issue 24770] New: TWIN - TRANG CHỦ TẢI APP GAME TWIN68 CHÍNH THỨC 2024
https://issues.dlang.org/show_bug.cgi?id=24770 Issue ID: 24770 Summary: TWIN - TRANG CHỦ TẢI APP GAME TWIN68 CHÍNH THỨC 2024 Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: twin68v...@gmail.com TWIN - TRANG CHỦ TẢI APP GAME TWIN68 CHÍNH THỨC 2024 TWIN Game bài đổi thưởng | Trang chủ twin68 chính thức | Link tải file apk và ios mới nhất 2024 - Nhận 888k ngay khi đăng ký tại twin68vip5.com Website: https://twin68vip5.com/ Địa chỉ: 10 Đ. Lê Hồng Phong, Phường 2, Quận 10, Hồ Chí Minh 70 Phone: 0969346450 Email: twin68v...@gmail.com Tags: #twin, #twin68 Google Sites: https://sites.google.com/view/twin68vip5 Google Maps: https://maps.app.goo.gl/pqKytobNgDYeoofa9 Social: https://localwiki.org/Users/twin68vip5 https://www.free-ebooks.net/profile/1585840/twin-trang-chu-tai-app-game-twin68-chinh-thuc-2024#gs.fdrnwe https://paizo.com/people/twin68vip5 https://v.gd/twin68vip5 https://help.forumfree.it/?act=Profile&MID=14144350 --
[Issue 24769] Add pragma compile on import
https://issues.dlang.org/show_bug.cgi?id=24769 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #3 from Adam D. Ruppe --- When is this actually useful? The case of the windows bindings' helper functions is already solved by a linker. If you try to separate compile anything with this pragma two things that depend on it in a diamond shape, you're liable to get duplicate symbols. Easy to solve with -i, but to clear how it would be solved with this pragma. --
[Issue 24769] Add pragma compile on import
https://issues.dlang.org/show_bug.cgi?id=24769 --- Comment #2 from Richard (Rikki) Andrew Cattermole --- It is part of PhobosV3, see Adam Wilson's DConf 2024 talk. A more concrete example of a module that would benefit from it is core.int128, but there are others such as the WinAPI bindings that have symbols declared that are not a binding. Oh and I've implemented it https://github.com/dlang/dmd/pull/16848 --
[Issue 24769] Add pragma compile on import
https://issues.dlang.org/show_bug.cgi?id=24769 Paul Backus changed: What|Removed |Added CC||snarwin+bugzi...@gmail.com --- Comment #1 from Paul Backus --- Where is the proposal for "the proposed phobos.sys.* package"? --
[Issue 24768] spam
https://issues.dlang.org/show_bug.cgi?id=24768 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |INVALID Summary|789Club - Cổng Game Đổi |spam |Thưởng Uy Tín, Tải Nhanh| |iOS/Android | --
[Issue 19329] pragms(lib) and pragma(linkerDirective) can emit duplicate entries to the object
https://issues.dlang.org/show_bug.cgi?id=19329 --- Comment #2 from Dlang Bot --- @thewilsonator updated dlang/dmd pull request #16849 "Do not emit duplicate string for `pragma([lib|linkerDirective])`" fixing this issue: - Fix bugzilla Issue 19329: Do not emit duplicate string for `pragma([lib|linkerDirective])` https://github.com/dlang/dmd/pull/16849 --
[Issue 24769] New: Add pragma compile on import
https://issues.dlang.org/show_bug.cgi?id=24769 Issue ID: 24769 Summary: Add pragma compile on import Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: alphaglosi...@gmail.com Sometimes it is useful to have modules that are always compiled into each binary that uses them. These import-only modules should be able to be imported by setting the import path, and the compiler will if it is used compile it in. A pragma in the module can specify this behaviour ``pragma(compileonimport);``. The existing solution for this is to use the ``-i`` switch. This may be a useful addition wrt. the proposed phobos.sys.* package, that could be import only. The only catch is the object file will need to enable multiple definitions to prevent linker errors. --
[Issue 24768] 789Club - Cổng Game Đổi Thưởng Uy Tín, Tải Nhanh iOS/Android
https://issues.dlang.org/show_bug.cgi?id=24768 789clubcoupons <789clubcoup...@gmail.com> changed: What|Removed |Added URL||https://789club.coupons/ --
[Issue 24768] New: 789Club - Cổng Game Đổi Thưởng Uy Tín, Tải Nhanh iOS/Android
https://issues.dlang.org/show_bug.cgi?id=24768 Issue ID: 24768 Summary: 789Club - Cổng Game Đổi Thưởng Uy Tín, Tải Nhanh iOS/Android Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: 789clubcoup...@gmail.com 789Club - Cổng Game Đổi Thưởng Uy Tín, Tải Nhanh iOS/Android 789Club là cổng game bài đổi thưởng nổi tiếng với đa dạng các thể loại trò chơi trực tuyến hấp dẫn như tiến lên, mậu binh, tài xỉu, xóc đĩa livestream, bắn cá, quay hũ và nhiều trò chơi khác. Với hệ thống nạp rút an toàn, nhanh chóng và đội ngũ hỗ trợ 24/7, 789Club đảm bảo mang đến trải nghiệm giải trí đẳng cấp cho mọi người chơi. Tham gia ngay trên web hoặc tải ứng dụng iOS/Android để trải nghiệm không giới hạn. Website: https://789club.coupons/ Địa chỉ: 368 Đ. Nguyễn Tất Thành, Phường 18, Quận 4, Hồ Chí Minh, Việt Nam Phone: 0903558651 Email: 789clubcoup...@gmail.com Tags: #789club, #nha_cai_789club, #game_doi_thuong, #danh_bai_online, #ca_cuoc_the_thao, #no_hu, #tai_xiu. #xoc_dia Google Sites: https://sites.google.com/view/789clubcoupons Social: https://linkpop.com/789clubcoupons https://www.slideserve.com/H135 https://www.doyoubuzz.com/789club-c-ng-game-d-i-th-ng-uy-tin-t-i-nhanh-ios-android https://my.omsystem.com/members/789clubcoupons https://www.mountainproject.com/user/201918063/trang-chu-789club --
[Issue 24766] SPAM
https://issues.dlang.org/show_bug.cgi?id=24766 anonymous4 changed: What|Removed |Added URL|https://vz99.sarl/ | --
[Issue 24767] New: Bad Signature
https://issues.dlang.org/show_bug.cgi?id=24767 Issue ID: 24767 Summary: Bad Signature Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: mcookspok...@gmail.com I imported the dlang keyring here: https://dlang.org/d-keyring.gpg. gpg --import d-keyring.gpg I Installed dlang dmd. curl -fsS https://dlang.org/install.sh | bash -s dmd. I got this error. Downloading https://dlang.org/d-keyring.gpg 100.0% gpg: Signature made Mon 13 Feb 2023 02:52:51 PM PST gpg:using RSA key E22EC04C82780970381402F4A7D4D42F8EC6A355 gpg: BAD signature from "Iain Buclaw " [unknown] Invalid signature https://dlang.org/d-keyring.gpg.sig I also tried this. gpg --search-keys "Iain Buclaw " I imported 1 and 2. Same error. --
[Issue 24765] spam
https://issues.dlang.org/show_bug.cgi?id=24765 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED URL|https://vz99.vet/ | CC||n...@geany.org Resolution|--- |INVALID Summary|VZ99|spam --
[Issue 24766] SPAM
https://issues.dlang.org/show_bug.cgi?id=24766 Dennis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID Summary|VZ99.COM|SPAM --
[Issue 24766] VZ99.COM
https://issues.dlang.org/show_bug.cgi?id=24766 vz99sarl changed: What|Removed |Added URL||https://vz99.sarl/ Summary|VZ99.COM|VZ99.COM --
[Issue 24766] New: VZ99.COM
https://issues.dlang.org/show_bug.cgi?id=24766 Issue ID: 24766 Summary: VZ99.COM Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: vz99s...@gmail.com VZ99.COM 🎖️ TRUY CẬP VZ99 CASINO KHÔNG BỊ CHẶN VZ99 đã có hơn 12 năm hoạt động trên thị trường cá cược châu Á. Nhà cái mang đến rất nhiều sản phẩm cá cược đặc biệt, chất lượng. Hệ thống chơi uy tín, … Website: https://vz99.sarl/ Địa chỉ: 565b Đ. Nguyễn Ảnh Thủ, Hiệp Thành, Quận 12, Hồ Chí Minh Phone: 0348465319 Email: vz99s...@gmail.com Tags: #vz99, #vz99_casino, #vz99casino, #nhà_cái_vz99, #VZ99_đăng_ký, #vz99_đăng_nhập, #đăng_nhập_vz99, #đăng_ký_vz99, #tải_app_vz99, #vz99_app, #vz99app, #tải_app_vz99, #Khuyến_mãi_vz99 Google Site: https://sites.google.com/view/vz99sarl Google Maps: https://maps.app.goo.gl/icEQN84oTmh1faHG6 Social: https://smallpdf.com/file#s=c7065437-e835-4fce-a6fb-d0773a53e4bd https://www.cryptocompare.com/profile/vz99sarl/#/activity https://ko-fi.com/vz99sarl https://seositecheckup.com/seo-audit/vz99.sarl https://data.world/vz99sarl --
[Issue 24765] VZ99
https://issues.dlang.org/show_bug.cgi?id=24765 vz99vet changed: What|Removed |Added URL||https://vz99.vet/ Summary|VZ99|VZ99 --
[Issue 23812] ImportC: allow adding function attributes to imported C functions
https://issues.dlang.org/show_bug.cgi?id=23812 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #16820 "Fix bugzilla 23812 - ImportC: allow adding function attributes to imp…" was merged into master: - d956dc0ccc458a8506a2776ebc1eb00ef5127685 by Tim Schendekehl: Fix bugzilla 23812 - ImportC: allow adding function attributes to imported C functions This adds a new pragma for ImportC, which allows to set default storage classes. Only `nothrow`, `@nogc` and `pure` are supported for now. They can be disabled later using `#pragma attribute(pop)`. Unknown storage classes are ignored. https://github.com/dlang/dmd/pull/16820 --
[Issue 24749] A clause consisting only of "throw" should be the unlikely path
https://issues.dlang.org/show_bug.cgi?id=24749 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16831 "fix Bugzilla Issue 24749 throw block moved to end of function" was merged into master: - bc6c9895b3d568ad4c85a6e092ad04ced437bf9a by Walter Bright: fix Bugzilla Issue 24749 throw block moved to end of function https://github.com/dlang/dmd/pull/16831 --
[Issue 24748] DMD can't output object files with fully qualified name, making -od overwirte each other file
https://issues.dlang.org/show_bug.cgi?id=24748 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16840 "Fix bugzilla 24748 - DMD can't output object files with fully qualifi…" was merged into master: - 9963dc1a5b74472c9f9add669a14be46400df426 by Dennis Korpel: Fix bugzilla 24748 - DMD can't output object files with fully qualified name, making -od overwirte each other file https://github.com/dlang/dmd/pull/16840 --
[Issue 24748] DMD can't output object files with fully qualified name, making -od overwirte each other file
https://issues.dlang.org/show_bug.cgi?id=24748 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16840 "Fix bugzilla 24748 - DMD can't output object files with fully qualifi…" fixing this issue: - Fix bugzilla 24748 - DMD can't output object files with fully qualified name, making -od overwirte each other file https://github.com/dlang/dmd/pull/16840 --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754 --- Comment #14 from Dennis --- (In reply to Nick Treleaven from comment #12) > The compiler doesn't know (without optimization or -dip1000) that the > program is equivalent to that. It could, all it needs to know is that typeof(Foo.foo) == typeof(new int[1]) == int[]. > It doesn't know below that `f` doesn't escape > the scope of foobar somehow. Doesn't mattter, `f` may escape, unless it's a `scope int[]`, which doesn't really exist without `-preview=dip1000`. --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
--- Comment #13 from Nick Treleaven ---
(In reply to Nick Treleaven from comment #3)
> @safe
> int* foobar()
> {
> int* f;
> foreach(ref e; foo)
> f = &e; // escaping address of foo[0]
> return f;
> }
BTW with dmd git master and -dip1000, the static array escape is now caught:
Error: scope variable `f` may not be returned
--
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
--- Comment #12 from Nick Treleaven ---
(In reply to Dennis from comment #8)
> Reduces to:
>
> ```D
> void main() @safe
> {
> foreach(ref e; new int[1])
> int* f = &e;
> }
> ```
The compiler doesn't know (without optimization or -dip1000) that the program
is equivalent to that. It doesn't know below that `f` doesn't escape the scope
of foobar somehow.
@safe
void foobar()
{
int* f;
foreach(ref e; foo)
f = &e;
}
So it seems counter-intuitive to the way D's semantic analysis works to allow
this case without -dip1000.
--
[Issue 24738] Import core.interpolation suggestion
https://issues.dlang.org/show_bug.cgi?id=24738 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16838 "Fix bugzilla 24738 - Import core.interpolation suggestion" was merged into master: - 69b2970ebcbbb579708c54965038184fd55613e0 by Dennis Korpel: Fix bugzilla 24738 - Import core.interpolation suggestion https://github.com/dlang/dmd/pull/16838 --
[Issue 24738] Import core.interpolation suggestion
https://issues.dlang.org/show_bug.cgi?id=24738 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16838 "Fix bugzilla 24738 - Import core.interpolation suggestion" fixing this issue: - Fix bugzilla 24738 - Import core.interpolation suggestion https://github.com/dlang/dmd/pull/16838 --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754 --- Comment #11 from Dennis --- > the same way this should compile > I'm glad if this is considered a design-flaw that should be fixed. Without `-preview=dip1000` taking the address of local, stack allocated variables is not @safe. This is not going to be fixed, we're not going to add special cases to allow a halfway, in between form of safe stack pointers. It's all or nothing. The question here is whether a `ref` variable counts as a local variable. `ref` parameters freely bind to any lvalue in @safe code, including local variables, so the answer there is yes. A ref loop variable in foreach is a bit more difficult, as it depends on the type of the thing you're iterating over. In theory, in the absence of -preview=dip1000, it can't be a stack pointer when you're iterating over a dynamic array, so this issue's test case can be made `@safe` on the basis of that. On the other hand, there's still the gaping hole that local static arrays can be sliced in `@safe` code without `-preview=dip1000`, and get an unrestricted lifetime. So fixing this issue facilitates more exploitation of that hole (issue 24750). So perhaps we need to make that a deprecation first and then consider adding a special for this, but whether that's worth it depends on the future direction of dip1000 vs Robert's Simple Safe D. --
[Issue 24763] Can't use struct initializer in an array literal
https://issues.dlang.org/show_bug.cgi?id=24763
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
Summary|Can't initialize a struct |Can't use struct
|with a static array |initializer in an array
||literal
--- Comment #3 from Nick Treleaven ---
> `a = {test: 1};` is an assign expression and the struct initalizer is not an
> expression. I think this all could be simplified and indeed the struct
> initializer should be accepted as an expression
Well then the parser would have to look ahead in function literals for a
semi-colon after an arbitrarily complex expression statement. Unless we make
`{...}` not a function literal and require `(){...}`.
--
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
--- Comment #10 from Dominikus Dittes Scherkl ---
(In reply to Luís Ferreira from comment #4)
> > Pointers are not allowed in @safe functions at all.
>
> What are you talking about? They are, its specified in the spec. 20.24.1.
> Safe Functions.
Sorry.
I misread your code. And of course the compiler could allow for some more
patterns to be considered @safe, but I thought that was intentional so.
E.g. the following (a simple self-reference check) is also not considered @safe
and I was told that this is intentional without DIP1000:
```
struct Foo
{
Foo opAssign(const ref Foo f)
{
if(&f == this) return this;
...
}
}
```
I'm glad if this is considered a design-flaw that should be fixed.
--
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
--- Comment #9 from Luís Ferreira ---
(In reply to Dennis from comment #8)
> Reduces to:
>
> ```D
> void main() @safe
> {
> foreach(ref e; new int[1])
> int* f = &e;
> }
> ```
Thanks! So, maybe this should also be valid, but more arguable if requires
dip1000 internal checks the same way with `ref`, although, spec-wise it should:
```
void main() @safe
{
foreach(e; new int[1])
int* f = &e;
}
```
I removed the `ref`, `f` doesn't escape its own scope, the same way this should
compile:
```
void main() @safe
{
int e;
int* f = &e;
}
```
--
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
Dennis changed:
What|Removed |Added
CC||dkor...@live.nl
--- Comment #8 from Dennis ---
Reduces to:
```D
void main() @safe
{
foreach(ref e; new int[1])
int* f = &e;
}
```
--
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754 Luís Ferreira changed: What|Removed |Added Keywords|accepts-invalid |rejects-valid --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
--- Comment #7 from Luís Ferreira ---
Funny enough, if you compile the initial code snippet with `-vcg-ast` (that
yields incorrect D code, but you can understand how it converts it to), it
pretty much converts it to something compatible like this, which is compilable:
```
struct Foo
{
int[] foo;
void foobar()
{
int* f = null;
{
int[] __r2 = this.foo[];
ulong __key3 = 0LU;
for (; __key3 < __r2.length; __key3 += 1LU)
{
int* e = &__r2[__key3];
f = e;
}
}
}
}
```
--
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754 --- Comment #6 from Luís Ferreira --- > > However, if Foo.foo is changed to `int[1] foo;`, it still won't error and > > it should Also the code you presented has a different type, even though trivially valid if you don't escape from within the function, which you do, so it doesn't apply to this particular issue. --- For the frontend folks, just ease this from DIP1000 preview flag, it doesn't make sense to be within the flag. --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754 --- Comment #5 from Luís Ferreira --- > If `&e` is the address of an int inside the `Foo.foo` array, then that is > fine so long as the array is null or GC allocated. Specification guarantees that only safe assignments are made, so, whatever is assigned to `foo`, unless its `= void` assignment, its safe to de-reference it, again, as long as the assignment is safe. > However, if Foo.foo is changed to `int[1] foo;`, it still won't error and it > should The code you presented escapes variables. The code I presented doesn't escape anything beyond its own scope, which is conceptually not escaping. Escaping is defined via DIP1000, and I'm not expecting the code to compile when escaping without defining `return` attribute to the member function. --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
--- Comment #4 from Luís Ferreira ---
> Pointers are not allowed in @safe functions at all.
What are you talking about? They are, its specified in the spec. 20.24.1. Safe
Functions.
Please don't close tickets as invalid as you see them and just because you
think they are invalid. It's not productive for anyone. Maybe someone else
sympathize with the same problem, you might not have enough understanding of
it, ask for elaboration, or present arguments against it...
---
> That's not a bug, it's a feature!
This is a bug, and an industry facing bug. Probably one of the reasons no one
at industry use or rely on it (e.g. like people do in Rust), in practice,
@safe, is because its buggy and have holes. Being restrictive at the point of
not allowing pointers is not a real feature, if D didn't allow pointers. It
would certainly make the feature even less adopted.
It's another question if we would discuss if D allows a subset of pointers only
(like ref variables, or like Zig does, define the pointer semantic restrictions
in the type), but that goes out of scope both from what is defined in spec and
what we have today.
Also if pointers was the real problem, explain why this code compiles:
```
struct Foo
{
int[] foo;
@safe
void foobar()
{
int* f;
foreach(i; 0 .. foo.length)
f = &foo[i];
}
}
void main()
{
Foo foo;
foo.foobar();
}
```
It uses pointers, doesn't it?
--
[Issue 24764] New: ICE when -vcg-ast prints imported invariant
https://issues.dlang.org/show_bug.cgi?id=24764
Issue ID: 24764
Summary: ICE when -vcg-ast prints imported invariant
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice
Severity: normal
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
Reduced from `imported!"std.outbuffer"`:
```
// a.d
template imported()
{
import imported = b;
}
alias x = imported!();
```
```
// b.d
struct O
{
invariant() {}
}
```
When compiling `dmd -vcg-ast a.d` you get:
```
core.exception.AssertError@src/dmd/hdrgen.d(1863): Assertion failure
```
The code in question being:
```D
void visitInvariantDeclaration(InvariantDeclaration d)
{
if (hgs.hdrgen)
return;
if (stcToBuffer(buf, d.storage_class))
buf.writeByte(' ');
buf.writestring("invariant");
if(auto es = d.fbody.isExpStatement())
{
assert(es.exp && es.exp.op == EXP.assert_); // FAILS, it's EXP.call
buf.writestring(" (");
(cast(AssertExp)es.exp).e1.expressionToBuffer(buf, hgs);
buf.writestring(");");
buf.writenl();
}
else
{
bodyToBuffer(d);
}
}
```
--
[Issue 24763] Can't initialize a struct with a static array
https://issues.dlang.org/show_bug.cgi?id=24763
RazvanN changed:
What|Removed |Added
Severity|blocker |enhancement
--- Comment #2 from RazvanN ---
(In reply to RazvanN from comment #1)
> A reduction of the test case:
>
> struct Test
> {
> int test;
> }
>
> void func(Test t) {}
>
> void main()
> {
>
> Test a = {test: 1};
> func({test: 1});
>
> }
>
> It seems that struct initializers only work when they are the rhs of an
> assign expression.
Now I get it. The struct initializer is an initializer, meaning that it's not
an expression. Initializer can only appear as part of variable declarations.
For example:
Test a;
a = {test: 1};
Doesn't compile either because `a = {test: 1};` is an assign expression and the
struct initalizer is not an expression. I think this all could be simplified
and indeed the struct initializer should be accepted as an expression, however,
this is not a bug, rather an enhancement request.
If you are blocked by this, just use the default constructor:
struct Test
{
int test;
}
struct Data
{
Test[1] test; // note that I changed this from Test[8] to Test[1]
// otherwise I had to put an array of 8 elements
}
void add(Data data)
{
}
void func(Test t) {}
extern(C) void main()
{
Test a = {test: 1};
add( Data(test: [ Test(1)] ) );
}
--
[Issue 24763] Can't initialize a struct with a static array
https://issues.dlang.org/show_bug.cgi?id=24763
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from RazvanN ---
A reduction of the test case:
struct Test
{
int test;
}
void func(Test t) {}
void main()
{
Test a = {test: 1};
func({test: 1});
}
It seems that struct initializers only work when they are the rhs of an assign
expression.
--
[Issue 24763] New: Can't initialize a struct with a static array
https://issues.dlang.org/show_bug.cgi?id=24763
Issue ID: 24763
Summary: Can't initialize a struct with a static array
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: blocker
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ryuukk@gmail.com
```D
struct Test
{
int test;
}
struct Data
{
Test[8] test;
}
void add(Data data)
{
}
extern(C) void main()
{
add( Data(test: [ {test: 1}] ) );
}
```
This doesn't compile, it should
--
[Issue 24762] @nogc false positive error
https://issues.dlang.org/show_bug.cgi?id=24762 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16835 "Fix Bugzilla Issue 24762 - @nogc false positive error" was merged into master: - d270e2e018a2973e627533eef498e841105fcd2f by RazvanN7: Fix Bugzilla Issue 24762 - @nogc false positive error https://github.com/dlang/dmd/pull/16835 --
[Issue 24760] ICE on variadic after default argument
https://issues.dlang.org/show_bug.cgi?id=24760 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16834 "Fix Bugzilla Issue 24760 - ICE on variadic after default argument" was merged into stable: - ba942e42d5b3a01d131950c06b26848172c2f830 by RazvanN7: Fix Bugzilla Issue 24760 - ICE on variadic after default argument https://github.com/dlang/dmd/pull/16834 --
[Issue 14651] Typesafe variadic parameter after optional parameter causes ICE
https://issues.dlang.org/show_bug.cgi?id=14651 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |DUPLICATE --- Comment #4 from RazvanN --- *** This issue has been marked as a duplicate of issue 24760 *** --
[Issue 24760] ICE on variadic after default argument
https://issues.dlang.org/show_bug.cgi?id=24760 RazvanN changed: What|Removed |Added CC||erikas.aub...@gmail.com --- Comment #2 from RazvanN --- *** Issue 14651 has been marked as a duplicate of this issue. *** --
[Issue 24762] @nogc false positive error
https://issues.dlang.org/show_bug.cgi?id=24762 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #16835 "Fix Bugzilla Issue 24762 - @nogc false positive error" fixing this issue: - Fix Bugzilla Issue 24762 - @nogc false positive error https://github.com/dlang/dmd/pull/16835 --
[Issue 24761] Access violation when inlining for 32 bit target.
https://issues.dlang.org/show_bug.cgi?id=24761 Bastiaan Veelo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Bastiaan Veelo --- The problem is not reproducible using current nightly build, and seems to have been fixed. --
[Issue 24760] ICE on variadic after default argument
https://issues.dlang.org/show_bug.cgi?id=24760 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #16834 "Fix Bugzilla Issue 24760 - ICE on variadic after default argument" fixing this issue: - Fix Bugzilla Issue 24760 - ICE on variadic after default argument https://github.com/dlang/dmd/pull/16834 --
[Issue 24762] New: @nogc false positive error
https://issues.dlang.org/show_bug.cgi?id=24762
Issue ID: 24762
Summary: @nogc false positive error
Product: D
Version: D2
Hardware: All
URL: http://dlang.org/
OS: All
Status: NEW
Severity: major
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: e...@weka.io
struct S { int m; }
string m() { return "m"; }
@nogc void f() {
S s;
auto x = __traits(getMember, s, m()); // Error: `@nogc` function `nogc.f`
cannot call non-@nogc function `nogc.m`
}
Of course, this can be worked around with:
enum M = m();
auto x = __traits(getMember, s, M);
But the m() call is in compile-time, and should not relate to the runtime @nogc
enforcement inside f().
--
[Issue 24761] New: Access violation when inlining for 32 bit target.
https://issues.dlang.org/show_bug.cgi?id=24761
Issue ID: 24761
Summary: Access violation when inlining for 32 bit target.
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: basti...@veelo.net
```d
float macht(float grondtal)
{
import std;
grondtal = abs(grondtal);
if (grondtal)
exp(grondtal);
return 1.0f;
}
void delft(float volume, float planeer_oppervlak, ref float totaal_weerstand)
{
float[] reken_matrix_1;
totaal_weerstand = macht(volume) + macht(volume) +
macht(planeer_oppervlak / macht(volume)) + macht(volume) +
1.0f / macht(volume) + reken_matrix_1[0] * (planeer_oppervlak /
macht(volume));
}
```
On Windows dmd v2.109.1 exits with error code -1073741819 (access violation)
when compiling the code above with options -inline -m32. No output or error
messages are produced.
--
[Issue 24760] New: ICE on variadic after default argument
https://issues.dlang.org/show_bug.cgi?id=24760 Issue ID: 24760 Summary: ICE on variadic after default argument Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: ice Severity: normal Priority: P3 Component: dmd Assignee: nob...@puremagic.com Reporter: dkor...@live.nl Sent to me by Bruce Carneal. ``` long f(int e = 0, uint[] optional...) => optional.length; long f0() => f(); // compiler segfaults ``` ``` core.exception.ArraySliceError@src/dmd/typesem.d(838): slice [1 .. 0] has a larger lower index than upper index ??:? onArraySliceError [0x5f0da9310bc6] ??:? _d_arraybounds_slicep [0x5f0da9300d36] src/dmd/typesem.d:838 int dmd.typesem.callMatch(... ``` --
[Issue 24758] spam
https://issues.dlang.org/show_bug.cgi?id=24758 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED URL|https://debet.expert/ | CC||n...@geany.org Resolution|--- |INVALID Summary|Debet - Nhà cái Debet cá|spam |cược thể thao, chơi là win | --
[Issue 24759] Order-dependent failure to create an overload set with template function
https://issues.dlang.org/show_bug.cgi?id=24759
--- Comment #1 from Max Samukha ---
Another manifestation of likely the same bug:
module a;
import std.range.primitives;
ref T front(T)(T* range) => range[0];
alias front = std.range.primitives.front;
void main()
{
}
a.d(6): Deprecation: package std.range is not accessible here, perhaps add
'static import std.range;'
a.d(6): Deprecation: module std.range.primitives is not accessible here,
perhaps add 'static import std.range.primitives;'
a.d(6): Deprecation: package std.range is not accessible here, perhaps add
'static import std.range;'
a.d(6): Deprecation: module std.range.primitives is not accessible here,
perhaps add 'static import std.range.primitives;'
--
[Issue 24759] New: Order-dependent failure to create an overload set with template function
https://issues.dlang.org/show_bug.cgi?id=24759
Issue ID: 24759
Summary: Order-dependent failure to create an overload set with
template function
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: maxsamu...@gmail.com
module b;
void foo() {}
module a;
import b;
void foo(T)(T a) {}
alias foo = b.foo;
void main()
{
foo();
foo(1);
}
a.d(6): Error: alias `a.foo` conflicts with template `a.foo(T)(T a)` at a.d(5)
The test case compiles if the alias declaration preceeds the template
declaration.
--
[Issue 24758] Debet - Nhà cái Debet cá cược thể thao, chơi là win
https://issues.dlang.org/show_bug.cgi?id=24758 debetexpert changed: What|Removed |Added URL||https://debet.expert/ --
[Issue 24758] New: Debet - Nhà cái Debet cá cược thể thao, chơi là win
https://issues.dlang.org/show_bug.cgi?id=24758 Issue ID: 24758 Summary: Debet - Nhà cái Debet cá cược thể thao, chơi là win Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: nhacaidebetexp...@gmail.com Debet - Nhà cái Debet cá cược thể thao, chơi là win Debet là nhà cái cá cược thể thao đậm nét Việt với chất lượng châu Âu . Vào Debet, chơi là win. Debet còn có nhiều Game bài vip. Debet tự hào là nhà tài trợ chính cho CLB Wolves Ngoại hạng Anh Mùa giải 2024-2026 Website: https://debet.expert/ Địa chỉ: 7 Hoàng Hoa Thám, Phường 6, Bình Thạnh, Hồ Chí Minh, Việt Nam Phone: 033988 Email: nhacaidebetexp...@gmail.com Tags: #debet, #debetexpert, #nha_cai_debet, #choi_la_win Google Sites: https://sites.google.com/view/debetexpert Social: https://www.shadertoy.com/user/debetexpert https://community.arlo.com/t5/user/viewprofilepage/user-id/997159 https://community.networkofcare.org/blogs/debet_-_nh_ci_debet_c_cc_th_thao_chi_l_win/archive/2024/09/09/debet-nh-224-c-225-i-debet-c-225-c-c-th-thao-ch-i-l-224-win.aspx https://v.gd/debetexpert https://openagenda.com/en/debetexpert --
[Issue 24757] Escaping with typesafe variadic functions is not detected, making @safe code potentially unsafe
https://issues.dlang.org/show_bug.cgi?id=24757 Jonathan M Davis changed: What|Removed |Added Keywords||safe --
[Issue 24750] escaping sliced stack arrays not detected
https://issues.dlang.org/show_bug.cgi?id=24750 --- Comment #4 from Jonathan M Davis --- A similar issue: https://issues.dlang.org/show_bug.cgi?id=24757 --
[Issue 24757] New: Escaping with typesafe variadic functions is not detected, making @safe code potentially unsafe
https://issues.dlang.org/show_bug.cgi?id=24757
Issue ID: 24757
Summary: Escaping with typesafe variadic functions is not
detected, making @safe code potentially unsafe
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: issues.dl...@jmdavisprog.com
This code compiles and runs, but the assertion fails
---
void main() @safe
{
auto arr = bar();
assert(arr == [1, 2, 3]);
}
int[] foo(int[] args...) @safe
{
auto saved = args;
return saved;
}
int[] bar() @safe
{
return foo(1, 2, 3);
}
---
If you have
---
void main() @safe
{
auto arr = foo(1, 2, 3);
assert(arr == [1, 2, 3]);
}
int[] foo(int[] args...) @safe
{
auto saved = args;
return saved;
}
---
it works - presumably because the array ends up sitting on the stack in main in
that case - but it's still not actually memory safe.
If you have
---
void main() @safe
{
auto arr = foo(1, 2, 3);
assert(arr == [1, 2, 3]);
}
int[] foo(int[] args...) @safe
{
return args;
}
---
then the compiler catches it with
---
q.d(9): Error: returning `args` escapes a reference to variadic parameter
`args`
---
but once you slice the array, it can no longer catch the problem, making it so
that @safe code is not actually memory safe.
The issue is pretty similar to what happens with slicing static arrays -
https://issues.dlang.org/show_bug.cgi?id=24750 - in that DIP 1000 does solve
the problem, but without it, we have a hole in @safe. Also, just like with
static arrays, slicing the array is caught when returning it directly but isn't
otherwise (without DIP 1000).
If we want to close the hole without needing DIP 1000, it seems to me that we
either need to make it so that typesafe variadic functions are not considered
@safe, or we need the compiler to flag anywhere that slices the variadic array
as @system (even if it's implicit like when passing it to a function or using
auto to slice the entire array). Making it @system to slice the variadic array
would likely be the better choice, because then more code can be @safe, though
I expect that a large percentage of such functions will ultimately have to be
@trusted anyway, since in most cases, you're probably going to want to slice
the array rather than simply access its elements.
Also, special attention may have to be take with foreach, since depending on
how that's implemented, it could be slicing the array, but if it is, it's
guaranteed that the slice isn't escaping, because the compiler is doing it in a
way that it can't escape. But it could be that that's simply lowered to using
for with an index, in which case, no slicing actually happens, and it's a
non-issue. I just bring it up, since it occurs to me that it might be, and it
should not be flagged as @system.
But regardless of how we want to solve it, as things stand, without DIP 1000,
it's very possible to escape a variadic array from an @safe function.
--
[Issue 24756] New: SIGRTMIN and SIGRTMIN+1 previous sigaction are being silently ignored when set by crt_constructor
https://issues.dlang.org/show_bug.cgi?id=24756 Issue ID: 24756 Summary: SIGRTMIN and SIGRTMIN+1 previous sigaction are being silently ignored when set by crt_constructor Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: cont...@lsferreira.net Libraries that implement crt0 constructor (crt_constructor) that set SIGRTMIN and SIGRTMIN+1 get silently ignored after runtime initialisation as it overrides without checking sigaction previous assignments. As specified by POSIX, this should be checked and SIGRTMIN+n should have runtime checks, and not hardcoded. Runtime, at bare minimum, should assert when silently trying to override a previous sigaction. --
[Issue 24755] spam
https://issues.dlang.org/show_bug.cgi?id=24755 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED URL|https://w88.sydney | CC||n...@geany.org Resolution|--- |INVALID Summary|W88 - Link vào W88 mới |spam |nhất, trải nghiệm mượt mà | |Mobile | --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
--- Comment #3 from Nick Treleaven ---
> This might be a bug, DIP1000 should be catching this I think.
If `&e` is the address of an int inside the `Foo.foo` array, then that is fine
so long as the array is null or GC allocated.
However, if Foo.foo is changed to `int[1] foo;`, it still won't error and it
should:
```d
import std.stdio;
struct Foo
{
int[1] foo;
@safe
int* foobar()
{
int* f;
foreach(ref e; foo)
f = &e; // escaping address of foo[0]
return f;
}
}
void main() @safe
{
int* p;
{
Foo foo = Foo([1]);
//writeln(&foo.foo[0]);
p = foo.foobar();
}
p.writeln();
(*p).writeln();
}
```
--
[Issue 24755] W88 - Link vào W88 mới nhất, trải nghiệm mượt mà Mobile
https://issues.dlang.org/show_bug.cgi?id=24755 w88sydney changed: What|Removed |Added URL||https://w88.sydney --
[Issue 24745] Better error message when creating an associative array with the wrong syntax
https://issues.dlang.org/show_bug.cgi?id=24745 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @royalpinto007 updated dlang/dmd pull request #16832 "fix 24745 - improve associative array syntax error message" fixing this issue: - fix Bugzilla 24745 - improve associative array syntax error message Signed-off-by: royalpinto007 fix 24745 - issue line Signed-off-by: royalpinto007 https://github.com/dlang/dmd/pull/16832 --
[Issue 24752] betterC memset link errors with template+array
https://issues.dlang.org/show_bug.cgi?id=24752 tg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from tg --- Resolved. --
[Issue 24752] betterC memset link errors with template+array
https://issues.dlang.org/show_bug.cgi?id=24752 --- Comment #2 from tg --- I just tested again with DMD64 D Compiler v2.104.2 on Alpine Linux and with DMD64 D Compiler v2.109.1 on Void Linux, they both work. I should have tested with a more recent version first. Sorry about that. --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added Keywords||accepts-invalid, safe Priority|P1 |P3 Status|RESOLVED|REOPENED CC||alphaglosi...@gmail.com Resolution|INVALID |--- --- Comment #2 from Richard (Rikki) Andrew Cattermole --- This might be a bug, DIP1000 should be catching this I think. I checked, and with it turned on it did not catch it. But yes, a pointer is allowed in @safe functions, including taking a pointer of currently. --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754 Dominikus Dittes Scherkl changed: What|Removed |Added Status|NEW |RESOLVED CC||domini...@scherkl.de Resolution|--- |INVALID --- Comment #1 from Dominikus Dittes Scherkl --- Pointers are not allowed in @safe functions at all. That's not a bug, it's a feature! --
[Issue 24754] cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754 Luís Ferreira changed: What|Removed |Added Hardware|x86_64 |All OS|Linux |All Severity|enhancement |normal --
[Issue 24754] New: cannot take address of a member array in a ref foreach
https://issues.dlang.org/show_bug.cgi?id=24754
Issue ID: 24754
Summary: cannot take address of a member array in a ref foreach
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: cont...@lsferreira.net
The following code should compile:
```
struct Foo
{
int[] foo;
@safe
void foobar()
{
int* f;
foreach(ref e; foo)
f = &e;
}
}
void main()
{
Foo foo;
foo.foobar();
}
```
Shouldn't yield:
```
Up to 2.078.3: Failure with output: onlineapp.d(10): Error: cannot take
address of local e in @safe function foobar
Since 2.079.1: Failure with output: onlineapp.d(10): Error: cannot take
address of local `e` in `@safe` function `foobar`
```
--
[Issue 24751] [std.container.binaryheap] example uses heapify but there is no documentation
https://issues.dlang.org/show_bug.cgi?id=24751 Dennis changed: What|Removed |Added Status|NEW |RESOLVED CC||dkor...@live.nl Resolution|--- |INVALID --
[Issue 24751] [std.container.binaryheap] example uses heapify but there is no documentation
https://issues.dlang.org/show_bug.cgi?id=24751 --- Comment #2 from ppadil...@gmail.com --- You are right - my bad. I'll blame it on not enough coffee. Feel free to delete, mark complete or whatever is the appropriate way to dispose of this report. Thank you. --
[Issue 24753] New: run.dlang.io throws exception for 'all dmd compilers' and -betterC argument
https://issues.dlang.org/show_bug.cgi?id=24753 Issue ID: 24753 Summary: run.dlang.io throws exception for 'all dmd compilers' and -betterC argument Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: n...@geany.org Empty file data gives: > rdmd playground.d std.conv.ConvException@/work/ldc-1.26.0/bin/../import/std/conv.d(2288): Can't parse string: bool should be case-insensitive 'true' or 'false' ??:? [0x491605] ??:? [0x493086] ??:? [0x4761df] ??:? [0x40992c] ??:? [0x40968c] ??:? [0x40965c] ??:? [0x429e6a] ??:? [0x42957b] ??:? [0x41bca2] ??:? [0x419ebb] ??:? [0x475ecb] ??:? [0x475dc7] ??:? [0x475c1d] ??:? [0x420264] ??:? __libc_start_main [0x7fd3a94d383f] ??:? [0x4043b8] --
[Issue 24752] betterC memset link errors with template+array
https://issues.dlang.org/show_bug.cgi?id=24752 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- Works for me with DMD64 D Compiler v2.109.0 on Linux Mint. --
[Issue 24751] [std.container.binaryheap] example uses heapify but there is no documentation
https://issues.dlang.org/show_bug.cgi?id=24751 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- The ddoc page does list it: https://dlang.org/phobos/std_container_binaryheap.html ddox lists it here: https://dlang.org/library-prerelease/std/container/binaryheap.html This sub-page doesn't (but that's the intended design of ddox): https://dlang.org/library-prerelease/std/container/binaryheap/binary_heap.html --
[Issue 24752] New: betterC memset link errors with template+array
https://issues.dlang.org/show_bug.cgi?id=24752
Issue ID: 24752
Summary: betterC memset link errors with template+array
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b...@i64.mooo.com
Possibly related to other array `memset` errors already reported before. The
following code fails to link with `dmd` but works fine with `ldc2` on:
- Void Linux
- DMD64 D Compiler v2.101.1
- Args: `-betterC`
```
void fn(T, int N)(const T[N] arr) {
}
extern (C) void main() {
fn([1, 2]);
fn([1, 2, 3]);
fn([1, 2, 2]);
// same size array with different values fails
}
```
source/bug.d:(.text.main[main]+0x60): undefined reference to `_memset32'
--
[Issue 24750] escaping sliced stack arrays not detected
https://issues.dlang.org/show_bug.cgi?id=24750 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #3 from Nick Treleaven --- > compiles without complaint. > The error is detected if -dip1000 is used and the function is marked @safe. With dmd v2.109.0 (and recent git master) I get: os/retslice.d(7): Error: scope variable `slice` may not be returned --
[Issue 24749] A clause consisting only of "throw" should be the unlikely path
https://issues.dlang.org/show_bug.cgi?id=24749 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright updated dlang/dmd pull request #16831 "fix Issue 24749 throw block moved to end of function" fixing this issue: - fix Bugzilla Issue 24749 throw block moved to end of function https://github.com/dlang/dmd/pull/16831 --
[Issue 24750] escaping sliced stack arrays not detected
https://issues.dlang.org/show_bug.cgi?id=24750
Jonathan M Davis changed:
What|Removed |Added
CC||issues.dl...@jmdavisprog.co
||m
--- Comment #2 from Jonathan M Davis ---
Well, I wouldn't expect an error in those examples, because foo isn't marked as
@safe (though if the compiler is able to see that it's definitively a bug, I
see no problem with it giving an error even with @system code).
More generally, what should be happening though is that slicing a static array
should give the same kind of error that taking the address of a local variable
does (and in the same circumstances). So,
---
void foo() @safe
{
int[3] arr;
auto slice = arr[];
}
---
should give an error similar to
---
void foo() @safe
{
int i;
auto ptr = &i;
}
---
which gives
---
test.d(8): Error: cannot take address of local `i` in `@safe` function `foo`
---
If the compiler is able to detect that the usage is actually memory-safe (like
it can with DIP 1000), then it makes sense for it to not give an error, but in
any case where it isn't smart enough to know for sure, it should give an error
in @safe code (since otherwise, it can't actually guarantee that the code is
memory-safe), and the situations where it's going to be able to do that should
be identical between taking the address of a local variable and slicing a
static array, because it's ultimately the same operation, just with a different
type.
And at this point, without DIP 1000, I would expect an error in any case where
you take the address of a local variable in @safe code (since without DIP 1000,
the compiler can't currently detect that no escaping occurs), so IMHO, we
should be doing the same with any code that slices a static array (be it
explicitly or implicitly), and until we do, it's a hole in @safe - though of
course, any such change would require a deprecation period if we don't want to
immediately break existing code.
--
[Issue 24751] New: [std.container.binaryheap] example uses heapify but there is no documentation
https://issues.dlang.org/show_bug.cgi?id=24751 Issue ID: 24751 Summary: [std.container.binaryheap] example uses heapify but there is no documentation Product: D Version: D2 Hardware: All URL: http://dlang.org/phobos/ OS: All Status: NEW Severity: enhancement Priority: P3 Component: phobos Assignee: nob...@puremagic.com Reporter: ppadil...@gmail.com The std doc page for [std.container.binaryheap] example uses a routine named "heapify" but there is no documentation about it in the page with the rest of the functions. Users have to look at the source to figure out where this function came from. --
[Issue 24750] escaping sliced stack arrays not detected
https://issues.dlang.org/show_bug.cgi?id=24750 --- Comment #1 from Walter Bright --- The error is detected if -dip1000 is used and the function is marked @safe. --
[Issue 24750] escaping sliced stack arrays not detected
https://issues.dlang.org/show_bug.cgi?id=24750 Walter Bright changed: What|Removed |Added Keywords||safe --
[Issue 24750] New: escaping sliced stack arrays not detected
https://issues.dlang.org/show_bug.cgi?id=24750
Issue ID: 24750
Summary: escaping sliced stack arrays not detected
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
Jonathan Davis reports:
int[] foo()
{
int[3] arr = [1,2,3];
return arr[]; // returning `arr[]` escapes a reference to local variable
`arr`
}
whereas:
int[] foo()
{
int[3] arr = [1,2,3];
int[] slice = arr[];
return slice;
}
compiles without complaint.
--
[Issue 24749] New: A clause consisting only of "throw" should be the unlikely path
https://issues.dlang.org/show_bug.cgi?id=24749
Issue ID: 24749
Summary: A clause consisting only of "throw" should be the
unlikely path
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
As suggested by Quirin Schroll.
int foo(int i)
{
if (i)
throw new Exception("hello");
return i;
}
should emit code this way:
int foo(int i)
{
if (!i)
return i;
throw new Exception("hello");
}
so the return statement is considered the most likely code execution path.
--
[Issue 24748] New: DMD can't output object files with fully qualified name, making -od overwirte each other file
https://issues.dlang.org/show_bug.cgi?id=24748 Issue ID: 24748 Summary: DMD can't output object files with fully qualified name, making -od overwirte each other file Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: msnmanc...@hotmail.com I need a fully qualified name, so, dmd object dir output doesn't overwrite each other. I'm working on a build tool optimization and now it is blocked while that unless - Use -op - Filter each of those object generated files - Rename and move them to object directory LDC has already solved that with the -oq flag Related issues: https://issues.dlang.org/show_bug.cgi?id=4095 https://issues.dlang.org/show_bug.cgi?id=3541 --
[Issue 24747] Offer compiler configuration information
https://issues.dlang.org/show_bug.cgi?id=24747 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added Priority|P1 |P5 --
