Properly detect overflow in Instance ± Duration.
Fix#44216.
Fix#42622
The computation `Instant::now() + Duration::from_secs(u64::max_value())` now panics. The call `receiver.recv_timeout(Duration::from_secs(u64::max_value()))`, which involves such time addition, will also panic.
The reason #44216 arises is because of an unchecked cast from `u64` to `i64`, making the duration equivalent to -1 second.
Note that the current implementation is over-conservative, since e.g. (-2⁶²) + (2⁶³) is perfectly fine for an `i64`, yet this is rejected because (2⁶³) overflows the `i64`.
Extend E0623 for LateBound and EarlyBound Regions
This is a fix for #43882
```
fn foo<'a,'b>(x: &mut Vec<&'a u8>, y: &'b u8) {
x.push(y);
}
```
now gives
```
error[E0623]: lifetime mismatch
--> $DIR/ex3-both-anon-regions-latebound-regions.rs:12:12
|
11 | fn foo<'a,'b>(x: &mut Vec<&'a u8>, y: &'b u8) {
| ------ ------ these two types are declared with different lifetimes...
12 | x.push(y);
| ^ ...but data from `y` flows into `x` here
```
cc @nikomatsakis @arielb1
Please ignore the second commit. It will be merged in a separate PR.
std:🧵:LocalKey: Document limitation with initializers
Document that if a `LocalKey`'s initializer recursively depends on itself, initialization will result in infinite recursion.
Use memalign instead of posix_memalign for Solaris
As pointed out in https://github.com/rust-lang/libc/commit/deb61c8,
Solaris 10 does not support posix_memalign.
Use memalign for all Solaris versions instead.
With this change applied I am able to cross-build rustc for Solaris 10.
Expect pipe symbol after closure parameter list
Fixes#44021.
---
Originally, the parser just called `bump` to discard following token after parsing closure parameter list, because it assumes `|` is following. However, the following code breaks the assumption:
```rust
struct MyStruct;
impl MyStruct {
fn f() {|x, y}
}
```
Here, the parameter list is `x, y` and the following token is `}`. The parser discards `}`, and then we have a curly bracket mismatch.
Indeed, this code has a syntax error. On current nightly, the compiler emits an syntax error, but with incorrect message and span, followed by an ICE.
```
error: expected expression, found `}`
--> 44021.rs:4:1
|
4 | }
| ^
error: internal compiler error: unexpected panic
```
Even worse, on current stable(1.20.0), the compiler falls into an infinite loop.
This pull request fixes this problem. Now the compiler emits correct error message and span, and does not ICE.
```
error: expected one of `:`, `@`, or `|`, found `}`
--> 44021.rs:3:20
|
3 | fn foo() {|x, y}
| ^ expected one of `:`, `@`, or `|` here
```
rustc: Separately feature gate repr(i128)
Brought up during the discussion of #35118, the support for this is still
somewhat buggy and so stabilization likely wants to be considered independently
of the type itself.
Use rvalue promotion to 'static instead of static items.
Fixes#44240. Among other things, in crates that do a lot of formatting, this could reduce the number of items, although I haven't measured the performance benefits. If there's a codegen slowdown, that should IMO be solved by caching the output of miri, *not* by using `static`.
r? @alexcrichton
rustc: Remove `DepGraph` handling from rustc_metadata
This should now be entirely tracked through queries, so no need to have a
`DepGraph` in the `CStore` object any more!
cc #44390
rustbuild: Switch back to using hard links
The `copy` function historically in rustbuild used hard links to speed up the
copy operations that it does. This logic was backed out, however, in #39518 due
to a bug that only showed up on Windows, described in #39504. The cause
described in #39504 happened because Cargo, on a fresh build, would overwrite
the previous artifacts with new hard links that Cargo itself manages.
This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer
should overwrite files on fresh builds, opportunistically leaving the filesystem
intact and not touching it.
Hopefully this can help speed up local builds by doing fewer copies all over the
place!
The `copy` function historically in rustbuild used hard links to speed up the
copy operations that it does. This logic was backed out, however, in #39518 due
to a bug that only showed up on Windows, described in #39504. The cause
described in #39504 happened because Cargo, on a fresh build, would overwrite
the previous artifacts with new hard links that Cargo itself manages.
This behavior in Cargo was fixed in rust-lang/cargo#4390 where it no longer
should overwrite files on fresh builds, opportunistically leaving the filesystem
intact and not touching it.
Hopefully this can help speed up local builds by doing fewer copies all over the
place!
Add libbacktrace support for Apple platforms (resubmitted)
Resubmitting #43422 rebased on the current master (cc @JohnColanduoni).
I have added an additional commit to fallback to `dladdr`-based `resolve_symbol` if `libbacktrace` returns `None`, otherwise the stack trace will be full of `<unknown>` when you forget to pass the `-g` flag (actually it seems — at least on macOS — the `dladdr` symbol is more accurate than the `libbacktrace` one).
Allow Drop types in const's too, with #![feature(drop_types_in_const)].
Implements the remaining amendment, see #33156. cc @SergioBenitez
r? @nikomatsakis
Avoid hashing when creating a DepNode from a HirId
Instead, combine the already-present DefPathHash with the 32-bit
ItemLocalIndex.
Should fix#44323.
r? @alexcrichton
limit and clear cache obligations opportunistically
Keeping **all** the obligations for every projection is wasteful of
memory and compilation time. We only really care about those
subobligations that may inform the result of the projection (i.e., may
help to resolve any inference variables that appear within).
Therefore, we can clear the subobligations from the cache that don't
potentially affect the result of the projection. On every cache hit,
we also take the opportunity to check if the type variables have been
resolved *yet* and, if so, clear out the pending obligations.
Fixes#43613.
r? @arielb1
NB -- not sure how to test for this. Probably we should add the #43613 test case to perf.
