[Issue 23999] literal suffixes dont mix well with template instantiations
https://issues.dlang.org/show_bug.cgi?id=23999 --- Comment #5 from Puneet Goel --- s/limiter/literal --
[Issue 23999] literal suffixes dont mix well with template instantiations
https://issues.dlang.org/show_bug.cgi?id=23999 --- Comment #4 from Puneet Goel --- There needs to be a mandatory delimiter (whitespace) between the limiter, which is a part of the type (template instance) and the object being declared. --
[Issue 23999] literal suffixes dont mix well with template instantiations
https://issues.dlang.org/show_bug.cgi?id=23999 Puneet Goel changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from Puneet Goel --- By ambiguity I meant how it would be perceived by an end user. "Programs are meant to be read by humans and only incidentally for computers to execute." Donald Knuth --
[Issue 20008] __traits(allMembers) of packages is complete nonsense
https://issues.dlang.org/show_bug.cgi?id=20008 JR changed: What|Removed |Added CC||zor...@gmail.com --
[Issue 20008] __traits(allMembers) of packages is complete nonsense
https://issues.dlang.org/show_bug.cgi?id=20008 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #4 from Dlang Bot --- @dkorpel created dlang/dmd pull request #15335 "Fix 20008 - __traits(allMembers) of packages is complete nonsense" fixing this issue: - Fix 20008 - __traits(allMembers) of packages is complete nonsense https://github.com/dlang/dmd/pull/15335 --
[Issue 23999] literal suffixes dont mix well with template instantiations
https://issues.dlang.org/show_bug.cgi?id=23999
Dennis changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||dkor...@live.nl
Resolution|--- |INVALID
--- Comment #2 from Dennis ---
There is no ambiguity.
> The source text is split into tokens using the maximal munch algorithm, i.e.,
> the lexical analyzer assumes the longest possible token.
https://dlang.org/spec/lex.html#source_text
The longest possible tokens in your example are `q{foo}` and `q{foo}c`
respectively, leaving `bb` and `c` as identifier tokens.
--
[Issue 23999] literal suffixes dont mix well with template instantiations
https://issues.dlang.org/show_bug.cgi?id=23999 Basile-z changed: What|Removed |Added Hardware|x86_64 |All Summary|Potentially Ambiguous |literal suffixes dont mix |Template Instatiation |well with template ||instantiations OS|Linux |All --
[Issue 24000] show the open bracket "{" location for Error: matching `}` expected, not `End of File`
https://issues.dlang.org/show_bug.cgi?id=24000
Dlang Bot changed:
What|Removed |Added
Keywords||pull
--- Comment #1 from Dlang Bot ---
@ntrel created dlang/dmd pull request #15334 "Fix Issue 24000 - show open
bracket "{" location for Error: matching …" fixing this issue:
- Fix Issue 24000 - show open bracket "{" location for Error: matching `}`
expected
https://github.com/dlang/dmd/pull/15334
--
[Issue 24003] return/scope inference does not end up in type to some degree
https://issues.dlang.org/show_bug.cgi?id=24003 --- Comment #2 from Dlang Bot --- @dkorpel created dlang/dmd pull request #15333 "Issue 24003 - mangle inferred return/scope attributes in parameters" mentioning this issue: - Issue 24003 - mangle inferred return/scope attributes in parameters https://github.com/dlang/dmd/pull/15333 --
[Issue 23996] pragma(assume)
https://issues.dlang.org/show_bug.cgi?id=23996
--- Comment #7 from timon.g...@gmx.ch ---
(In reply to elpenguino+D from comment #6)
> (In reply to Bolpat from comment #5)
> > (In reply to elpenguino+D from comment #1)
> ...
> An assertion is just an enforced assumption. They both mean the same thing.
> ...
They are dual. An assertion is a proof obligation, an assumption is an axiom.
It's more obvious in a verifier. Standard definitions in Hoare logic:
{ P ∧ Q } assert(P) { Q }
{ Q } assume(P) { P ∧ Q }
In D, `assert` is `@safe`, `assume` has to be `@system`. You can't do hard
optimizations based on unchecked assumptions (in particular in `@safe` code)
while following the D specification, any flag that does so deviates from the
specification of `@safe`. This is why this enhancement is important, it enables
actually giving `@trusted` optimization hints in a sound manner.
--
[Issue 23996] pragma(assume)
https://issues.dlang.org/show_bug.cgi?id=23996 --- Comment #6 from elpenguin...@gmail.com --- (In reply to Bolpat from comment #5) > (In reply to elpenguino+D from comment #1) > > I think assert(expr) could provide this functionality. Maybe with a > > -checkaction=assume switch? It would also work for contracts, invariants, > > etc then, while also making it trivial to test the assumptions. > > I’d say this is really bad design. An assertion and an assumption mean > totally different things. With a compiler flag, you control all of them at > once. > > Just for an example, an assumption can be used to inform the compiler about > a truth that its optimization routines can make use of and that its > optimization routines could not figure out themselves. > An assert might be used to validate function input, e.g. `isPrime(int x)` > might `assert(x > 0)`. An assertion is just an enforced assumption. They both mean the same thing. assert(): - code following is optimized with the assumption that the condition is true - undefined behaviour if condition is false pragma(assume): - code following is optimized with the assumption that the condition is true - undefined behaviour if condition is false It is legal for assert() to influence the optimizer without actively checking the condition, and this proposal would also allow a compiler to actively check and enforce the condition in pragma(assume) - it is undefined behaviour, and it might be useful to prove your assumptions while debugging. Enabling assertions to be treated as unchecked assumptions additionally allows for invariants and contracts to influence optimizations, though current compilers don't appear to be capable of optimizing invariants... --
[Issue 24003] return/scope inference does not end up in type to some degree
https://issues.dlang.org/show_bug.cgi?id=24003 Dennis changed: What|Removed |Added CC||dkor...@live.nl --- Comment #1 from Dennis --- (In reply to Bolpat from comment #0) > Also, there’s some Schrödinger action going on with template type inference. Yes, I'm all too aware of this. It was decided at some point to make inferred `scope` and `return` not part of the type mangle, so that there wouldn't be link errors between phobos compiled with dip1000 and user code without it. However, the compiler uses the mangle internally as the identity of a type. So if two types have the same mangled name, they are considered equal. I tried undoing this, but of course, that breaks everything, so it's going to be hard to untangle the mess. --
[Issue 23964] [REG2.102] inccorect error opAssign cannot be used ... @disable
https://issues.dlang.org/show_bug.cgi?id=23964 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #15332 "Fix Issue 23964 - [REG2.102] inccorect error opAssign cannot be used …" fixing this issue: - Fix Issue 23964 - [REG2.102] inccorect error opAssign cannot be used ... @disable https://github.com/dlang/dmd/pull/15332 --
[Issue 23996] pragma(assume)
https://issues.dlang.org/show_bug.cgi?id=23996 --- Comment #5 from Bolpat --- (In reply to elpenguino+D from comment #1) > I think assert(expr) could provide this functionality. Maybe with a > -checkaction=assume switch? It would also work for contracts, invariants, > etc then, while also making it trivial to test the assumptions. I’d say this is really bad design. An assertion and an assumption mean totally different things. With a compiler flag, you control all of them at once. Just for an example, an assumption can be used to inform the compiler about a truth that its optimization routines can make use of and that its optimization routines could not figure out themselves. An assert might be used to validate function input, e.g. `isPrime(int x)` might `assert(x > 0)`. --
[Issue 24003] New: return/scope inference does not end up in type to some degree
https://issues.dlang.org/show_bug.cgi?id=24003
Issue ID: 24003
Summary: return/scope inference does not end up in type to some
degree
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
When function attributes are inferred, they end up in the type:
```d
auto f() {}
static assert(is(typeof() == void function() @safe nothrow @nogc pure));
```
However, when parameters’ `scope` and `return` attributes are inferred, they
are not displayed in error messages or `pragma(msg)`.
They might not be displayed, but could still (silently) be part of the type;
but in a Schrödinger fashion, they are and they are not:
```d
auto f(int[] xs) @safe
{
static int ctr;
ctr++; // force impure
return xs;
}
void tplTypeInfer(F)(ref F fp1, ref F fp2)
{
int[3] xs;
fp1(xs);
fp2(xs);
}
//void nonTpl(ref int[] function(int[] xs) nothrow @nogc @safe fp) @safe
//{
////int[3] xs;
////fp(xs);
//}
void main() @safe
{
int[3] xs;
f(xs); // good: `xs` binds to parameter inferred `return scope`.
static assert(typeof().stringof ==
"int[] function(int[] xs) nothrow @nogc @safe");
alias F1 = int[] function(int[] xs) nothrow @nogc @safe;
alias F2 = typeof();
static assert(is(F1 == F2)); // PASSES!
F1 fp1 = // This and …
F2 fp2 = // … this should behave the same, right?
fp1(xs); // error: reference to local variable `xs` assigned to non-scope
parameter `xs`
fp2(xs); // good (apparently, the parameter is scope here)
tplTypeInfer(fp1, fp2);// good/error depending on if nonTpl is
commented-in
tplTypeInfer(fp2, fp1);// good/error (same)
tplTypeInfer!F1(fp1, fp2); // good/error (same)
tplTypeInfer!F1(fp2, fp1); // good/error (same)
tplTypeInfer!F2(fp1, fp2); // good/error (same)
tplTypeInfer!F2(fp2, fp1); // good/error (same)
}
```
It seems that if you *use* the function pointer, it remembers somehow that the
parameter is inferred scope.
Also, there’s some Schrödinger action going on with template type inference.
--
[Issue 24002] New: "The CodeView record is corrupted" heisenbug
https://issues.dlang.org/show_bug.cgi?id=24002 Issue ID: 24002 Summary: "The CodeView record is corrupted" heisenbug Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Keywords: DebugInfo, link-failure Severity: blocker Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: dlang-bugzi...@thecybershadow.net Created attachment 1882 --> https://issues.dlang.org/attachment.cgi?id=1882=edit Reproducer Given certain inputs, dmd will produce output that lld-link refuses to consume, failing with the message: lld-link: error: codeview::mergeTypeAndIdRecords failed: The CodeView record is corrupted. Unfortunately it is difficult to reduce the exact inputs which trigger this bug. It seems to be related to the size of the program being compiled, and maybe things like exact alignment. It may be a buffer overflow that causes the output to be corrupted only under certain conditions. I am attaching an input which reliably reproduces the problem with DMD 2.101.0 for Windows, as obtainable from https://downloads.dlang.org/releases/2.x/2.101.0/dmd.2.101.0.windows.7z. Other versions of D may or may not reproduce the bug, as I'm sure that changes in Phobos/Druntime affect the outcome as well. To reproduce, edit reproduce.cmd to point it to the path to where your copy of the 2.101.0 dmd.exe is located, and run it. You should get a bunch of deprecation warnings followed by the link error above. --
[Issue 23312] Crash when calling writeln in WinMain
https://issues.dlang.org/show_bug.cgi?id=23312 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24001 --
[Issue 12990] utf8 string not read/written to windows console
https://issues.dlang.org/show_bug.cgi?id=12990 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24001 --
[Issue 24001] Add console module to replace std.stdio
https://issues.dlang.org/show_bug.cgi?id=24001 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=23312, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=6880, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=1448, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=12990, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=15761 --
[Issue 6880] Heisenbug: deferred crash when writing to stdout on Windows without console.
https://issues.dlang.org/show_bug.cgi?id=6880 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24001 --
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24001 --
[Issue 1448] UTF-8 output to console is seriously broken
https://issues.dlang.org/show_bug.cgi?id=1448 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24001 --
[Issue 24001] New: Add console module to replace std.stdio
https://issues.dlang.org/show_bug.cgi?id=24001 Issue ID: 24001 Summary: Add console module to replace std.stdio Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: alphaglosi...@gmail.com Consoles are a special subclass of standard IO. On Windows you want to use the UTF-16 instead of UTF-8/ANSI functions to read and write to it. This circumvents the need for setting code pages which don't always work and have to be reset when the program has been completed. It would also be ideal to have timeout support for reading. It should not throw exceptions if a console has not been attached. Instead, completion with no failure would be more desirable in the cases such as in a GUI program. This bug ticket represents a solution to the following reports: https://issues.dlang.org/show_bug.cgi?id=23312 https://issues.dlang.org/show_bug.cgi?id=6880 https://issues.dlang.org/show_bug.cgi?id=1448 https://issues.dlang.org/show_bug.cgi?id=12990 https://issues.dlang.org/show_bug.cgi?id=15761 --
[Issue 23756] Add thread local constructor/destructor pragma
https://issues.dlang.org/show_bug.cgi?id=23756 --- Comment #3 from Richard Cattermole --- I had a look at that PR. Nothing in it looks to be adding a per-thread constructor/destructor. It only adjusts the existing crt_constructor/destructor behavior. Without changing what list of hooks it gets added to. From what I can tell it is unrelated to this ticket. --
[Issue 23756] Add thread local constructor/destructor pragma
https://issues.dlang.org/show_bug.cgi?id=23756 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- > It is necessary to have a libc-based constructor/destructor at the thread > level. https://github.com/dlang/dmd/pull/14669 --
