Our great sponsors
-
-
chalk
An implementation and definition of the Rust trait system using a PROLOG-like logic solver (by rust-lang)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
There are a number of issues in rustc that are considered acceptable (to some degree), or less pressing, to those maintianers, that may not be considered acceptable to all implementors. One is the TypeId collision issue that is currently P-low, despite being I-unsound (https://github.com/rust-lang/rust/issues/10389). Different implementations may have different priorities in these kinds of bugs, and different users may find different cases more or less acceptable. While this is not a stated goal of gcc-rs, one of my goals in lccc to to fix as many of the known soundness bugs in rustc, even where they are considered non-issues. ABI was just a specific example I had relatively recent issues with.
Thus I believe RustBelt and chalk/polonius/miri are far better at specifying the language and validating the specification than a competing compiler implementation. This is something I should have addressed in my original post, but forgot.
Thus I believe RustBelt and chalk/polonius/miri are far better at specifying the language and validating the specification than a competing compiler implementation. This is something I should have addressed in my original post, but forgot.
In the case of the abi to be provided by lccc, as I say, it is to mitigate issues with proc-macro crates (where I have to cross from Rust to C++). Additionally, it ensures code need not be recompiled between versions of lccc, something that is very annoying when I work on rust projects as I upgrade rustc versions frequently. Note that the abi isn't entirely stable, IE. can never be broken. Rather it's designed so that it can be upgraded, to implement new layout optimizations, fix bugs, or comply with new guarantees from the language, and a new version can be released. In the case of the abi desired for use in lccc, the entire architecture of lccc depends upon a complicated system that requires dynamic dispatch, is sufficiently complicated that writing a C api for it would be significant extra work (the header that declares it, https://github.com/LightningCreations/lccc/blob/main/xlang/include/xlang%2B%2B/Visit.hpp, is currently 832 lines of C++), and can operate between discretely compiled shared object files, loaded at runtime. I had actually brought a feature request, last summer, that would have been sufficient for that use, however it was postponed for an understandable reason (https://github.com/rust-lang/rfcs/pull/2955).
Thus I believe RustBelt and chalk/polonius/miri are far better at specifying the language and validating the specification than a competing compiler implementation. This is something I should have addressed in my original post, but forgot.
If you wondered why Boost headers look like hell that's because once your library ends up being popular, you're kinda stuck supporting quirky compilers -- either yourself, or accepting patches for it.
I'm not saying it doesn't have a legitimate reason for being low priority, I'm just saying that, with the capability of implementing a fix myself, I think it's reasonable to at least attempt to do so (and, I did, in fact, https://github.com/LightningCreations/lccc/blob/main/rust/libcore/src/any.rs, though this is pending on the relevent https://github.com/rust-lang/rust/issues/84391).