Expose LLVM types #5727
Comments
|
I can easily see arguments for including i1, i128, and f128 as first-class types in Rust, but what other types are there (more specifically than "vectors")? Does this request change in light of the SIMD support that landed in #6214? |
|
LLVM allows arbitrarily-sized integer types so the only limit is what makes sense to expose, based on hardware support. |
|
It does somewhat change in the light of SIMD (and packed structs), since that means that the most pressing types that were missing are now supported. (i128 and f128 are mostly a curiosity imho.) But at the time the idea was to implement something like and then you could get some types that you could otherwise not access (and likely never will be able to access otherwise), like the MIPS DSP ASE type v2q15, or x86mmx. Ps. Feel free to close nofix, if it is a bad idea. |
|
As I understand the proposal, using these types would require either
Nominating for "far future" milestone. (That, or close as "nofix"; I don't have a preference.) |
|
There are already intrinsics operating on the weird SIMD and accumulator types, we just cannot call them since we don't support the types. (Unlike iN and f128 etc., which would need actual code generator support, but yes, "far future" is the only milestone that makes sense) |
|
As-proposed, I think most of the moz folks are against this (discussing in triage meeting); SIMD of course needs support and it's reasonable to assume f128 and i128 will show up as new suffixes/literals and types in the prelude at some point. Otherwise I think not: it's too much tying the language to LLVM. Closing WONTFIX. |
…r=flip1995 Expands `manual_memcpy` to lint ones with loop counters Closes rust-lang#1670 This PR expands `manual_memcpy` to lint ones with loop counters as described in rust-lang/rust-clippy#1670 (comment) Although the current code is working, I have a couple of questions and concerns. ~~Firstly, I manually implemented `Clone` for `Sugg` because `AssocOp` lacks `Clone`. As `AssocOp` only holds an enum, which is `Copy`, as a value, it seems `AssocOp` can be `Clone`; but, I was not sure where to ask it. Should I make a PR to `rustc`?~~ The [PR]( rust-lang#73629) was made. Secondly, manual copying with loop counters are likely to trigger `needless_range_loop` and `explicit_counter_loop` along with `manual_memcpy`; in fact, I explicitly allowed them in the tests. Is there any way to disable these two lints when a code triggers `manual_memcpy`? And, another thing I'd like to note is that `Sugg` adds unnecessary parentheses when expressions with parentheses passed to its `hir` function, as seen here: ``` error: it looks like you're manually copying between slices --> $DIR/manual_memcpy.rs:145:14 | LL | for i in 3..(3 + src.len()) { | ^^^^^^^^^^^^^^^^^^ help: try replacing the loop by: `dst[3..((3 + src.len()))].clone_from_slice(&src[..((3 + src.len()) - 3)]) ``` However, using the `hir` function is needed to prevent the suggestion causing errors when users use bitwise operations; and also this have already existed, for example: `verbose_bit_mask`. Thus, I think this is fine. changelog: Expands `manual_memcpy` to lint ones with loop counters
This might not be a super idea, but It would be really cool and useful in some cases to be able to expose LLVM types like i1, i128, fp128, vectors <16 x i8> etc. to rust, mainly to interface with LLVM intrinsics that take these types as parameters, but also to implement SIMD in Rust.
I don't know how this would be implemented, but it doesn't really matter if it is ugly since only library code would ever need it (probably.)
The text was updated successfully, but these errors were encountered: