Comment #0 by timothee.cour2 — 2013-12-03T11:09:49Z
when building from git head I now get, when running make -f posix.mak under tools:
dget.d(49): Error: ScopeDsymbol dget.__anonymous.__anonymous template std.regex.ctRegex(alias pattern, alias flags = []) is private
How come those errors aren't automatically caught? isn't there an autotester for tools repo? I've seen many breakages for tools repo.
Comment #1 by timothee.cour2 — 2013-12-03T11:24:37Z
> How come those errors aren't automatically caught? isn't there an autotester
for tools repo?
No test suite for tools currently :(, though some work was started for rdmd.
Comment #3 by dmitry.olsh — 2013-12-03T12:20:55Z
Works for me, I run
dmd dget.d
with whatever version of DMD 2.065 alpha I had.
Comment #4 by timothee.cour2 — 2013-12-03T13:22:07Z
(In reply to comment #2)
> > How come those errors aren't automatically caught? isn't there an autotester
> for tools repo?
>
> No test suite for tools currently :(, though some work was started for rdmd.
Before even thinking of a writing an elaborate test suite, there should at the very least be a unittest (or other program) that tries to build the various makefiles. Currently that's what failed so many times for me.
Comment #5 by timothee.cour2 — 2013-12-03T13:24:20Z
(In reply to comment #3)
> Works for me, I run
>
> dmd dget.d
>
> with whatever version of DMD 2.065 alpha I had.
It failed for me on that step:
dmd -c -ofgenerated/osx/64/dget.o dget.d
(on osx)
and it worked with my pull.
(note, I'm building from git head)
Comment #6 by code — 2013-12-03T17:10:13Z
cat > bug.d << CODE
import std.regex;
void main()
{
enum rule = ctRegex!"";
}
CODE
dmd -c bug
----
bug.d(5): Error: module bug template std.regex.ctRegex(alias pattern, alias flags = []) is private
----
Fails for me too.
DMD64 D Compiler v2.065-devel-7088593
druntime-8cfd7f5
phobos-ae34e22
(In reply to comment #5)
> (In reply to comment #3)
> > Works for me, I run
> >
> > dmd dget.d
> >
> > with whatever version of DMD 2.065 alpha I had.
>
> It failed for me on that step:
> dmd -c -ofgenerated/osx/64/dget.o dget.d
> (on osx)
> and it worked with my pull.
> (note, I'm building from git head)
You are right, it's a recent regression caused by my refactoring.
Sadly we don't have (yet) a way to test accessibility of symbols, I hope that will come with splitting up modules.
Comment #11 by jakobovrum — 2013-12-04T10:26:46Z
(In reply to comment #10)
> You are right, it's a recent regression caused by my refactoring.
> Sadly we don't have (yet) a way to test accessibility of symbols, I hope that
> will come with splitting up modules.
Technically we can test it with `__traits(getProtection, symbol)`. This is probably the kind of thing that would become more practical with a more advanced testing library than the barebones we get by default.
Comment #12 by monarchdodra — 2013-12-04T13:09:47Z
(In reply to comment #11)
> (In reply to comment #10)
> > You are right, it's a recent regression caused by my refactoring.
> > Sadly we don't have (yet) a way to test accessibility of symbols, I hope that
> > will come with splitting up modules.
>
> Technically we can test it with `__traits(getProtection, symbol)`. This is
> probably the kind of thing that would become more practical with a more
> advanced testing library than the barebones we get by default.
Another (simpler) solution would be to include "programs" with phobos that are part of the testing suite. Not only would it cover things a bit more "real-world"-ish then the "unitary" "unittests", but it would also cover the public/private issues (you don't cover with unittests), as well as make sure it still works outside of a "version(unittest)" case (we've had a couple of these too).
Currently, the closest we have is "dmd"'s testing suite: I've seen more than a couple of additions to phobos that passed phobo's test's with flying colors, but *broke* dmd's test suite: Specifically because dmd's test suite is an actual program written in D.
Comment #13 by github-bugzilla — 2013-12-09T04:04:56Z