www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8220] New: invalid function call not detected during semantic analysis

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220

           Summary: invalid function call not detected during semantic
                    analysis
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: timon.gehr gmx.ch



DMD 2.059:

void foo(int){}
static assert(!__traits(compiles,foo(typeof(0)))); // fail

The static assertion should pass.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 11 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, pull



https://github.com/D-Programming-Language/dmd/pull/1000

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 11 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220




Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f20292b8738155431589915166770abd8a2ce82a
fix Issue 8220 - invalid function call not detected during semantic analysis

https://github.com/D-Programming-Language/dmd/commit/cb3da3bf9e3f54ec3e89061c99adfd54045fbd80


Issue 8220 - invalid function call not detected during semantic analysis

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 13 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220




00:27:28 PDT ---
Created an attachment (id=1115)
failing test case

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 14 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220






 Created an attachment (id=1115) [details]
 failing test case


I think this test case is not correct code.

(From test case)

 alias typeof(Length*Length) 		Area;
 alias typeof(Length*Area) 		Volume;
 alias typeof(Mass/Volume) 		Density;
 alias typeof(Length*Mass/Time/Time) 	Force;
 alias typeof(1/Time) 			Frequency;
 alias typeof(Force/Area) 		Pressure;
 alias typeof(Force*Length) 		Energy;
 alias typeof(Energy/Time) 		Power;
 alias typeof(Time*Current) 		Charge;
 alias typeof(Power/Current) 		Voltage;
 alias typeof(Charge/Voltage) 		Capacitance;
 alias typeof(Voltage/Current) 		Resistance;
 alias typeof(1/Resistance) 		Conductance;
 alias typeof(Voltage*Time) 		MagneticFlux;
 alias typeof(MagneticFlux/Area) 	MagneticFluxDensity;
 alias typeof(MagneticFlux/Current) 	Inductance;
 alias typeof(Intensity*UnitLess) 	LuminousFlux;
 alias typeof(LuminousFlux/Area) 	Illuminance;


As far as I know, normal expressions cannot take Type as their operands, even
if it is defined by operator overloading.

 struct S { void opMul(S s){} }
 S + S;   // this is INVALID code

This rule should be applied even in typeof expression, then
typeof(Length*Length) must be invalid.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 14 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220


klickverbot <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code klickverbot.at



---


 Created an attachment (id=1115) [details]
 failing test case


I also think this is genuinely invalid code: Besides the fact that there isn't
really a good reason, grammar-wise, for the code to compile, allowing it as a
special case in typeof() would create exactly the same sort of problems with
is(typeof()) as with __traits(compiles, …) in the original report.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 14 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220




Opened identical pull:
https://github.com/D-Programming-Language/dmd/pull/1007

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 15 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



14:16:22 PDT ---
This example has been around a long time, and I've been telling people that
that's the way to do it. I'm really reluctant to break it, and there doesn't
seem to be an obvious other way to do it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220






 This example has been around a long time, and I've been telling people that
 that's the way to do it. I'm really reluctant to break it,


The behaviour must be fixed for __traits(compiles,...), but not necessarily for
typeof.


 and there doesn't seem to be an obvious other way to do it.


alias typeof(Length.init*Length.init)         Area;
alias typeof(Length.init*Area.init)         Volume;
alias typeof(Mass.init/Volume.init)         Density;
...

or even

alias typeof(meter*meter)                       Area;
alias typeof(meter*meter*meter)                 Volume;
alias typeof(kilogram/(meter*meter*meter))      Density;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220




---


 This example has been around a long time, and I've been telling people that
 that's the way to do it. I'm really reluctant to break it, and there doesn't
 seem to be an obvious other way to do it.


Just use typeof(U.init * V.init).

The idea might have seemed nice originally, but I think it has to go the 'bit'
route. At least in my opinion, allowing types to be used in place of
expressions is one of the most confusing things you can do to the poor
programmers out there. I recall stumbling over strange behavior is(typeof(…))
several times in the past, and this might have well been the reason.

What's more, is this interpretation backed by the spec in any way? If not, I
can hardly imagine that any alternative frontend would implement typeof() like
this.

To restate my point, typeof(<code>) acting differently than just <code> is a
huge source of confusion (constant folding and apparent null pointer
dereferences in typeof() can be bad enough already). There would have to be a
very good excuse not to remove this special case.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220




---


 alias typeof(meter*meter)                       Area;
 alias typeof(meter*meter*meter)                 Volume;
 alias typeof(kilogram/(meter*meter*meter))      Density;


For an example of a working design similar to this, see my std.units prototype
(there didn't seem to be much interest in it, so I never actually pursued
Phobos integration so far):

https://github.com/klickverbot/phobos/blob/units/std/units.d
http://klickverbot.at/code/units/std_units.html

(the implementation is more ugly than it needs to be because of a number of
now-fixed compiler bugs, but that's not the point here)

Note how any template taking a unit type also accepts an alias to a unit
struct, thus removing the need to deal with the actual unit types in virtually
all situations, which avoids cluttering up the code with typeof() and .init.
For example, new compound units are just defined like this:

---
enum newton = kilogram * metre / pow!2(second);
---

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220




---




 This example has been around a long time, and I've been telling people that
 that's the way to do it. I'm really reluctant to break it,


 
 The behaviour must be fixed for __traits(compiles,...), but not necessarily for
 typeof.


I think this would be opening a very big can of worms, because is(typeof(…))
has been equivalent to __traits(compiles, …) so far (well, for things that
have
a type).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220










 This example has been around a long time, and I've been telling people that
 that's the way to do it. I'm really reluctant to break it,


 
 The behaviour must be fixed for __traits(compiles,...), but not necessarily for
 typeof.


 
 I think this would be opening a very big can of worms, because is(typeof(…))
 has been equivalent to __traits(compiles, …) so far (well, for things that
have
 a type).


I don't think that not conflating the notions of being able to deduce a type
for 
an expression and of whether or not it actually compiles in a given context is 
opening any cans of worms.

What I am suggesting is to make __traits(compiles, ...) behave like is(typeof({
...;})).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220




Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/d56194cd99c160c00fb831aacf4315791a9e62c7
fix Issue 8220 - invalid function call not detected during semantic analysis

https://github.com/D-Programming-Language/dmd/commit/3644943a299b5e50157c8b2f8cfec609fed5fd68


[Repost] Issue 8220 - invalid function call not detected during semantic
analysis

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 06 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8220


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement



22:55:42 PST ---
I'm going to mark this as an enhancement because it changes existing behavior,
and that behavior was relied upon, even though arguably it should never have
accepted that behavior.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 06 2013