[Issue 20508] std.math.pow(-infinity, y) does not return NaN for imaginary or complex results
https://issues.dlang.org/show_bug.cgi?id=20508 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/phobos pull request #7747 "Fix Issue 20508 - std.math.pow(-infinity, y) does not return NaN for imaginary or complex results" was merged into master: - 7cc7d4d01a6f801ada095f553c151f0f49bc by Bernhard Seckinger: Fix Issue 20508 - std.math.pow(-infinity, y) does not return NaN for imaginary or complex results https://github.com/dlang/phobos/pull/7747 --
[Issue 18026] Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen()
https://issues.dlang.org/show_bug.cgi?id=18026 Boris Carvajal changed: What|Removed |Added CC||boris...@gmail.com --
[Issue 21570] __traits(isStaticArray, ...) accepts enums with static array as base type
https://issues.dlang.org/show_bug.cgi?id=21570 --- Comment #2 from Dlang Bot --- dlang/phobos pull request #7760 "Make isAutoDecodableString independent of issue 21570" was merged into master: - 7c13ddf8de6bbaf287a60ebac7e3f31acf45ecec by MoonlightSentinel: Make isAutoDecodableString independent of issue 21570 The current implementation relies on issue 21570 to reject enums with static arrays as their base type. Use another is-expression instead of `isStaticArray` to detect types that are (convertible to) static arrays. See https://issues.dlang.org/show_bug.cgi?id=21570 https://github.com/dlang/phobos/pull/7760 --
[Issue 21376] [x86-only] Returning 32-bit floats have wrong precision
https://issues.dlang.org/show_bug.cgi?id=21376 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @ibuclaw updated dlang/dmd pull request #12073 "fix Issue 21515 extern(C) and extern(C++) returns creal in wrong order" fixing this issue: - fix Issue 21376 - Returning 32-bit floats have wrong precision on i386 https://github.com/dlang/dmd/pull/12073 --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565
--- Comment #15 from Steven Schveighoffer ---
(In reply to Paul Backus from comment #14)
> (In reply to Steven Schveighoffer from comment #12)
> >
> > On the grounds that it's not desirable. It does not cause undefined
> > behavior, just useless behavior. We are better off disallowing it.
>
> "I don't like it" is not a technical argument, and should have no place in a
> technical discussion.
That's not my argument.
> > What does this mean? All individual values are safe according to D.
>
> If you really believe this, then you do not understand D's memory-safety
> system well enough to contribute usefully to this discussion, and I am
> wasting both my time and yours by continuing to respond.
Basic types and pointers are all accessible using @safe. I can access int, int
* perfectly fine in @safe code. It's the aliasing of the two that is a problem.
Frankly I think you are misinterpreting what I'm saying, or I am doing the same
for you. Wasting time might definitely be what you are doing.
>
> > It's not about being @safe or not. That's why I said the rules are sound.
> > It's just that the rules leave us with the reality that using such unions
> > usable in @safe or @trusted code has no utility.
>
> If it's "not about being @safe or not", then what on Earth *is* it about?
The whole point of @safe is to avoid code review. Otherwise it's a glamorized
linter. If you have to review @safe code to make sure things outside the safe
code are actually memory safe, then you have lost the battle.
Imagine that D does not have builtin slices (and get rid of the rules safe
defines around them). Then you need a structure to pass slices into a @trusted
function:
struct Array(T)
{
T* ptr;
size_T length;
}
A @trusted function that accepts this type has 2 options:
1. it can't do ANYTHING with the data beyond the one value pointed at by ptr,
because @safe code is allowed to set length to anything it wants.
2. It can use the data beyond the first element, but then you have to review
all @safe functions that call it.
It's the fact that the compiler disallows mutable access to length that we can
reason about what this semantically means as a parameter to a @trusted
function. Therefore, I don't have to review any array-using safe code for
memory safety because I know that the semantic invariant is held by the
compiler.
Likewise, a union of an int and an int * semantically MUST mean int today in
safe code AND TRUSTED CODE. If you access the int * after any safe code has run
with it, it must be considered memory unsafe.
So for instance:
struct S
{
union X {
int x;
int *y;
}
X val;
@safe {
void a();
void b();
void c();
void d();
}
@trusted void e() { /* use val.y */ }
}
How do you review that the usage of val.y is safe? the answer is: you review a,
b, c, d, in addition to e. Now you are reviewing safe code to make sure it's
safe in the context of val. This is useless. val might as well be an int, or a,
b, c, d might as well be marked trusted. So the logical conclusion is, e cannot
use val.y. And if it cannot use it, then what's the point of having it?
If we know that a, b, c, and d can never set the value of val.x or val.y, then
we don't have to review them at all. Now we are only reviewing e, which is the
intent of D's safety system.
I'm not arguing that the current implementation is unsafe, just that the
current semantic guarantees make using such unions pointless in the context of
safe/trusted code. The point of a union is to use all the members in it. If
there is one member that cannot be used, then it shouldn't be part of the
union.
> Personally, I think @safe should allow all code that the compiler can prove
> is memory-safe, regardless of whether you, I, or anyone else thinks it "has
> utility" or not.
The @safe rules provide a framework for proof of memory safety where we can
avoid reviewing whole sections of code. The compiler isn't proving safety, it's
just enforcing rules. We create the rules to make sure memory safety cannot be
violated even without a careful review of certain functions AND that
@safe/@trusted code is reasonable to write with those rules.
For example, let's say we changed the @safe rules to say only arrays and
references are allowed to be dereferenced in @safe code, never pointers. Now,
safe code can read and write pointers, even write arbitrary values. That's
perfectly safe. And perfectly useless. Isn't that just asking to make trusted
code even less safe? How does one use @trusted code with a pointer when you can
never know if the safe code that passed it to you has just set arbitrary
values? What do we gain as a language by allowing setting pointers up as
garbage in @safe code?
Such a rule would mean, pointers are safe to use in @trusted functions as long
as you don't use them as pointers, only as bits. This is the same rule we are
talking about. I don't see why the rule is desirable, an
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Dlang Bot --- dlang/dmd pull request #12143 "Fix 21569: Set RES path relative to build.d's directory" was merged into stable: - ca4dde78dd4777bc70b5ffce5eb6bf3b62355f23 by MoonlightSentinel: Fix 21569: Set RES path relative to build.d's directory This ensures the resulting path is correct even for the sources distributed alongside the official releases. This is a regression introduced by #11269. https://github.com/dlang/dmd/pull/12143 --
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569 --- Comment #8 from moonlightsenti...@disroot.org --- I am not very familiar with these makefiles. You can also building from the git repositorys or try LDC's `--link-defaultlib-debug` flag instead. --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #14 from Paul Backus --- (In reply to Steven Schveighoffer from comment #12) > > On the grounds that it's not desirable. It does not cause undefined > behavior, just useless behavior. We are better off disallowing it. "I don't like it" is not a technical argument, and should have no place in a technical discussion. > What does this mean? All individual values are safe according to D. If you really believe this, then you do not understand D's memory-safety system well enough to contribute usefully to this discussion, and I am wasting both my time and yours by continuing to respond. > It's not about being @safe or not. That's why I said the rules are sound. > It's just that the rules leave us with the reality that using such unions > usable in @safe or @trusted code has no utility. If it's "not about being @safe or not", then what on Earth *is* it about? Personally, I think @safe should allow all code that the compiler can prove is memory-safe, regardless of whether you, I, or anyone else thinks it "has utility" or not. I am rather surprised that this is a controversial point of view. --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #13 from Steven Schveighoffer --- (In reply to Steven Schveighoffer from comment #12) > It's just that the rules leave us with the reality that using such unions > usable in @safe or @trusted code has no utility. I rewrote this several times, and it looks terrible. I mean: It's just that the rules leave us with the reality that such unions in @safe or @trusted code have no utility. --
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569 --- Comment #7 from apham --- (In reply to moonlightsentinel from comment #5) > Sorry for the confusion, didn't realise you were building the sources > included in the official release instead of the git repository. > > Submitted a fix for your problem. Thanks you for quick fix!!! I sorry to bundle with this bug report Can you also try to rebuild using make (32 bit) for druntime & phobos. I got the long list of errors when doing the rebuild for those two The reason that I need to rebuild so I can try to figure out how to get the callstack for below error while doing unittest my projects. core.exception.InvalidMemoryOperationError@src\core\exception.d(647): Invalid memory operation src\core\exception.d(647): [unittest] Invalid memory operation --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #12 from Steven Schveighoffer --- (In reply to Paul Backus from comment #11) > > Read-only access is fine. Write access is not. > > Again, on what grounds do you make this claim? Can writing to the integer > member cause undefined behavior in @safe-only code? If so, please provide an > example. On the grounds that it's not desirable. It does not cause undefined behavior, just useless behavior. We are better off disallowing it. > What I have in mind is to change the definition of "unsafe value" for unions > to the following: > > > A struct/union instance is safe when: > > > > * the values of its accessible fields are safe, and What does this mean? All individual values are safe according to D. > > * it does not introduce unsafe aliasing with unions that is accessible > > from @safe code. This is not very specific. > This change does not, as far as I can tell, introduce unsoundness into the > language. It does not allow undefined behavior to occur in @safe code. If > you believe I am mistaken about this, please correct me. It's not about being @safe or not. That's why I said the rules are sound. It's just that the rules leave us with the reality that using such unions usable in @safe or @trusted code has no utility. > The reason I call this "sensical" is that *unnecessarily* excluding values > from the definition of "safe value" makes the language more difficult to use > without any benefit to soundness or memory-safety. More difficult than just using an integer instead of a union to represent an integer? > Ideally, we would like > @safe to impose on the programmer only those restrictions that are truly > necessary in order to avoid undefined behavior. There has to be consideration of what semantic meanings the application needs to be able to enforce. Disallowing @safe access to the scalars actually INCREASES the amount of code that is allowed to be marked @safe. That really should be the goal for @safe. Leaving the rules as-is just means such unions, when passed into @trusted code, must treat it the same as @safe code, and therefore they become simply integers. While that's sound, and not allowing undefined behavior, it means writing e.g. a tagged union that has any @safe code is impossible. It must all be @trusted or inferred w/ review. --
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569 Witold Baryluk changed: What|Removed |Added CC||witold.barylu...@gmail.com --- Comment #6 from Witold Baryluk --- Same happens on Linux. Same fix should work. Thank you! --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #11 from Paul Backus --- > Read-only access is fine. Write access is not. Again, on what grounds do you make this claim? Can writing to the integer member cause undefined behavior in @safe-only code? If so, please provide an example. > I just don't know what the definition of "sensical" means, based on your > prior messages. What rules do you have in mind? What I have in mind is to change the definition of "unsafe value" for unions to the following: > A struct/union instance is safe when: > > * the values of its accessible fields are safe, and > * it does not introduce unsafe aliasing with unions that is accessible > from @safe code. This change does not, as far as I can tell, introduce unsoundness into the language. It does not allow undefined behavior to occur in @safe code. If you believe I am mistaken about this, please correct me. The reason I call this "sensical" is that *unnecessarily* excluding values from the definition of "safe value" makes the language more difficult to use without any benefit to soundness or memory-safety. Ideally, we would like @safe to impose on the programmer only those restrictions that are truly necessary in order to avoid undefined behavior. --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #10 from Steven Schveighoffer --- (In reply to Paul Backus from comment #9) > > I'm disagreeing with the ability of safe code to access any part of this. > > On what grounds? The point of @safe is to prevent undefined behavior, and > allowing access to the integer cannot possibly lead to undefined behavior, > because all integer values are safe values. Read-only access is fine. Write access is not. > > > the current rules are sound, just nonsensical. It makes such unions > > pointless when writing safe code. > > I agree--which is why I would like to replace them with rules that are both > sound *and* sensical. Can we agree that that's a desirable goal? I can't say no to the agreement ;) I just don't know what the definition of "sensical" means, based on your prior messages. What rules do you have in mind? --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #9 from Paul Backus --- > I'm disagreeing with the ability of safe code to access any part of this. On what grounds? The point of @safe is to prevent undefined behavior, and allowing access to the integer cannot possibly lead to undefined behavior, because all integer values are safe values. > the current rules are sound, just nonsensical. It makes such unions pointless > when writing safe code. I agree--which is why I would like to replace them with rules that are both sound *and* sensical. Can we agree that that's a desirable goal? --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #8 from Steven Schveighoffer --- (In reply to RazvanN from comment #5) > (In reply to Steven Schveighoffer from comment #3) > > If you do intend to access the int *, then having any safe code anywhere > > just change the integer ruins the any safety assumptions that the @trusted > > or @system code can make. Essentially, it means @trusted code can never > > access such a union reliably except to access just the integer. > > Trusted does not offer any guarantees. This is why I said "assumptions" and not "guarantees". It's in fact impossible for a trusted function to guarantee the union state between calls, because safe code can do anything it wants with the union so long as there is a mutable basic type involved. > You can do whatever you want there. > If you want to access a pointer that is overlapped with an integer that is > the users' problem not the typesystems'. You cannot assume anything with > regards to that pointer, that is the reason why it is not allowed in @safe > code. In case you do use and you have a segfault, then the developer will > have > to audit the trusted blocks, not the @safe ones. Auditing is not possible. The trusted code cannot make any assumptions about the union, it must ALWAYS treat it as an integer (at least when it comes in). Inside the function, sure, it can assign things. But as soon as it leaves the function, it must be treated as an integer again. This means, such unions serve no purpose as parameters to trusted code. Ever. In which case, using such a union in safe code is pointless. It's more productive to follow the rules already set in the spec. > I think that this is an issue were reasonable people may disagree, but the > fact is that @safe is checked with regards to operations not data > structures. There is no concept of @safe union or @system union in D. It is > the way you use it that makes it @safe/@system. From this point of view, > setting an integer that is overlapped with a pointer is not unsafe, however > accessing a pointer that is overlapped with an integer is. This is a misunderstanding. @safe has everything to do with data structures, and the semantics surrounding those data structures. If we don't have data rules for @safe code, then @trusted code cannot make any reasonable assumptions about the incoming parameters. Remember that @trusted code MUST ASSUME it is being called from @safe code. For example, @safe ascribes a semantic meaning to the length field of an array. It means "all the items that are pointed to by the pointer that are up to that length are accessible." Without that, arrays of data could not be passed to a @trusted function. We also have rules for an incoming pointer, which means, it only can point at a single valid value, or null. Using these rules, one can write useful @trusted code. Without such rules, either trusted code would have to assume any incoming parameters are suspect, or we have to review all code including @safe code. With a rule of "Incoming union values can only ever have scalar values set" is unnecessarily limiting. If you can only set the scalar values, why have a union that is usable in safe code that has pointer and scalar values mixed? It's what makes the DIP1035 proposal so promising -- you can ascribe your own semantic rules to types that the compiler doesn't have built in. --
[Issue 21539] [REG 2.084] symbols from import inside template mixin cannot be accessed using module scope dot operator
https://issues.dlang.org/show_bug.cgi?id=21539 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #6 from Dlang Bot --- @BorisCarvajal created dlang/dmd pull request #12145 "Fix Issue 21539 - [REG 2.084] symbols from import inside template mix…" fixing this issue: - Fix Issue 21539 - [REG 2.084] symbols from import inside template mixin cannot be accessed using module scope dot operator https://github.com/dlang/dmd/pull/12145 --
[Issue 21567] build.d install fails, can't find dmd.conf
https://issues.dlang.org/show_bug.cgi?id=21567 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @MoonlightSentinel created dlang/dmd pull request #12144 "Fix 21567 - build.d install fails for sources from official releases" fixing this issue: - Fix 21567 - build.d install fails for sources from official releases The official releases only include the configuration of the current OS in the root directory instead off multiple configurations nested in the `ini` folder. This commit checks whether the `ini` directory exists and falls back to the expected path for releases otherwise. https://github.com/dlang/dmd/pull/12144 --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #7 from Steven Schveighoffer --- (In reply to Paul Backus from comment #4) > The *intent* of the spec is clearly to allow code like this to be marked as > @trusted. If the current wording of the spec does not allow that, then the > spec's wording does not match its intent, and the wording should be changed. I'm not disagreeing with the requirement that system/trusted code should be needed to access aliased values. I'm disagreeing with the ability of safe code to access any part of this. And the spec currently says that. Consider this function: void example(ref T t) @trusted; This function has to assume that t only is valid as an integer, never as a pointer. Because safe code can *only* access and/or mutate the integer. In that case, what's the point of the union? Even in your example, you simply ignore the parameter (it might as well not be there). Not only that, but even if it sets the pointer in t, it must be automatically assumed once the function ends that the pointer value is no longer valid (it went back into safe-land where the code can happily mutate anything it wants in t). The union becomes an unnecessarily complicated integer. the current rules are sound, just nonsensical. It makes such unions pointless when writing safe code. --
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569 --- Comment #5 from moonlightsenti...@disroot.org --- Sorry for the confusion, didn't realise you were building the sources included in the official release instead of the git repository. Submitted a fix for your problem. --
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #4 from Dlang Bot --- @MoonlightSentinel created dlang/dmd pull request #12143 "Fix 21569: Set RES path relative to build.d's directory" fixing this issue: - Fix 21569: Set RES path relative to build.d's directory This ensures the resulting path is correct even for the sources distributed alongside the official releases. This is a regression introduced by #11269. https://github.com/dlang/dmd/pull/12143 --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 --- Comment #6 from ag0aep6g --- (In reply to Paul Backus from comment #2) > The question is: should the value of `t` after `t.x = 5`, in comment 1's > example, be considered an unsafe value? [...] > If we amend the spec as follows: > > > A struct/union instance is safe when: > > > > * the values of its accessible fields are safe, and > > * it does not introduce unsafe aliasing with unions **that is accessible > > from @safe code**. > > ...then `t`'s value becomes safe, and we are allowed to use it in @safe and > @trusted code as long as we are careful not to let @safe code access `t.x` > and `t.y` at the same time. > > I think this interpretation is much more useful, and almost certainly the > intended one, so I suggest that this is really a bug in the spec, not the > implementation. > > [1] https://dlang.org/spec/function.html#safe-interfaces I can say that I did not intend that interpretation when I added "safe aliasing" to the spec. But I might have been overly conservative. Currently, the spec explicitly says that @safe code "Cannot access unions that have pointers or references overlapping with other types."[1] If that's so, then I guess it doesn't matter whether the union's aliasing is safe or not, because @safe code can't access it at all. And I guess it's still okay even if we change that to allow access to the non-pointy bits of the union, because the @safe code just sees another harmless int (or whatever). As far as I can tell, that means all possible union values can be considered safe (just like all ints are safe), and we can remove the parts about "[introducing] unsafe aliasing with unions" from the "save values" section. One must still be careful not to expose the unsafe aliasing to @safe code in other ways, but that's already covered by the spec. I wouldn't have designed it this way, but it seems to be what DMD is going for. [1] https://dlang.org/spec/function.html#safe-functions --
[Issue 21571] goto across assignment to AA fails and reports false Error
https://issues.dlang.org/show_bug.cgi?id=21571 Stefan changed: What|Removed |Added CC||kde...@vogtner.de --
[Issue 21571] New: goto across assignment to AA fails and reports false Error
https://issues.dlang.org/show_bug.cgi?id=21571
Issue ID: 21571
Summary: goto across assignment to AA fails and reports false
Error
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: kde...@vogtner.de
~~~gotoskip.d
int main ()
{
string[string] aa;
goto A; // line 4
aa["X"] = "Y";// line 5
A:
return 0;
}
~~~
$ dmd gotoskip.d
gotoskip.d(4): Error: goto skips declaration of variable gotoskip.main.__aaval2
at gotoskip.d(5)
As mentioned by Paul Backus [1] the compiler generates a temporary for
the assigned value:
// goto A;
(string __aaval2 = "Y";) , aa["X"] = __aaval2;
A:
[1]
http://forum.dlang.org/thread/zodxcypeddafyqruz...@forum.dlang.org#post-fplpglzhvxckvryubwsc:40forum.dlang.org
--
[Issue 21570] __traits(isStaticArray, ...) accepts enums with static array as base type
https://issues.dlang.org/show_bug.cgi?id=21570 --- Comment #1 from Dlang Bot --- @MoonlightSentinel created dlang/phobos pull request #7760 "Make isAutoDecodableString independent of issue 21570" mentioning this issue: - Make isAutoDecodableString independent of issue 21570 The current implementation relies on issue 21570 to reject enums with static arrays as their base type. Use another is-expression instead of `isStaticArray` to detect types that are (convertible to) static arrays. See https://issues.dlang.org/show_bug.cgi?id=21570 https://github.com/dlang/phobos/pull/7760 --
[Issue 20552] Deprecated Nullable.get warning with Appenders
https://issues.dlang.org/show_bug.cgi?id=20552 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #4 from Dlang Bot --- @RazvanN7 created dlang/phobos pull request #7759 "Fix Issue 20552 - Deprecated Nullable.get warning with Appenders" fixing this issue: - Fix Issue 20552 - Deprecated Nullable.get warning with Appenders https://github.com/dlang/phobos/pull/7759 --
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569
--- Comment #3 from apham ---
(In reply to moonlightsentinel from comment #1)
> Does your current environment contain a RES variable?
>
I see RES is set in build.d module as below
env.setDefault("RES", dmdRepo.buildPath("src/dmd/res"));
--
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569 --- Comment #2 from apham --- (In reply to moonlightsentinel from comment #1) > Does your current environment contain a RES variable? > > The include path (C:\Development\DLang\D\dmd2\src\src/dmd/res) is wrong and > points inside of your dmd installation AFAICT. No RES variable --
[Issue 21567] build.d install fails, can't find dmd.conf
https://issues.dlang.org/show_bug.cgi?id=21567 moonlightsenti...@disroot.org changed: What|Removed |Added CC||moonlightsentinel@disroot.o ||rg Hardware|x86_64 |All --- Comment #1 from moonlightsenti...@disroot.org --- This isn't strictly a build.d issue because it the old makefile implementation had the same problem. The real problem is that the tarball uses a different directory layout than the git project. The tarball includes only the configuration files for the current os: Git: - ini/ - linux/ - bin32/ - bin64/ - windows/ - ... Tarball: - linux/ - bin32/ - bin64/ --
[Issue 21569] Unable to rebuild DMD build using win32.mak - v2.095.0
https://issues.dlang.org/show_bug.cgi?id=21569 moonlightsenti...@disroot.org changed: What|Removed |Added CC||moonlightsentinel@disroot.o ||rg --- Comment #1 from moonlightsenti...@disroot.org --- Does your current environment contain a RES variable? The include path (C:\Development\DLang\D\dmd2\src\src/dmd/res) is wrong and points inside of your dmd installation AFAICT. --
[Issue 21570] New: __traits(isStaticArray, ...) accepts enums with static array as base type
https://issues.dlang.org/show_bug.cgi?id=21570
Issue ID: 21570
Summary: __traits(isStaticArray, ...) accepts enums with static
array as base type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: moonlightsenti...@disroot.org
Example:
-
enum EnumArray : int[2] {
a = [ 1, 2 ],
b = [ 3, 4 ]
}
static assert(!__traits(isStaticArray, EnumArray)); // Fails
// Expected equal behaviour of trait and is-expression
static assert(!is(EnumArray == T[n], T, size_t n)); // Passes
-
The spec[1] states that a named enum creates a distinct type which is
implicitly convertible to it's base type. So EnumArray is not a static array
and __traits(isStaticArray, EnumArray) should yield `false` as done for the
equivalent is-expression.
[1] https://dlang.org/spec/enum.html#named_enums
--
[Issue 20552] Deprecated Nullable.get warning with Appenders
https://issues.dlang.org/show_bug.cgi?id=20552 RazvanN changed: What|Removed |Added Component|dmd |phobos --
[Issue 20552] Deprecated Nullable.get warning with Appenders
https://issues.dlang.org/show_bug.cgi?id=20552 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #3 from RazvanN --- Compiling this with git HEAD yields: /home/razvan/dmd/phobos/std/traits.d(3727): Deprecation: function `std.typecons.Nullable!string.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. /home/razvan/dmd/druntime/import/core/internal/traits.d(233): instantiated from here: `F!(Nullable!string)` /home/razvan/dmd/phobos/std/meta.d(880):instantiated from here: `anySat!(hasElaborateAssign, Nullable!string)` /home/razvan/dmd/phobos/std/traits.d(3729):instantiated from here: `anySatisfy!(hasElaborateAssign, Nullable!string)` /home/razvan/dmd/druntime/import/core/internal/traits.d(233):... (5 instantiations, -v to show) ... /home/razvan/dmd/phobos/std/array.d(3468):instantiated from here: `emplaceRef!(StructWithNullable, StructWithNullable, StructWithNullable)` test.d(12):instantiated from here: `put!(StructWithNullable)` Note that the instantion point (test.d(12)) is present in the output, so this is a phobos issue, not a dmd one. Changing component to reflect that. --
[Issue 21544] -checkaction=context formats enum members as their base type
https://issues.dlang.org/show_bug.cgi?id=21544 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @MoonlightSentinel created dlang/druntime pull request #3336 "Fix 21544 - -checkaction=context formats enum members as their base type" fixing this issue: - Fix 21544 - -checkaction=context formats enum members as their base type Generate code that detects the correct enum member (or defaults to the base type in case of an invalid enum value). https://github.com/dlang/druntime/pull/3336 --
[Issue 18913] Cannot move static array of non-copyable type
https://issues.dlang.org/show_bug.cgi?id=18913 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 19616] Result type of ternary operator connecting pointers/slices of class handles broken
https://issues.dlang.org/show_bug.cgi?id=19616 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 21565] @safe code allows modification of a scalar that overlaps with a pointer
https://issues.dlang.org/show_bug.cgi?id=21565 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #5 from RazvanN --- (In reply to Steven Schveighoffer from comment #3) > A union between a pointer and integer is most definitely unsafe in all > instances. If you never intend to access the int*, in any circumstance, then > why have a union? It may be safe if the user sets the integer part with valid memory addresses. However, the compiler cannot know that. > If you do intend to access the int *, then having any safe code anywhere > just change the integer ruins the any safety assumptions that the @trusted > or @system code can make. Essentially, it means @trusted code can never > access such a union reliably except to access just the integer. Trusted does not offer any guarantees. You can do whatever you want there. If you want to access a pointer that is overlapped with an integer that is the users' problem not the typesystems'. You cannot assume anything with regards to that pointer, that is the reason why it is not allowed in @safe code. In case you do use and you have a segfault, then the developer will have to audit the trusted blocks, not the @safe ones. > This means that T is OK to use ONLY in @system code, or ONLY in @safe code, > but NEVER in @trusted code (unless you just follow the @safe rules). > > I don't feel like we should bend the spec over backwards to fit with the > implementation, when there isn't really a benefit (other than being able to > close a bug report). I think that this is an issue were reasonable people may disagree, but the fact is that @safe is checked with regards to operations not data structures. There is no concept of @safe union or @system union in D. It is the way you use it that makes it @safe/@system. From this point of view, setting an integer that is overlapped with a pointer is not unsafe, however accessing a pointer that is overlapped with an integer is. --
[Issue 19706] Attribute inference in struct fails
https://issues.dlang.org/show_bug.cgi?id=19706 Bolpat changed: What|Removed |Added Keywords||rejects-valid --
[Issue 21562] Allow mixin template declarations without parentheses
https://issues.dlang.org/show_bug.cgi?id=21562 --- Comment #2 from Bolpat --- Just a random thought. Laziness is the main driver. --
[Issue 2079] Phobos unit tests fail assertion on std/std/string.d
https://issues.dlang.org/show_bug.cgi?id=2079 --- Comment #4 from Dlang Bot --- dlang/dub pull request #2081 "Allow adding dflags on dependencies when using SDL format" was merged into stable: - cfd4fd801468a46cd599dda476c19bbd9f093237 by Ömer Faruk IRMAK: Allow adding dflags on dependencies when using SDL format Fixes #2079 https://github.com/dlang/dub/pull/2081 --
