[Issue 24280] ImportC: forward reference error when compiling multiple files
https://issues.dlang.org/show_bug.cgi?id=24280
--- Comment #1 from Dennis ---
Another example: (not sure if it's the same bug)
a.c
```C
typedef struct {} Slice;
struct Lang
{
Slice *slices;
};
```
b.c
```C
typedef struct {} Slice;
struct Lang
{
Slice *slices;
};
void langmap(struct Lang *self)
{
Slice slice = *self->slices;
}
```
```
dmd a.c // works
dmd b.c // works
dmd b.c a.c // works
dmd a.c b.c // fails:
b.c(11): Error: cannot implicitly convert expression `*(*self).slices` of type
`__tag2` to `__tag3`
```
--
[Issue 24280] New: ImportC: forward reference error when compiling multiple files
https://issues.dlang.org/show_bug.cgi?id=24280
Issue ID: 24280
Summary: ImportC: forward reference error when compiling
multiple files
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
I have two single-file c libraries, and dmd can compile either one just fine,
but not at the same time. Reduced example:
a.c:
```C
struct timespec
{
int s;
};
```
b.c:
```C
struct S;
struct timespec
{
int s;
};
typedef struct timespec Clock;
Clock now()
{
Clock result;
return result;
}
struct S
{
Clock clock;
};
```
```
dmd a.c // works
dmd b.c // works
dmd b.c a.c // works
dmd a.c b.c // fails:
b.c(13): Error: forward reference to type `timespec`
```
It's very fragile, sometimes the error goes away when removing a random unused
macro `#define _POSIX_C_SOURCE 200112L` or changing an identifier name (I can't
rename `timespec`), but it does seem deterministic: I get the error every time
as long as the input stays the same.
--
[Issue 23666] Recognize template opApply pattern
https://issues.dlang.org/show_bug.cgi?id=23666 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #2 from Nick Treleaven --- You can use `auto opApply` to infer attributes instead of a template. --
[Issue 24279] Conflicting constructors/functions due to default arguments should not compile
https://issues.dlang.org/show_bug.cgi?id=24279 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #1 from Adam D. Ruppe --- I think it has to do with overload resolution not considering the visibility --
[Issue 24279] New: Conflicting constructors/functions due to default arguments should not compile
https://issues.dlang.org/show_bug.cgi?id=24279
Issue ID: 24279
Summary: Conflicting constructors/functions due to default
arguments should not compile
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: huskyna...@protonmail.ch
When constructors or functions conflict due to having the same calling
signature, they should not be allowed to compile.
This is already the case in most scenarios, but when default arguments cause
conflict, the compiler does not catch this issue. Even more so, in the case of
constructors, visibility rules are ignored.
Example:
```d
module text;
import std.stdio;
class Text {
string text;
private this(string text) {
writeln("private");
}
this(string filename, string arg2 = ".txt") {
writeln("public");
}
}
```
```d
module app;
void main(){
Text t = new Text("file"); // writes "private"
}
```
Calling `new Text("test")` from anywhere will call the first constructor,
ignoring its `private` attribute.
If this is done with functions instead of constructors, the same thing will
happen with one exception: the compiler will state the function is not
accessible. (It will however try to resolve to the private function, ignoring
the accessible alternative)
1. This hints at issues with constructors ignoring visibility attributes!
2. The code should not compile when conflicts occur (even when this is due to
default values).
--
[Issue 24278] New: std.math.abs promotes unsigned argument to 32 bits
https://issues.dlang.org/show_bug.cgi?id=24278
Issue ID: 24278
Summary: std.math.abs promotes unsigned argument to 32 bits
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
```D
import std.math;
void main()
{
assert(is(typeof(abs(ubyte(8u))) == ubyte));
}
```
The assert fails, while the documentation says "the return type will be the
same as the input."
--
[Issue 6980] Disallow shadowing template parameters
https://issues.dlang.org/show_bug.cgi?id=6980
Bolpat changed:
What|Removed |Added
CC||qs.il.paperi...@gmail.com
--- Comment #2 from Bolpat ---
The general sense of when shadowing a symbol is an error or not is if the
symbol has an unambiguous way to be referenced. This expectation is broken when
template parameters are shadowed:
```d
struct S(T)
{
alias T = int; // no error!?
T x;
pragma(msg, typeof(x)); // int
}
S!double unused;
```
--
[Issue 24276] ImportC: typedef aliases not emitted correctly in .di files
https://issues.dlang.org/show_bug.cgi?id=24276 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #15899 "fix Issue 24276 - ImportC: typedef aliases not emitted correctly in .…" was merged into master: - 0cc531948c80af3afcab95f7edf397651592ad40 by Walter Bright: fix Issue 24276 - ImportC: typedef aliases not emitted correctly in .di files https://github.com/dlang/dmd/pull/15899 --
