Introduced in PR #9331, this was changed from a normal bug fix to a
-preview switch because enabling it triggered a suprious "statement is
not reachable" warning in Phobos. That warning has since been removed
(in PR #15568).
Commit a3abf1187e fixes some cases of
lambdas having unstable symbol names between compilation units by
using `generateIdWithLoc` to generate stable lambda names, however since
LOC doesn't uniquely identify a lambda instance (because templates,
mixins, static foreach and foreach unrolling), `generateIdWithLoc`
adds a counter, so there is still some instability going on.
`generateIdWithLoc` makes the name uniq per file+loc, by adding adding a
numeric suffix. But the order of instantiations might be different
across compilation units, so with this counting scheme we are back to
unstable names, so one module might have
`t!0.__lambda_LOC` and
`t!1.__lambda_LOC_1`
while another one has
`t!1.__lambda_LOC`
This is not a critical problem, but at very least the code gets
duplicated for no reason. I also have an example where it leads to
linking error, but since it's not a small one and fails to minimize
further, I suspect it's a result of interaction with some other bug.
The thing is we don't even need uniqueness for those lambdas inside
templates/mixins: their final names will have the instantiation prefix anyway.
But we can't also just disable this uniqueness check completely: `static
foreach` as well as unrollings of the normal `foreach` with lambdas in
the loop body will have several copies of a single lambda with the same
file+loc. So here we do want to keep making them unique. Fortunately, I
don't think a `foreach` could be iterated in different order in
different compilation units, so hopefully if we limit the counting to
this case only, it won't make symbols unstable.
To implement this idea, I've added an extra `parent` argument to
`generateIdWithLoc`: it works like using `parent ~ prefix` prefix, but
without adding `parent` to the final output.
Fixes since last review:
1. Changed `fromStringz` to `toDString`
2. Added a test to showcase the problem
Pr #14837 added templated lowering for _d_newclass and
lowering field to NewExp. Pr #13494 added templated lowering
for _d_newThroable. This Pr merges those two.
In expressionsem.d, instead of giving up the expression node and
keeping just the id.expressionSemantic of it, the result is the
whole node with all its previous fields and a new one, lowering,
that is set to the previously returned value.
In e2ir.d, for a newExpression, the expression is already created
in the semantic phase with all the arguments needed, so the visitor
will not recreate it, therefore the assert at line 1153 is no longer
necessary.
Signed-off-by: Andrei Rusanescu <andreirusanescu154@gmail.com>
Fix bugzilla issue 24871 - DDoc strips indent in triple slash comments
Signed-off-by: Dennis <dkorpel@users.noreply.github.com>
Signed-off-by: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Merged-on-behalf-of: Nicholas Wilson <thewilsonator@users.noreply.github.com>
Removes code in the lexer responsible for removing leading spaces in
triple slash doc comments.
This affects the test file for issue 14413; two more spaces appear, but
they are not significant in the HTML output.
PR #14985 introduced `LoweredAssignExp` with a separate field to store the
lowering during semantic analysis. Then #15791 placed the lowering of
`CatAssignExp`s into this field, but did not remove the code that was
previously recreating the original `CatAssignExp` from the lowering
during CTFE.
Signed-off-by: Teodor Dutu <teodor.dutu@gmail.com>
This promotion from scalar right-hand-sides to vectors already happens
for the arithmetic binops, via `typeCombine()` side effects. Handle
bit-shift expressions too now, by casting a scalar to the left-hand-side
vector type.
This can't be tested with DMD, as DMD's `Target.isVectorOpSupported()`
doesn't support bit-shifts yet. It is ~required/useful for LDC though.
