[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #22 from Mathias Lang  ---
> I think what you are saying is that a mixed in template could affect existing 
> *imports*, right? But an import can already do that! Ignoring imports with 
> mixins doesn't fix this problem.

An import can already hijack an import if it appears at scope lexically
'closer' to the looked-up symbol, but yes, imports can still hijack.
I don't know if there is any solution to that issue, short of allowing only one
level of import, which of course is out of question.

> The mixin could not hijack local symbols, right? I thought that was the 
> larger point -- you are referring to class/local symbols, or even module 
> functions, and suddenly that changes through a hijacked import.

It could be implemented both ways, since those are two different lists of
imports. I believe the sane way to do it (and the approach I used IIRC) would
be to look up mixed in / inherited imports after local ones.

> I get that it's good to prevent hijacking as much as possible. But this 
> doesn't disallow hijacking to any further degree than is already disallowed. 
> In other words, preventing mixins from hijacking imported symbols doesn't 
> remove the problem, and just makes the language inconsistent.

It disallows some imports, so it *does* prevent hijacking by definition.
Whether or not those hijackings are a common enough source of bugs, and the
feature it disallows is useful, is up to one's judgment.

As for inconsistency, I disagree. With the separated lookup, there is no way to
inherit an 'import scope'. This means any hijacking can only ever come from an
import that is in your module. I believe that was the important property Walter
was after: https://issues.dlang.org/show_bug.cgi?id=15966#c3

Note that as the original author of this issue (and the similar #15966) I'm
only the messenger, and not the one that took the decision.
IOW, I'm fighting someone else's war here, and he's the one you have to
convince if you want this overturned :-)

--

[Issue 16312] "Error: Overlapping fields" caused by use of deprecated features in referred to fields

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16312

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #1 from Mathias Lang  ---
Note: Only when compiled with `-de`.

They are two things at play here:

- First, when the compiler encounter an error, it 'poison' the AST node.
That can lead to wrong error messages in places not adjusted to deal with the
poisoning.

- Second, the compiler treat a non-fatal error (e.g. a warning when `-w` is
provided or a deprecation when `-de` is provided) as a fatal one. This can have
extremely dangerous consequences, e.g. the following will still compiles, just
have different behaviour:

```
class Deprecated
{
int j;
this (T) (T i)
{
this.j = (i, T.init);
}
}

template Foo (T) if (__traits(compiles, { T a = new T(42); }))
{
enum Foo = "First instance";
}

template Foo (T) if (!__traits(compiles, { T a = new T(42); }))
{
enum Foo = "Second instance";
}

pragma(msg, Foo!(Deprecated));
```

The second bug is well known, so I suppose this ER is about the first point ?

--

[Issue 16312] "Error: Overlapping fields" caused by use of deprecated features in referred to fields

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16312

Marco Leise  changed:

   What|Removed |Added

   Severity|enhancement |minor

--

[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15498

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #12 from Marco Leise  ---
Hmm, recently I see different "overlapping fields" error messages popping up
after certain types of deprecations are detected on the involved fields. There
may be a connection: https://issues.dlang.org/show_bug.cgi?id=16312

--

[Issue 16312] New: "Error: Overlapping fields" caused by use of deprecated features in referred to fields

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16312

  Issue ID: 16312
   Summary: "Error: Overlapping fields" caused by use of
deprecated features in referred to fields
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: diagnostic, rejects-valid
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: marco.le...@gmx.de

The compiler sees fields as overlapping when there are certain types of
deprecated features involved in the types of those fields. The two trigger
features I could make out are using full symbol paths to bypass imports (i.e.
using core.stdc.stdlib.free without importing core.stdc.stdlib) and providing a
struct ctor with all arguments having defaults. If such a "deprecated" struct
is then used with other fields in an aggregate in a way it would not be allowed
for overlapping fields, an error is printed. Here is a short example:

struct Deprecated
{
this(int i = 0) {}
}

class Bogus
{
Deprecated* a = null;
int seems_to_overlap = 0;
}

Deprecation: constructor app.Deprecated.this all parameters have default
arguments, but structs cannot have default constructors.
Error:   overlapping default initialization for field a and
seems_to_overlap

Whether or not the compiler would actually silently overlap the two fields
under other circumstances is not known to me.

Related in some way:
https://issues.dlang.org/show_bug.cgi?id=15498
(Unhelpful error message "destructors, postblits and invariants are not allowed
in overlapping fields")

--

[Issue 16310] std.zip: can't specify archive member order

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16310

Chris Wright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Chris Wright  ---
https://github.com/dlang/phobos/pull/4637

--