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
Currently, for `use` declarations with multiple paths, only the `use`
item itself is saved in the AST map, not the individual path nodes. This
can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in
`ImportResolver::check_for_conflicting_import()`.
Fixes#25763.
Currently, there are two conditional blocks that exist to check for "clang or gcc"
On line 866:
```
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
and on line 1019:
```
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
err "either clang or gcc is required"
fi
```
Given the order of the clauses, this results in the "either clang or gcc is required" error from the earlier block, (even) when CC is set.
The expected behaviour is to honour user-flags, in this case CC.
Aside from removing all hand-holdy compiler checks in favour of actual compiler *feature* checks, this change removes the redundant former block in favour of the latter block, which appears designed to allow the expected behaviour.
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.
