www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Synchronize D 2.101.0 release with tooling please

reply ryuukk_ <ryuukk.dev gmail.com> writes:
Please think about tooling before doing the release

As usual tooling was completely ignored

DUB merged stable without ImportC support.. [1]

- DUB: needs ImportC support PR: [2]

- DCD: needs to pick up bitfield support from recent libdparse PR 
[3]


So we can ensure users will have a great experience


[1] - https://github.com/dlang/dub/pull/2529

[2] - https://github.com/dlang/dub/pull/2522

[3] - https://github.com/dlang-community/libdparse/pull/476
Nov 14 2022
next sibling parent reply bauss <jacobbauss gmail.com> writes:
On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release

 As usual tooling was completely ignored

 DUB merged stable without ImportC support.. [1]

 - DUB: needs ImportC support PR: [2]

 - DCD: needs to pick up bitfield support from recent libdparse 
 PR [3]


 So we can ensure users will have a great experience


 [1] - https://github.com/dlang/dub/pull/2529

 [2] - https://github.com/dlang/dub/pull/2522

 [3] - https://github.com/dlang-community/libdparse/pull/476
I agree. No release should happen unless tooling is up to pair with the release.
Nov 14 2022
parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Tuesday, 15 November 2022 at 07:06:24 UTC, bauss wrote:
 On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release
I agree. No release should happen unless tooling is up to pair with the release.
Could you list the tools that should have synchronized releases?
Nov 15 2022
parent bauss <jacobbauss gmail.com> writes:
On Tuesday, 15 November 2022 at 09:10:54 UTC, Andrey Zherikov 
wrote:
 On Tuesday, 15 November 2022 at 07:06:24 UTC, bauss wrote:
 On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release
I agree. No release should happen unless tooling is up to pair with the release.
Could you list the tools that should have synchronized releases?
I would say the most important one would be dub.
Nov 15 2022
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release

 As usual tooling was completely ignored

 DUB merged stable without ImportC support.. [1]

 - DUB: needs ImportC support PR: [2]

 - DCD: needs to pick up bitfield support from recent libdparse 
 PR [3]


 So we can ensure users will have a great experience


 [1] - https://github.com/dlang/dub/pull/2529

 [2] - https://github.com/dlang/dub/pull/2522

 [3] - https://github.com/dlang-community/libdparse/pull/476
New D version released, and this post got ignored, as expected I guess folks have different priorities, that's unfortunate
Nov 15 2022
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 16 November 2022 at 03:34:15 UTC, ryuukk_ wrote:

 New D version released, and this post got ignored, as expected
No, it wasn't ignored. I think coordinating tooling with dmd releases is a good idea and plan to bring it to our next monthly meeting. There's just no way it could happen with this release through. The release process was already well underway when you posted this, and Iain Buclaw is managing it for the first time. It was a bit late and a bit much to throw on him at the last minute. I'm highly confident I'll find general agreement on this in the meeting. Then it will just be a matter of identifying all of the tooling projects we need to keep in sync, who to coordinate with to make it happen, how to make it happen, etc. I see this as the sort of thing that would fall under the purview of the ecosystem management team once we get the ball rolling there.
Nov 15 2022
parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Wednesday, 16 November 2022 at 04:44:42 UTC, Mike Parker wrote:
 On Wednesday, 16 November 2022 at 03:34:15 UTC, ryuukk_ wrote:

 New D version released, and this post got ignored, as expected
No, it wasn't ignored. I think coordinating tooling with dmd releases is a good idea and plan to bring it to our next monthly meeting. There's just no way it could happen with this release through. The release process was already well underway when you posted this, and Iain Buclaw is managing it for the first time. It was a bit late and a bit much to throw on him at the last minute. I'm highly confident I'll find general agreement on this in the meeting. Then it will just be a matter of identifying all of the tooling projects we need to keep in sync, who to coordinate with to make it happen, how to make it happen, etc. I see this as the sort of thing that would fall under the purview of the ecosystem management team once we get the ball rolling there.
I believe we should "synchronize" compiler release with essential packages (like vibe, mir, arsd-official etc) as well. I mean we should ensure that these packages won't break after compiler release. This together with tooling will shape D managed ecosystem which I believe everyone will benefit from.
Nov 15 2022
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/11/2022 7:24 PM, Andrey Zherikov wrote:
 I believe we should "synchronize" compiler release with essential 
 packages (like vibe, mir, arsd-official etc) as well. I mean we should 
 ensure that these packages won't break after compiler release.
They won't. arsd is about the only project there that isn't tested on PR. Adam is fairly conservative with a very large range of version support, so I'm fairly sure that is likely to not break. https://buildkite.com/dlang/phobos/builds/7538
Nov 15 2022
next sibling parent Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Wednesday, 16 November 2022 at 06:38:35 UTC, rikki cattermole 
wrote:
 On 16/11/2022 7:24 PM, Andrey Zherikov wrote:
 I believe we should "synchronize" compiler release with 
 essential packages (like vibe, mir, arsd-official etc) as 
 well. I mean we should ensure that these packages won't break 
 after compiler release.
They won't. arsd is about the only project there that isn't tested on PR. Adam is fairly conservative with a very large range of version support, so I'm fairly sure that is likely to not break. https://buildkite.com/dlang/phobos/builds/7538
I didn't see it. Glad we have this already.
Nov 15 2022
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 16 November 2022 at 06:38:35 UTC, rikki cattermole 
wrote:
 arsd is about the only project there that isn't tested on PR.

 Adam is fairly conservative with a very large range of version 
 support, so I'm fairly sure that is likely to not break.
New dmds do sometimes break my stuff though. This most recent one did due to a (random, unjustifed) Phobos change, but one of my users who used the beta dmd sent me an email, so I got a fix landed ahead of the formal release. I have processes to test my stuff on old compilers, but not new ones. I rarely update stuff on my computers... so there is the risk that some dmd/phobos breakage will hit me. But I can usually fix it pretty quick without regressing support for old compilers if someone lets me know.
Nov 16 2022
parent reply bauss <jacobbauss gmail.com> writes:
On Wednesday, 16 November 2022 at 12:27:27 UTC, Adam D Ruppe 
wrote:
 ... (random, unjustifed) Phobos change ...
If you don't mind me asking, what was the change?
Nov 16 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 16 November 2022 at 14:30:14 UTC, bauss wrote:
 If you don't mind me asking, what was the change?
Socket.close is now `scope` on `this`. It isn't necessarily bad, like close prolly is scope anyway, but it is it worth the breakage to user code? I don't see the benefit.
Nov 16 2022
parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 16 November 2022 at 14:56:29 UTC, Adam D Ruppe 
wrote:
 I don't see the benefit.
The reason this was done is because for memory safety, class destructors shouldn't escape `this` in the constructor, so a PR was made to make class destructors implicitly `scope`. https://issues.dlang.org/show_bug.cgi?id=22680 https://github.com/dlang/dmd/pull/14402 Since std.socket calls `close` in the destructor of a socket, `close` had to be marked `scope` as well.
Nov 16 2022
parent Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 16 November 2022 at 15:39:18 UTC, Dennis wrote:
 class destructors shouldn't escape `this` in the constructor,
 so a PR was made to make class destructors implicitly `scope`.
The current implementation of class dtors is broken anyway; it doesn't even correctly implement the D spec! (The spec claims they are "always virtual", but they are actually never virtual, but the implementation tries to emulate it) and the statement that "The destructor for the super class automatically gets called when the destructor ends." is again only half-true, this does happen when you call rtFinalize, but it is not done in general when you call the dtor through other means. This has profound consequences with ` safe` and other static attributes - they just plain don't work! You can't call `.destroy()` in a safe (or nogc, etc.) contexts because destroy has no way of proving the destructor actually follows those rules at all. If it followed the spec, you could prove it, just like with any other virtual method, because subclasses would be forced to follow the rules. But it would be fairly strict: ``` class A { void dispose() safe {} } class B : A { override void dispose() system // compile error, cannot override safe with system // btw since attributes are inherited when overriding, you // don't actually have to write out ` safe` override void dispose() safe { super.dispose(); // all good! } // but can you tighten? override void dispose() safe nogc { // signature OK, you can tighten restrictions, but... // the spec says it must call the parent... super.dispose(); // uh oh, nogc this cannot call non- nogc super } } void destroy(T)(T t) { t.dispose(); } A a; destroy(a); // infers to safe because A.dispose B b; destroy(b); // the best this can do is also be safe because B.dispose must be able to call A.dispose // even if you made destroy call this.dtor(); then this.super.dtor(); in a loop, like rt_finalize does today, it could still at best infer to whatever the top-most class that defines the dtor actually specified ``` That "problem" with the mandatory call to `super.x()`... in effect, a destructor would not be allowed to tighten conditions. It'd have to exactly match the parent class' interface, attributes and all. I use the quotes on "problem" because that's not necessarily a problem! It'd work just fine, just you can't tighten things like you normally do in a subclass, since the parent chain is also required to be called. But the current implementation we have doesn't actually treat destructors as virtual. It just pretends they are when it is called. The fix we need is for the compiler to treat them that way too, and force all child classes to inherit the attributes from the parent class. Once you do that, you actually CAN meaningfully make a ` safe` destructor. But until then, all destructors are necessarily called from a ` system` context regardless; safe dtors just plain don't work, even if you try to .destroy() it explicitly in your ` safe` scope, because the static type system cannot prove that a dtor in a child type, only dynamically known, didn't do something ` system`. So, since ` safe` dtors are currently broken anyway, what do we gain by this change? I'd note that typing this post took about 50x the effort than fixing the code; this specific change is annoying but not terribly problematic. Just I wish breaking changes came with real world usability fixes rather than just patching one specific scenario while leaving the rest of the design as-is. I'd rather have to do a batched bigger fix for a bigger gain than a sequence of small fixes. BTW, I'd be surprised if either of those bugzilla things happened in the real world, since it'd most likely immediately crash if you did anyway. (Which is true of a lot of random things you do in finalizers. They are quite tricky in what you can actually do in them - obviously, no GC operations since it'd deadlock, it is fairly well known you can't access GC'd members since they might already be collected, but did you know even manually managed members might be problematic? Since a finalizer is called from an arbitrary thread, of the manually managed member refers at all to a thread-local piece of data, you're back in crash city. Notably, many Win32 gui handles are thread local, so don't try to clean them up in a finalizier either. And there's no attribute to help with that. Except maybe pure which is overkill lol)
 Since std.socket calls `close` in the destructor of a socket, 
 `close` had to be marked `scope` as well.
This btw is also a bit iffy; I wish Socket had a method to release its file descriptor so it wouldn't try to close it anymore. That'd be a fairly easy additive change though, maybe I'll PR it myself now that I'm thinking about it.
Nov 16 2022
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 16 November 2022 at 03:34:15 UTC, ryuukk_ wrote:
 On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release

 As usual tooling was completely ignored

 DUB merged stable without ImportC support.. [1]

 - DUB: needs ImportC support PR: [2]

 - DCD: needs to pick up bitfield support from recent libdparse 
 PR [3]


 So we can ensure users will have a great experience


 [1] - https://github.com/dlang/dub/pull/2529

 [2] - https://github.com/dlang/dub/pull/2522

 [3] - https://github.com/dlang-community/libdparse/pull/476
New D version released, and this post got ignored, as expected I guess folks have different priorities, that's unfortunate
Unfortunately the release was already tagged, built, signed, and uploaded to S3/FTP servers by 19:01 UTC on 14th November. You posted your first message 4 hours later at 22:43 UTC.
Nov 16 2022
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 16 November 2022 at 19:09:03 UTC, Iain Buclaw wrote:
 On Wednesday, 16 November 2022 at 03:34:15 UTC, ryuukk_ wrote:
 On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release

 As usual tooling was completely ignored

 DUB merged stable without ImportC support.. [1]

 - DUB: needs ImportC support PR: [2]

 - DCD: needs to pick up bitfield support from recent 
 libdparse PR [3]


 So we can ensure users will have a great experience


 [1] - https://github.com/dlang/dub/pull/2529

 [2] - https://github.com/dlang/dub/pull/2522

 [3] - https://github.com/dlang-community/libdparse/pull/476
New D version released, and this post got ignored, as expected I guess folks have different priorities, that's unfortunate
Unfortunately the release was already tagged, built, signed, and uploaded to S3/FTP servers by 19:01 UTC on 14th November. You posted your first message 4 hours later at 22:43 UTC.
I warned about bitfield back in July https://github.com/dlang-community/libdparse/issues/464 I sent a PR for .c files in DUB back in August https://github.com/dlang/dub/pull/2270
Nov 16 2022
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release

 As usual tooling was completely ignored

 DUB merged stable without ImportC support.. [1]
I think - _I think_ - that you have misunderstood what "merge stable" PRs are used for. The feedback I've been getting from the dub maintainers is that there have been so many things going on in dub already, they wanted to release now before moving forward with the next round of overhauling changes.
 - DUB: needs ImportC support PR: [2]
The release freeze occurred on 11th October. That PR was not raised until 30th October (and is still a draft). It has been _6 months_ since the last DMD release.
 - DCD: needs to pick up bitfield support from recent libdparse 
 PR [3]
Bit-field support is available only as a preview feature. There's plenty of time for downstream tooling to add support for it before it gets properly accepted into the language.
Nov 16 2022
parent Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 16 November 2022 at 18:57:54 UTC, Iain Buclaw wrote:
 before [bitfields] gets properly accepted into the language.
...which they hopefully never will. Such a godawful design, this would be another miss for D that Walter will regret later.
Nov 16 2022
prev sibling parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release

 As usual tooling was completely ignored

 DUB merged stable without ImportC support.. [1]

 - DUB: needs ImportC support PR: [2]

 - DCD: needs to pick up bitfield support from recent libdparse 
 PR [3]


 So we can ensure users will have a great experience


 [1] - https://github.com/dlang/dub/pull/2529

 [2] - https://github.com/dlang/dub/pull/2522

 [3] - https://github.com/dlang-community/libdparse/pull/476
Should we block a release for a WIP dub feature? The release was badly needed. On the subject of tooling I'd like to have a tree-sitter grammar in the compiler tree that we guarantee is up to date.
Nov 16 2022
parent M.M. <matus email.cz> writes:
On Wednesday, 16 November 2022 at 23:15:01 UTC, max haughton 
wrote:
 On Monday, 14 November 2022 at 22:43:57 UTC, ryuukk_ wrote:
 Please think about tooling before doing the release

 As usual tooling was completely ignored

 DUB merged stable without ImportC support.. [1]

 - DUB: needs ImportC support PR: [2]

 - DCD: needs to pick up bitfield support from recent libdparse 
 PR [3]


 So we can ensure users will have a great experience


 [1] - https://github.com/dlang/dub/pull/2529

 [2] - https://github.com/dlang/dub/pull/2522

 [3] - https://github.com/dlang-community/libdparse/pull/476
Should we block a release for a WIP dub feature? The release was badly needed. On the subject of tooling I'd like to have a tree-sitter grammar in the compiler tree that we guarantee is up to date.
Yeah, I also think that having a tree-sitter grammar would be greatly welcome (and contributing substantially to the "better tooling" quest). I think that the ultimate approach of Vladimir Panteleev would be a really great and sustainable solution.
Nov 16 2022