Impls on `clean::Type::FixedVector` are now collected in the array
primitive page instead of the slice primitive page.
Also add a primitive docs for arrays to `std`.
impls.
This requires:
1. modifying trait selection a bit so that when we synthesize impls for
fn pointers and closures;
2. adding code to trans so that we can synthesize a `FnMut`/`FnOnce`
impl for a `Fn` closure and so forth.
This commit implements [RFC
909](https://github.com/rust-lang/rfcs/pull/909):
The `std::thread_local` module is now deprecated, and its contents are
available directly in `std::thread` as `LocalKey`, `LocalKeyState`, and
`ScopedKey`.
The macros remain exactly as they were, which means little if any code
should break. Nevertheless, this is technically a:
[breaking-change]
Closes#23547
This small commit stabilizes the `Error` trait as-is, except that `Send`
and `Debug` are added as constraints. The `Send` constraint is because
most uses of `Error` will be for trait objects, and by default we would
like these objects to be transferrable between threads. The `Debug`
constraint is to ensure that e.g. `Box<Error>` is `Debug`, and because
types that implement `Display` should certainly implement `Debug` in any case.
In the near future we expect to add `Any`-like downcasting features to
`Error`, but this is waiting on some additional
mechanisms (`Reflect`). It will be added before 1.0 via default methods.
[breaking-change]
The new `relative_from` method no longer supports the case on unix
where both paths are absolute, which `-C rpath` depended on. This
version fixes the problem by copying the old path_relative_from
function into the rpath module.
Fixes#23140
contains ref-bindings, do not permit any upcasting from the type of
the value being matched. Similarly, do not permit coercion in a `let`.
This is a [breaking-change] in that it closes a type hole that
previously existed, and in that coercion is not performed. You should
be able to work around the latter by converting:
```rust
let ref mut x: T = expr;
```
into
```rust
let x: T = expr;
let ref mut x = x;
```
Restricting coercion not to apply in the case of `let ref` or `let ref mut` is sort
of unexciting to me, but seems the best solution:
1. Mixing coercion and `let ref` or `let ref mut` is a bit odd, because you are taking
the address of a (coerced) temporary, but only sometimes. It's not syntactically evident,
in other words, what's going on. When you're doing a coercion, you're kind of
2. Put another way, I would like to preserve the relationship that
`equality <= subtyping <= coercion <= as-coercion`, where this is
an indication of the number of `(T1,T2)` pairs that are accepted by
the various relations. Trying to mix `let ref mut` and coercion
would create another kind of relation that is like coercion, but
acts differently in the case where a precise match is needed.
3. In any case, this is strictly more conservative than what we had
before and we can undo it in the future if we find a way to make
coercion mix with type equality.
The change to match I feel ok about but similarly unthrilled. There is
some subtle text already concerning whether to use eqtype or subtype
for identifier bindings. The best fix I think would be to always have
match use strict equality but use subtyping on identifier bindings,
but the comment `(*)` explains why that's not working at the moment.
As above, I think we can change this as we clean up the code there.
Linking __pthread_get_minstack, even weakly, was causing Debian’s
dpkg-shlibdeps to detect an unnecessarily strict versioned dependency
on libc6.
Closes#23628.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Boolean values and small aggregates have a different type in args/allocas than
in SSA values but the intrinsics for volatile and atomic ops were
missing the necessary casts to handle that.
Fixes#23550
This commit removes the `IndexMut` impls on `HashMap` and `BTreeMap`, in
order to future-proof the API against the eventual inclusion of an
`IndexSet` trait.
Ideally, we would eventually be able to support:
```rust
map[owned_key] = val;
map[borrowed_key].mutating_method(arguments);
&mut map[borrowed_key];
```
but to keep the design space as unconstrained as possible, we do not
currently want to support `IndexMut`, in case some other strategy will
eventually be needed.
Code currently using mutating index notation can use `get_mut` instead.
[breaking-change]
Closes#23448
r? @Gankro
For the rust-call ABI, the last function argument is a tuple that gets
untupled for the actual call. For bare functions using this ABI, the
code has access to the tuple, so we need to tuple the arguments again.
But closures can't actually access the tuple. Their arguments map to the
elements in the tuple. So what we currently do is to tuple the arguments
and then immediately untuple them again, which is pretty useless and we
can just omit it.
After this patch code like `let ref a = *"abcdef"` doesn't cause ICE anymore.
Required for #23121
There are still places in rustc_trans where pointers are always assumed to be thin. In particular, #19064 is not resolved by this patch.
