Bug 16267 – Windows modules are missing key information

Status
NEW
Severity
trivial
Priority
P4
Component
druntime
Product
D
Version
D2
Platform
x86_64
OS
Windows
Creation time
2016-07-12T02:41:34Z
Last change time
2024-12-07T13:36:45Z
Assigned to
No Owner
Creator
TeddyBear12311
Moved to GitHub: dmd#17154 →

Comments

Comment #0 by TeddyBear12311 — 2016-07-12T02:41:34Z
1. Many windows modules are not marked @nogc, preventing them from being used in nogc code. This can be seen by doing an inverse search for nogc on the windows modules. There are many. Since these are bindings to C/win32, it's obvious they do not rely on the GC and should be marked so. This is probably the case for many bindings and not just the win32 ones. winreg.d and objbase.d are just a few. Should extern(Windows) always be marked nothrow @nogc automaticaly(search and replace the windows files)? 2. Many enumerations have no name(defined globally I guess) which prevents converting values to names. e.g., One can't do to!string(cast(???)val)) to convert error messages to their string equivalents. To get around this I'm duplicating the enum structures and naming them so I can fill in the ???. winerror.d is the main concern but all enums should be named so one can convert their values to their corresponding names. It would be better to be able to make allow a named enum to both be named and global. e.g., global enum NamedEnum { } Alternatively, maybe create a construct that allows one to get the enum containing the member. e.g., cast(GetEnum(S_OK))0 returns "S_OK". GetEnum returns the anonymous enum in some way(has an internal name).
Comment #1 by robert.schadek — 2024-12-07T13:36:45Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17154 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB