www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Help understanding no-runtime error?

reply Manu <turkeyman gmail.com> writes:
I'm building a majorly stripped back environment, but not quite better-c.
I removed druntime and building with an empty object.d, slowly filling it
to understand the minimum set of things I need.

I have encountered a weird error though:

  enum x = "X" == "y";

  error : incompatible types for array comparison: `string` and `string`

Most things seem to use __cmp, and certainly "X".__cmp("Y") does compile
and work.
Does anyone know why this error message? What is the compiler doing
internally that leads to such an error message? Something's obviously
missing, but I don't know what...?
Nov 12
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
Likely:

https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/array/equality.d
Nov 12
parent reply Manu <turkeyman gmail.com> writes:
On Wed, 13 Nov 2024 at 17:06, Richard (Rikki) Andrew Cattermole via
Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Likely:


 https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/array/equality.d


Oh that's so obvious! You know when the answer is right in front of your
nose, but you've convinced yourself it's somewhere else so you can't see it
no matter how long you stare at it! :P
Thanks fella! :)
Nov 12
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 13/11/2024 8:22 PM, Manu wrote:

 On Wed, 13 Nov 2024 at 17:06, Richard (Rikki) Andrew Cattermole via 
 Digitalmars-d <digitalmars-d puremagic.com <mailto:digitalmars- 
 d puremagic.com>> wrote:
 
     Likely:
 
     https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/
     array/equality.d <https://github.com/dlang/dmd/blob/master/druntime/
     src/core/internal/array/equality.d>
 
 
 Oh that's so obvious! You know when the answer is right in front of your 
 nose, but you've convinced yourself it's somewhere else so you can't see 
 it no matter how long you stare at it! :P
 Thanks fella! :)


This particular module has caused a lot of problems in -betterC.

It was fixed by turning on -allinst when -betterC is applied.

Hence this one is a well known internal detail :)
Nov 12
parent reply Manu <turkeyman gmail.com> writes:
On Wed, 13 Nov 2024 at 17:41, Richard (Rikki) Andrew Cattermole via
Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On 13/11/2024 8:22 PM, Manu wrote:

 On Wed, 13 Nov 2024 at 17:06, Richard (Rikki) Andrew Cattermole via
 Digitalmars-d <digitalmars-d puremagic.com <mailto:digitalmars-
 d puremagic.com>> wrote:

     Likely:

     https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/
     array/equality.d <https://github.com/dlang/dmd/blob/master/druntime/
     src/core/internal/array/equality.d>


 Oh that's so obvious! You know when the answer is right in front of your
 nose, but you've convinced yourself it's somewhere else so you can't see
 it no matter how long you stare at it! :P
 Thanks fella! :)


 This particular module has caused a lot of problems in -betterC.

 It was fixed by turning on -allinst when -betterC is applied.

 Hence this one is a well known internal detail :)



I really wish there was an official document which maintained a list of all
the expressions that generate runtime calls inside the compiler... there's
a hell of a lot of them!
If you sift through druntime, the fact that this code is such a mess is a
really good indicator of some core language deficits. All these things
handle SO MANY CASES.
A lot of it will resolve with move semantics and the proper emplace
expression that Walter's working... the rest of it, I dunno.
Like, look at `template _arrayOp(Args...)`, that's pretty wild stuff!
Nov 13
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2024 12:01 AM, Manu wrote:

 I really wish there was an official document which maintained a list of all
the 
 expressions that generate runtime calls inside the compiler... there's a hell
of 
 a lot of them!
 If you sift through druntime, the fact that this code is such a mess is a
really 
 good indicator of some core language deficits. All these things handle SO MANY 
 CASES.


The idea was to use the language itself to implement parts of the language, to 
keep the compiler simple.

Whether this has succeeded or not is debatable.


 A lot of it will resolve with move semantics and the proper emplace expression 
 that Walter's working... the rest of it, I dunno.


My progress on placement new has already yielded reductions in template bloat.
Nov 13
parent Manu <turkeyman gmail.com> writes:
On Thu, 14 Nov 2024 at 06:41, Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 11/13/2024 12:01 AM, Manu wrote:

 I really wish there was an official document which maintained a list of


 all the

 expressions that generate runtime calls inside the compiler... there's a


 hell of

 a lot of them!
 If you sift through druntime, the fact that this code is such a mess is


 a really

 good indicator of some core language deficits. All these things handle


 SO MANY

 CASES.


 The idea was to use the language itself to implement parts of the
 language, to
 keep the compiler simple.

 Whether this has succeeded or not is debatable.


I think it's successful in some domains. I like the *idea *of `_arrayOp`
for instance, but the complexity of some of these implementations is kinda
high.
The biggest black stain that I see is core.lifetime... these are just far
too low-level and important/critical pieces of infrastructure to leave up
to such unbelievably awkward implementations; the core issue is that these
are deep-set and fundamental language semantics, and trying to implement
them in-language is pretty absurd, because they're building-blocks
themselves.
There is *so much *code in there, and it's so ugly and gross. It all
depends on the optimiser to be reasonable; without inlining it's a
disaster. It's like cancer to symbolic debugging (which people still seem
to dismiss like it's not essential for professional-grade productivity);
steeping though core.lifetime in debug builds is frankly embarrassing.
Like; you get to a new statement, or an emplace or something and you
obviously want to step inside the constructor to watch it construct... or
even just a `move` or `forward`; those in particular appear in argument
lists all the time to setup args for a call... you try and step-in to a
function you want to inspect, and you have to work your way through 50
lines of `move` or `forward`, stepping in and out of stupid auxiliary
nonsense before you step into the function that you actually want to
inspect.
Those 2 things in particular need to be intrinsics (as they are moving
towards with the move semantic work); they shouldn't themselves yield a
single line of execution! There's no business for there to be a physical
`move` or `forward` function to step-in to; it should just be an intrinsic
that coerces an argument into the proper form... there's no code to execute.

Anyway, we seem to be moving in a good direction in this stuff. I hope you
saw my emails where I took this stuff for a test drive.



 A lot of it will resolve with move semantics and the proper emplace
 expression

 that Walter's working... the rest of it, I dunno.


 My progress on placement new has already yielded reductions in template
 bloat.


As it should! That's a large part of the point... although a uniform syntax
and concentrating initialisation code in one semantic location are pretty
worthy goals.
Nov 14
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 13 November 2024 at 08:01:00 UTC, Manu wrote:

 I really wish there was an official document which maintained a 
 list of all
 the expressions that generate runtime calls inside the 
 compiler... there's
 a hell of a lot of them!
 If you sift through druntime, the fact that this code is such a 
 mess is a
 really good indicator of some core language deficits. All these 
 things
 handle SO MANY CASES.
 A lot of it will resolve with move semantics and the proper 
 emplace
 expression that Walter's working... the rest of it, I dunno.
 Like, look at `template _arrayOp(Args...)`, that's pretty wild 
 stuff!


Yes, that or, compiler hooks go in `core.internal.hooks` or 
something like that.

I think we should focus on that once all the hooks-to-template 
work is done.

-Steve
Nov 15