Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More ergonomic multiple-data expressions. #12917

Closed

Conversation

DiamondLovesYou
Copy link
Contributor

The gist:

#[phase(syntax)] extern crate simd_syntax;
extern crate simd;
use simd::{Simd, i32x8};
// Two new expressions, with inference:
let v = gather_simd!(1, 2, 3, 4);
let w = swizzle_simd!(v -> (3, 2, 1, 0));
let x: i32x8 = swizzle_simd!(v .. w -> (0, 7, 1, 6, 2, 5, 3, 4));
// multiple-data compare:
let cond = (x == gather_simd!(1, 1, 2, 2, 3, 3, 4, 4));
assert!(cond.every_true());

// New type (libsimd defines all the types anyone would realistically need,
// so most users won't need to use this):
def_type_simd!(pub type f32x4 = <f32, ..4>;)
def_type_simd!(pub struct i32x4(<i32, ..4>);)

I should emphasize that there are no parse changes in this PR; I choose to expose the ergonomics with a syntax extension so others can use a different syntax than the one provided in libsimd_syntax, hopefully without too much issue.

Pre-merge FIXME's (off the top of my head):

  • Moar tests.
  • Documentation.
  • Drop single instruction-ness in nomenclature. This feature makes no such guarantee anyway.
  • Transition to single expression w/ opcode.
  • Remove std::unstable::simd.
  • #[deriving] for single-element struct tuples wrapping multiple-data types.

I wouldn't call this ready to be merged; as per the FIXME's I've still got work to do. However, I'd very much like some feedback!

Richard Diamond added 2 commits March 14, 2014 19:04
 * ExprSimd - SIMD gather
 * ExprSwizzle - Two operand shuffle
Added ty_simd and a corresponding ty_infer type.
Added simd_syntax for accessing the new expressions as well as a
new crate providing basic multiple-data types and implementations.
@alexcrichton
Copy link
Member

This looks like a very large change to the compiler, and I'm not sure there has been much discussion on this topic.

For large changes such as this, we require an RFC in the rust-lang/rfcs repo. The first RFC explains the process of how to submit an RFC.

I don't mean to dissuade you from this work, it looks awesome! Discussion for a change such as this should start outside of a PR, however.

lnicola pushed a commit to lnicola/rust that referenced this pull request Jun 23, 2024
feat: show type bounds from containers when hovering on functions

fix rust-lang#12917.

### Changes

1. Added Support for displaying the container and type bounds from it when hovering on functions with generic types.
2. Added a user config to determine whether to display container bounds (enabled by default).
3. Added regression tests.
4. Simplified and refactored `hir/display.rs` to improve readability.
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jul 11, 2024
…ishearth

doc_lazy_continuation: blank comment line for gap

This change addresses cases where doc comments are separated by blank lines, comments, or non-doc-comment attributes, like this:

```rust
/// - first line
// not part of doc comment
/// second line
```

Before this commit, Clippy gave a pedantically-correct warning about how you needed to indent the second line. This is unlikely to be what the user intends, and has been described as a "false positive." Since Clippy is warning you about a highly unintuitive behavior [that Rustdoc actually has](https://notriddle.com/rustdoc-html-demo-11/lazy-continuation-bad/test_dingus_2024/constant.D.html), we definitely want it to output *something*, but the suggestion to indent was poor.

Fixes rust-lang#12917

```
changelog: [`doc_lazy_continuation`]: suggest blank line for likely-unintended lazy continuations
```
flip1995 pushed a commit to flip1995/rust that referenced this pull request Sep 5, 2024
…=dswij

Rewrite `empty_line_after_doc_comments` and `empty_line_after_outer_attr`, move them from `nursery` to `suspicious`

changelog: [`empty_line_after_doc_comments`], [`empty_line_after_outer_attr`]: rewrite and move them from `nursery` to `suspicious`

They now lint when there's a comment between the last attr/doc comment and the empty line, to cover the case:

```rust
/// Docs for `old_code
// fn old_code() {}

fn new_code() {}
```

When these lints or `suspicious_doc_comments` trigger we no longer trigger any other doc lint as a broad fix for rust-lang#12917, reverts some of rust-lang#13002 as the empty line lints cover it

I ended up not doing rust-lang/rust-clippy#12917 (comment) as I don't think it's needed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants