Consider supporting `@_transparent`

Just noting for consideration Apple Swift’s @_transparent attribute.

In Apple Swift it is a stdlib only attribute for “treat this operation as if it were a primitive operation”, despite being implemented in Swift.

It is even partially documented. :wink:

What’s the use case for this?

My selfish reason is so that I don’t have to comment it out to see what other parts of the Apple Swift stdlib Silver doesn’t support.

It is primarily used for things which Apple wants actual declarations to exist for in the Swift stdlib, but are just wrappers for LLVM intrinsics or would be “really weird” for a debugger to decompose.

Some examples of what the Apple Swift stdlib uses @_transparent for:

  • the conversions between LLVM types and the stdlib wrappers
    e.g. Builtin.Int1 and Bool, and Builtin.IntN and [U]IntN,
    and all of the Pointer types
  • assert calls
  • range construction operators
  • ‘obvious’ compositions of such things
    e.g. Bool and [U]IntN's == and != implementations

You could just define a dummy attribute/aspect yourself, for now, then?

I seem to recall that I read in some documentation that custom attributes were only supported when targeting .NET, and .NET has the restriction on argument labels on constructors.

If not, that would likely work.

I believe we lifted that restriction; I’ll have to check. What platform do you work on? Island or Toffee?

I believe that’s now fixed/worked around?

I am currently using an Island target.

I haven’t checked.

I haven’t even done anything with Elements for a few months, submitting bugs to Elements is just a hobby activity for me, one that is a bit more intellectual than watching youtube.


However, I just added a .NET project with the “Class Library” template to my active solution with the name “Aspects”, and Fire version .2513 crashed, and keeps crashing when I open it, soon after checking for updates.

However, this should probably be a new thread?

:joy:

Curious can you retest this with 2523; 2513 isbfive weeks old at this stage and we changed a lot of things. Can you also send me the crash report and (if possible) the solution?

No, the preview channel subscription you gave me last year expired, so I only have access to the stable channel.

Where would I find the crash reports? It isn’t popping up the “[App] Unexpectedly closed” that sometimes pops up for crashes.

Hmm, what happens then? It just goes away? Any logs showing in Console.app?[quote=“dbroggi, post:9, topic:22302”]
No, the preview channel subscription you gave me last year expired, so I only have access to the stable channel.
[/quote]

Ah, I’ll send you a new build tomorrow, then.

After I force quit it (before it crashed) to keep it from reopening the solution automatically, it:
launches, I select the solution from the open recents, it opens the primary window and ~1 second later it closes.

This contains a copy from Console restricted to the Fire process:
Fire.log.txt (10.1 KB)

The last available version is 2521, no new build last friday!

Oops, my apologies, it looks like the cache didn’t get cleared so the new build did not show up; I didn’t notice because for once I was off the computer most of the weekend ;).

Fixed, and 2523 should be available now.

Nothing actionable in there,e unfortunately :(.

I’m uploading .2523 to your Personal Downloads page.

.2523 doesn’t fix it, unfortunately.

Here is another Console log, with Debug and Info logging enabled this time:
Fire.log.txt (1.2 MB)

:(. nothing helpful, I’m afraid. Can I see this solution, via PM?