[Issue 4663] Wrong 'static' position error message
https://issues.dlang.org/show_bug.cgi?id=4663 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #15321 "Fix Issue 4663 - Wrong 'static' position error message" was merged into master: - 1265a403b505b9f0ad51e155a6de544030c26d4a by Nick Treleaven: Fix Issue 4663 - Wrong 'static' position error message Also detects `extern`, `deprecated`, `ref`, `override` and friends. https://github.com/dlang/dmd/pull/15321 --
[Issue 20812] _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
https://issues.dlang.org/show_bug.cgi?id=20812
Steven Schveighoffer changed:
What|Removed |Added
Keywords||safe, wrong-code
CC||schvei...@gmail.com
--- Comment #3 from Steven Schveighoffer ---
I further diagnosed this. You don't need to declare the shared aa separately,
this will do:
```d
void main() { shared aa = ["abc": "123"]; }
```
If you declare `aa` as const instead, the `ti` parameter passed to
`_d_assocarrayliteralTX` is a legit `TypeInfo_AssociativeArray`. However, when
you use shared, the `ti` parameter is pointing to the wrapping
`TypeInfo_Shared`.
Note that this is a *reinterpret cast*, not a dynamic cast, and so it really
thinks it's pointing at a `TypeInfo_AssociativeArray`. Therefore the `key`
field doesn't actually exists, and is garbage.
I'm not sure on LDC if this is a similar problem but it's possible since it's
reading invalid memory it happens to work? I tend to think not.
I ran on run.dlang.io for all compilers, and all segfault. So this has been
happening for a while.
const, immutable, and inout all do not have this problem, only shared.
I also confirmed this is a problem on gdc.
--
[Issue 23990] constant folding of integer casts not always happening in front end
https://issues.dlang.org/show_bug.cgi?id=23990 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #15322 "fix Issue 23990 - constant folding of integer casts not always happen…" fixing this issue: - fix Issue 23990 - constant folding of integer casts not always happening in front end https://github.com/dlang/dmd/pull/15322 --
[Issue 23990] New: constant folding of integer casts not always happening in front end
https://issues.dlang.org/show_bug.cgi?id=23990 Issue ID: 23990 Summary: constant folding of integer casts not always happening in front end Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com It gets deferred until conversion to the intermediate code, unless CTFE is also run. This causes: 1. some inconsistencies in the expressions after semantic analysis 2. some high level optimizations to be missed 3. constant folding passes to get unnecessarily re-run --
[Issue 20812] _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
https://issues.dlang.org/show_bug.cgi?id=20812 m...@ernestocastellotti.it changed: What|Removed |Added CC||m...@ernestocastellotti.it --- Comment #2 from m...@ernestocastellotti.it --- I investigate this bug and the problem is that ti.key (field of TypeInfo_AssociativeArray) is null. The sigsegv obviously occurs at this line https://github.com/dlang/dmd/blob/342a226833a0e9c7a90bbb64ae8dc35aa6d6bfdc/druntime/src/rt/aaA.d#L766 I'm trying to figure out what the reason for this would be and how to fix it. --
[Issue 10910] Duplicate error messages for array bounds errors
https://issues.dlang.org/show_bug.cgi?id=10910 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @WalterBright updated dlang/dmd pull request #15314 "fix https://issues.dlang.org/show_bug.cgi?id=10910; fixing this issue: - fix Issue 10910 - Duplicate error messages for array bounds errors https://github.com/dlang/dmd/pull/15314 --
[Issue 4663] Wrong 'static' position error message
https://issues.dlang.org/show_bug.cgi?id=4663 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @ntrel created dlang/dmd pull request #15321 "Fix Issue 4663 - Wrong 'static' position error message" fixing this issue: - Fix Issue 4663 - Wrong 'static' position error message Also detects `extern`, `deprecated`, `ref`, `override` and friends. https://github.com/dlang/dmd/pull/15321 --
[Issue 20812] _d_assocarrayliteralTX segfault assigning a shared associative array an AA literal
https://issues.dlang.org/show_bug.cgi?id=20812 mw changed: What|Removed |Added Priority|P2 |P1 CC||min...@gmail.com Severity|critical|blocker --- Comment #1 from mw --- Encountered this bug again today with DMD64 D Compiler v2.104.0 You can also try on the run.dlang.org link, the bug still there. Sigh, we have so many such basic bugs for more than 3 years now, with no fix. Does anyone know how to fix it? or any work-around? Thanks. --
[Issue 23989] Regression in rdmd when running an empty eval
https://issues.dlang.org/show_bug.cgi?id=23989 mhh changed: What|Removed |Added CC||maxha...@gmail.com --- Comment #3 from mhh --- --eval containing a comment is pretty niche. Not entirely sure how to work around the empty statement problem. I assume it's to force evaluation because of the cache or something like that? If so then you might as well just s/rdmd/dmd because you basically gain 0 from rdmd other than it being slower. rdmd does seem to have a test-suite though so we can add this to it. --
[Issue 23966] [REG2.102] Cannot use traits(getAttributes) with overloaded template
https://issues.dlang.org/show_bug.cgi?id=23966
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #2 from RazvanN ---
This is not a problem with the deprecation of __traits(getAttributes), but
rather a problem of traits(getOverloads). This was simply exposed by the
deprecation. If you use __traits(getLocation) instead of getAttributes, you
will get the same behavior (except that an error is issued, not a deprecation):
module test;
@("gigi")
void fun() {}
@("mimi")
void fun(int) {}
@("didi")
void fun()(int, ulong) {}
void main()
{
//pragma(msg, __traits(getAttributes, fun));
pragma(msg, __traits(getOverloads, test, "fun"));
static foreach (t; __traits(getOverloads, test, "fun"))
pragma(msg, __traits(getLocation, t));
}
--
[Issue 23966] [REG2.102] Cannot use traits(getAttributes) with overloaded template
https://issues.dlang.org/show_bug.cgi?id=23966
--- Comment #3 from RazvanN ---
(In reply to RazvanN from comment #2)
> This is not a problem with the deprecation of __traits(getAttributes), but
> rather a problem of traits(getOverloads). This was simply exposed by the
> deprecation. If you use __traits(getLocation) instead of getAttributes, you
> will get the same behavior (except that an error is issued, not a
> deprecation):
>
> module test;
>
> @("gigi")
> void fun() {}
> @("mimi")
> void fun(int) {}
> @("didi")
> void fun()(int, ulong) {}
>
> void main()
> {
> //pragma(msg, __traits(getAttributes, fun));
> pragma(msg, __traits(getOverloads, test, "fun"));
> static foreach (t; __traits(getOverloads, test, "fun"))
> pragma(msg, __traits(getLocation, t));
>
> }
Updated snippet, without comments and extra things:
module test;
@("gigi")
void fun() {}
@("mimi")
void fun(int) {}
@("didi")
void fun()(int, ulong) {}
void main()
{
static foreach (t; __traits(getOverloads, test, "fun"))
pragma(msg, __traits(getLocation, t));
}
--
[Issue 23989] Regression in rdmd when running an empty eval
https://issues.dlang.org/show_bug.cgi?id=23989
--- Comment #2 from deadalnix ---
Something used to work.
Now it doesn't work.
None of the input provided contains either a `{}` or a `;`, so clearly the the
user supplied code isn't at fault.
If rdmd generates something that is now invalid, then this is rdmd's problem.
It's 100% a regression.
--
[Issue 23989] Regression in rdmd when running an empty eval
https://issues.dlang.org/show_bug.cgi?id=23989 Richard Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #1 from Richard Cattermole --- Not a regression in rdmd. In dmd 2.104.0 empty statements with semicolons now error. https://dlang.org/changelog/2.104.0.html#dmd.empty-statement-error You do not need anything passed to the eval flag and it would not emit the semicolon. However in saying that, rdmd in innerEvalCode should be made smarter so that it checks if last character is either a semicolon or a close brace, rather than just a semicolon. That way loops can work. https://github.com/dlang/tools/blob/master/rdmd.d#L875 I suppose making it even smarter with comment detection ext. would be good too. --
[Issue 23989] New: Regression in rdmd when running an empty eval
https://issues.dlang.org/show_bug.cgi?id=23989
Issue ID: 23989
Summary: Regression in rdmd when running an empty eval
Product: D
Version: D2
Hardware: All
URL: http://dlang.org/
OS: All
Status: NEW
Severity: regression
Priority: P3
Component: tools
Assignee: nob...@puremagic.com
Reporter: deadal...@gmail.com
We run unit tests for modules in the following way:
rdmd -m64 -Isrc -w -debug -g -unittest -i --extra-file=src/d/object.d
--eval="/* Do nothing */"
With an extra-file per file. These command are generated automatically by the
build and this used to work great.
With the latest rdmd, we have the following error message:
/tmp/.rdmd-1001/eval.73D1BDC8D7573E2DF9EF23CD86830110.d(18): Error: use `{ }`
for an empty statement, not `;`
Failed: ["/usr/bin/dmd", "-m64", "-Isrc", "-w", "-debug", "-g", "-unittest",
"-i", "-d", "-v", "-o-",
"/tmp/.rdmd-1001/eval.73D1BDC8D7573E2DF9EF23CD86830110.d", "-I/tmp/.rdmd-1001"]
make: *** [src/libd.mak:33: check-libd-d] Error 1
This is because the generated file is as follow:
module temporary;
import std.stdio, std.algorithm, std.array, std.ascii, std.base64,
std.bigint, std.bitmanip,
std.compiler, std.complex, std.concurrency, std.container, std.conv,
std.csv,
std.datetime, std.demangle, std.digest.md, std.encoding, std.exception,
std.file,
std.format, std.functional, std.getopt, std.json,
std.math, std.mathspecial, std.mmfile,
std.numeric, std.outbuffer, std.parallelism, std.path, std.process,
std.random, std.range, std.regex, std.signals, std.socket,
std.stdint, std.stdio,
std.string, std.windows.syserror, std.system, std.traits, std.typecons,
std.typetuple, std.uni, std.uri, std.utf, std.variant, std.zip,
std.zlib;
void main(char[][] args) {
/* Do nothing */;
}
--
[Issue 23988] Conditional Exp does not bring enums to correct common type if one leg is const
https://issues.dlang.org/show_bug.cgi?id=23988 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #15316 "fix Issue 23988 - Conditional Exp does not bring enums to correct com…" was merged into master: - 8e9d9db58d97d1509d9fa0cf4a2f8b0f96f86747 by Walter Bright: fix Issue 23988 - Conditional Exp does not bring enums to correct common type if one leg is const https://github.com/dlang/dmd/pull/15316 --
[Issue 23973] static constructors should have to be nothrow
https://issues.dlang.org/show_bug.cgi?id=23973 --- Comment #3 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #15318 "Fic Issue 23973 - static constructors should have to be nothrow" mentioning this issue: - Fic Issue 23973 - static constructors should have to be nothrow https://github.com/dlang/dmd/pull/15318 --
[Issue 23959] [REG2.101.0] Copying arrays of types with postblits from varargs broken
https://issues.dlang.org/show_bug.cgi?id=23959
Dlang Bot changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Dlang Bot ---
dlang/dmd pull request #15295 "Move lowerings to
`_d_array{setassign,assign_{l,r}}` to a `LoweredAssignExp` AST node" was merged
into stable:
- 196d3a4c0649094353b56fb3af81014ee8c8 by Teodor Dutu:
Fix Issue 23959 - Move lowerings to `_d_array{setassign,assign_{l,r}}` to a
`LoweredAssignExp` AST node
The compiler now uses a `LoweredAssignExp` node for assignmets that
lower to `_d_arrayassign_{l,r}`
Signed-off-by: Teodor Dutu
https://github.com/dlang/dmd/pull/15295
--
[Issue 23973] static constructors should have to be nothrow
https://issues.dlang.org/show_bug.cgi?id=23973 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- Would make sense to apply the same constraints for static destructors? Actually, I think that that would make sense for constructors and destructors in general. --
[Issue 23970] [REG2.097.0] Deprecation not emitted when selectively importing deprecated function
https://issues.dlang.org/show_bug.cgi?id=23970 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from RazvanN --- Yes, it could be implemented, however it will add cyclomatic complexity for no apparent benefit since the deprecation is issued on the call site anyway. --
[Issue 23968] Deprecation not emitted with alias to template function in UFCS
https://issues.dlang.org/show_bug.cgi?id=23968 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #15317 "Fix Issue 23968 - Deprecation not emitted with alias to template function in UFCS" fixing this issue: - Fix Issue 23968 - Deprecation not emitted with alias to template function in UFCS https://github.com/dlang/dmd/pull/15317 --
[Issue 23970] [REG2.097.0] Deprecation not emitted when selectively importing deprecated function
https://issues.dlang.org/show_bug.cgi?id=23970 --- Comment #2 from Vladimir Panteleev --- That sounds fine to me. I just want to note that maybe deprecation should be a property that is tracked for overload sets; then, maintaining that property on the overload set, and checking if all of the functions in the overload set are deprecated, become a O(1) operation. --
[Issue 23988] Conditional Exp does not bring enums to correct common type if one leg is const
https://issues.dlang.org/show_bug.cgi?id=23988 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #15316 "fix Issue 23988 - Conditional Exp does not bring enums to correct com…" fixing this issue: - fix Issue 23988 - Conditional Exp does not bring enums to correct common type if one leg is const https://github.com/dlang/dmd/pull/15316 --
[Issue 23988] New: Conditional Exp does not bring enums to correct common type if one leg is const
https://issues.dlang.org/show_bug.cgi?id=23988
Issue ID: 23988
Summary: Conditional Exp does not bring enums to correct common
type if one leg is const
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
Consider:
enum E : ubyte { A }
pragma(msg, "test1 ", typeof(1 ? E.A : E.A));
pragma(msg, "test2 ", typeof(1 ? E.A : cast(const)E.A));
which prints:
test1 E
test2 int
when it should print:
test1 E
test2 const(E)
The spec sez:
"If either the second or third expressions are of type void, then the resulting
type is void. Otherwise, the second and third expressions are implicitly
converted to a common type which becomes the result type of the conditional
expression."
https://dlang.org/spec/expression.html#conditional_expressions
Note that it doesn't exactly say what the common type is, but what the compiler
is doing is not expected. But the most obvious result should be const(E).
--
[Issue 23970] [REG2.097.0] Deprecation not emitted when selectively importing deprecated function
https://issues.dlang.org/show_bug.cgi?id=23970 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- I think this behavior is fine. Note that `fun` may also have a non-deprecated overload, in which case you are selectively importing an overload set. In that case, it would be wrong to output a deprecation. In this case, checking all overloads for a non-deprecated one seems like an overkill. From that point of view, having an overload set of just one overload means that we don't have to output the deprecation. Of course, a special case can be added: for overload sets with just one overload check if it is deprecated, but this seems overkill to me; the deprecation is going to be issued at the call site any way. --
[Issue 23983] Better error message when brace missing after `else`
https://issues.dlang.org/show_bug.cgi?id=23983
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #6 from RazvanN ---
(In reply to ryuukk_ from comment #5)
> > A human could guess the problem is at line 8, but formally, the else branch
> > is not required to have braces, and the } after the else branch could close
> > the main function.
>
> You don't understand, let me bring you my project and the problem that led
> me to create this issue
>
> https://gist.github.com/ryuukk/a4580ef154bf7801670e02a13f760858
>
>
> ```
> projects/game/context.d(566,1): Error: unmatched closing brace
> ```
>
>
> Try to find where the problem is
>
>
>
> > I understand and agree, I'm just wondering how the compiler could
> > algorithmically find out the problem is likely at line 8. Perhaps it could
> > take note of the mismatched indentation of the closing brace after else,
> > and report that once it encounters a missing brace error.
>
> I don't know, i am not a compiler developer, my role is to report issues i
> encounter
You are right for complaining about this. However, what Dennis is pointing out
is that this code is perfectly fine:
void main()
{
int stuff = 0;
version (Posix)
{
stuff++;
}
else
stuff++;
}
So, the compiler parses this and has no complaints. Next, you add another
brace:
void main()
{
int stuff = 0;
version (Posix)
{
stuff++;
}
else
stuff++;
}
}
The compiler sees this code as being valid up until the last brace. Then it
tries to consume the next token which is another curly brace so it just errors
and says that you have an unmatched closing brace. In this scenario, it is
impossible for the compiler to go back and rescan previous tokens to try and
better understand how the braces were meant to be used. Even if it did, your
code up to the problematic last brace is perfectly valid. Moreover, look at C:
void main()
{
int a;
if (1)
{}
else
a = 2;
}
}// line 9
This code yields:
gcc: test.c:9:1: error: expected identifier or ‘(’ before ‘}’ token
clang: test.c:9:1: error: extraneous closing brace ('}')
Which is the same thing the D compiler is complaining about.
So, although I understand your point, as Dennis pointed out there is no
algorithmic way in which what you are asking for can be done.
--
[Issue 23947] If a class overloads a method mixing private and public and the last overload is public, the method is always public.
https://issues.dlang.org/show_bug.cgi?id=23947 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #15282 "Fix issue 23947: Class method private is ignored if there's a public overload after it" was merged into master: - 8feaf5262cf35aa48b26b5177c9c1db2790f341c by Mathis Beer: Fix issue 23947: If checking access after overload resolution, only check the specific overload selected, not the most public overload of the set. This deprecation also covers the deprecation for issue 21275. This is a deprecation because making it an error would force issue 21275 to be an error as well. https://github.com/dlang/dmd/pull/15282 --
[Issue 23965] [REG2.101.0] Appending deprecated structs in deprecated function causes deprecation message
https://issues.dlang.org/show_bug.cgi?id=23965 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @teodutu updated dlang/dmd pull request #15315 "Fix Issue 23959 - Propagate deprecation to `_d_arrayappendcTXImpl` if the calling scope is deprecated" fixing this issue: - Fix Issue 23965 - Propagate deprecation to `_d_arrayappendcTXImpl` if the calling scope is deprecated This is needed if the lowered expression (`arr ~= elem`) is made within a deprecated context to avoid spurious deprecation messages about the hook being emitted. Signed-off-by: Teodor Dutu https://github.com/dlang/dmd/pull/15315 --
[Issue 23959] [REG2.101.0] Copying arrays of types with postblits from varargs broken
https://issues.dlang.org/show_bug.cgi?id=23959 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @teodutu created dlang/dmd pull request #15315 "Fix Issue 23959 - Propagate deprecation to `_d_arrayappendcTXImpl` if the calling scope is deprecated" fixing this issue: - Fix Issue 23959 - Propagate deprecation to `_d_arrayappendcTXImpl` if the calling scope is deprecated This is needed if the lowered expression (`arr ~= elem`) is made within a deprecated context to avoid spurious deprecation messages about the hook being emitted. Signed-off-by: Teodor Dutu https://github.com/dlang/dmd/pull/15315 --
