Redefine the pluralize macro's arm
Redefine the unintuitive pluralize macro's arm because of the negation. The initial code starts with check if count is not 1, which is confusing and unintuitive.
The arm shoud start with checking,
- if "count" `is 1` then, append `""` (empty string) - indicate as singular
- Then check if "count" `is not 1` (more than 1), append `"s"` - indicate as plural
Before:
```rs
// This arm is abit confusing since it start with checking, if "count" is more than 1, append "s".
($x:expr) => {
if $x != 1 { "s" } else { "" }
};
```
After:
```rs
// Pluralize based on count (e.g., apples)
($x:expr) => {
if $x == 1 { "" } else { "s" }
};
```
Remove myself from review rotation
I'll.. still be around, just not as active as I had been. I'm not adding myself to `users_on_vacation`, because anyone should still feel free to r? me if they want a specific review from me.
Reassign sparc-unknown-none-elf to tier 3
It should never have been moved to tier 2. It is a new platform and the maintainer has agreed to do tier 3 maintenance for it, not tier 2.
r? `@jonathanpallant`
Fix table issues in platform support documentation (closes#115047)
mdBook needs an empty line before and after the table block.
In addition, in the tier-3 list three targets forgot about the host column and therefore showed the notes in the host column.
Closes#115047
Add `suggestion` for some `#[deprecated]` items
Consider code:
```rust
fn main() {
let _ = ["a", "b"].connect(" ");
}
```
Currently it shows deprecated warning:
```rust
warning: use of deprecated method `std::slice::<impl [T]>::connect`: renamed to join
--> src/main.rs:2:24
|
2 | let _ = ["a", "b"].connect(" ");
| ^^^^^^^
|
= note: `#[warn(deprecated)]` on by default
```
This PR adds `suggestion` for `connect` and some other deprecated items, so the warning will be changed to this:
```rust
warning: use of deprecated method `std::slice::<impl [T]>::connect`: renamed to join
--> src/main.rs:2:24
|
2 | let _ = ["a", "b"].connect(" ");
| ^^^^^^^
|
= note: `#[warn(deprecated)]` on by default
help: replace the use of the deprecated method
|
2 | let _ = ["a", "b"].join(" ");
| ^^^^
```
Add projection obligations when comparing impl too
Fixes#115033
In the test, when we ask for WF obligations of `DatasetIter<'a, ArrayBase<D>>`, we get back two important obligations: `[<D as Data>::Elem -> ?1, ?1: 'a]`. If we don't add the projection obligation, `?1` remains unconstrained.
An alternative solution would be to use unnormalized obligations, where we only have one relevant obligation: `<D as Data>::Elem: 'a`. This would leave no inference vars unconstrained.
fix help text for rust-analyzer.check.invocation{Strategy,Location}
I highly doubt that `check.invocationLocation` only has an effect if `cargo.buildScripts.overrideCommand` is set -- looks like a copy-paste mistake from `buildScripts.invocationLocation` to me.
feat: Implement extern crate completion
Hi, this is a draft PR for #13002.
I have basic completion working as well as a filter for existing extern crate imports in the same file. This is based on the tests, I have not actually tried this in an editor. Before going further I think this is a good point to stop and get feedback on the
structure and approach I have taken so far. Let me know what you think :)
I will make sure to add more tests, rebase commits and align with the code style guidelines before submitting a final version.
A few specific questions :
1. Is there a better way to check for matching suggestions? right now I just test if an extern crate name starts with the current
user input.
2. Am I creating the `CompletionItem` correctly? I noticed that `use_.rs` invokes a builder where as I do not.
3. When checking for existing extern crate imports the current implementation only looks at the current source file, is that sufficient?
Remove apple-alt dist build.
This removes the dist-x86_64-apple-alt build to reduce CI usage because I suspect nobody is using it. This builder is almost identical to the `dist-x86_64-apple` with the small difference that the latter adds `rust.lto=thin`, and I do not think that difference was intentional. The reason they are identical is because llvm assertions were disabled in #44610, but I did not see any discussion about the consequence that this made the alt build identical to the normal build. Perhaps because #44610 was intended to be temporary?
