Needed to support:
```rust
match X {
pattern if Y ...
}
for pattern in Y {}
```
IMO, this shouldn't require an RFC because it can't interfere with any future language changes (because `pattern if` and `pattern in` are already legal in rust) and can't cause any ambiguity.
- Adds explanations for E0055, E0089, E0192, E0261-E0263, E0318
- Improves explanations for E0250, E0368, E0372.
- Converts 15 diagnostics to have error codes (E0380-E0394). Adds an explanation for E0380.
- The E0087-E0090 messages currently look like "expected {} parameter(s) found {} parameter(s)". This changes them to either use "parameter" or "parameters", based on the number.
This is, in part, more progress towards #24407
rustdoc: Associated type fixes
The first commit fixes a bug with "dud" items in the search index from
misrepresented `type` items in trait impl blocks.
For a trait *implementation* there are typedefs which are the types for
that particular trait and implementor. Skip these in the search index.
There were lots of dud items in the search index due to this (search for
Item, Iterator's associated type).
Add a boolean to clean::TypedefItem so that it tracks whether the it is
a type alias on its own, or if it's a `type` item in a trait impl.
The second commit fixes a bug that made signatures and where bounds
using associated types (if they were not on `Self`) incorrect.
The third commit fixes so that where clauses in type alias definititons
are shown.
Fixes#22442Fixes#24417Fixes#25769
Changes:
- adds explanations for E0185, E0186, E0202, E0326
- fixes the explanation for E0053. The previous description was too narrow; there are other error cases.
- changes the error message for E0202 to be specific for associated types, since it seems inherent associated constants are implemented.
Part of #24407
Closes#25046 (by rejecting the code that causes the ICE) and #24946. I haven't been able to deal with the array size or recursion issues yet for associated consts, though my hope was that the change I made for range match patterns might help with array sizes, too.
This PR is pretty much orthogonal to #25065.
This flag indicates that when files are being replaced or added to archives (the
`r` flag) that the new file should not be inserted if it is not newer than the
file that already exists in the archive. The compiler never actually has a use
case of *not* wanting to insert a file because it already exists, and this
causes rlibs to not be updated in some cases when the compiler was re-run too
quickly.
Closes#18913
This flag indicates that when files are being replaced or added to archives (the
`r` flag) that the new file should not be inserted if it is not newer than the
file that already exists in the archive. The compiler never actually has a use
case of *not* wanting to insert a file because it already exists, and this
causes rlibs to not be updated in some cases when the compiler was re-run too
quickly.
Closes#18913
The caching essentially eliminates "stability checking" time (my attempt to clean-up junk got tangled up with stability, so I added the caching while I was at it).
r? @eddyb
A regression was introduced by commit 7b1916d253#25612. Negative signed integer literals less than -9223372036854775808i64 were no longer properly reported as #[warn(overflowing_literals)].
Also adding missing test cases to test/compile-fail/lint-type-overflow.rs which could have detected the regression.
Further explanation:
The expression `(negative && v > max as u64 + 1)` relies on the fact that algebraically speaking `-min == max + 1` to avoid negation and removing the need for `min` completely.
If i128 or i256 are ever added, it should also work for these types without requiring a change to `min != i64::MIN &&` also simplifying maintenance.
r? @pnkfelix
In all other places the IDs of link references are without spaces (and explicitly set).
These are just some cleanups I did for the PDF version.
r? @steveklabnik
I'm not sure why `core` is on but it's blocking the playpen. Doesn't seem to be needed but I'm not sure. It's not on the playpen template and playpen works on release and nightly.
Seems easier to understand without `take()`.
A few of us [over on the forum](https://users.rust-lang.org/t/string-type-coercion-in-rust/1439) have been tripped up by this distinction, which I don't think is mentioned. It's kind of logical if you read the "Deref coercions" page and squint a bit but I think it would be nice to explain it directly. Here's one way we could clarify it.
Functions such as `fn foo<I: Iterator>(x: I::Item)` would not
render correctly and displayed `I` instead of `I::Item`. Same thing
with `I::Item` appearing in where bounds.
This fixes the bug by using paths for generics.
Fixes#24417
Typo in explanation of difference between stack and heap values.
`baz` is called at the end of a call to `bar` inside another call to `foo`. `baz` takes a copy of the value `e` which should have a value of 9 if following the rest of the stack trace.
This PR fixes this typo and should close#25635.
This is a port of @eddyb's `const-fn` branch. I rebased it, tweaked a few things, and added tests as well as a feature gate. The set of tests is still pretty rudimentary, I'd appreciate suggestions on new tests to write. Also, a double-check that the feature-gate covers all necessary cases.
One question: currently, the feature-gate allows the *use* of const functions from stable code, just not the definition. This seems to fit our usual strategy, and implies that we might (perhaps) allow some constant functions in libstd someday, even before stabilizing const-fn, if we were willing to commit to the existence of const fns but found some details of their impl unsatisfactory.
r? @pnkfelix
