The algorithm was not correctly detecting conflicts after moving
defaults into TypeVariableValue. The updated algorithm
correctly detects and reports conflicts with information about
where the conflict occured and which items the defaults were
introduced by. The span's for said items are not being correctly
attached and still need to be patched.
This patch allows type parameter defaults to influence type inference. This is a possible breaking change since it effects the way type inference works and will have different behavior when mixing defaults and literal fallback.
Instead of bar/baz, use valid/invalid as default methods. This
illustrates why you might want default methods, and shows that you can
call other trait methods from a default method.
Correct regression in type-inference caused by failing to reconfirm that
the object trait matches the required trait during trait selection. The
existing code was checking that the object trait WOULD match (in a
probe), but never executing the match outside of a probe.
This corrects various regressions observed in the wild, including
issue #26952. Fixes#26952.
r? @eddyb
cc @frankmcsherry
***Edit: Fixed now.*** I'm pretty sure the way I'm using LLVMReplaceAllUsesWith here is
unsafe... but before I figure out how to fix that, I'd like a
reality-check: is this actually useful?
This introduces a test for #23389 and improves the error behaviour to treat the malformed LHS as an error, not a compiler bug.
The parse phase that precedes the call to `check_lhs_nt_follows` could possibly be enhanced to police the format itself (which the old code suggests was the original intention), but I'm not sure that's any nicer than just parsing the matcher as generic rust code and then policing the specific requirements for being a macro matcher afterwards (as this does).
Fixes#23389
If they are ordered v0, v2, v1, v3, the compiler can find just a few
simd optimizations itself.
The new optimization I could observe on x86-64 was using 128 bit
registers for the v = key ^ constant operations in new / reset.
Use `ptr::copy_nonoverlapping` (aka memcpy) to load an u64 from the
byte stream. This is correct for any alignment, and the compiler will
use the appropriate instruction to load the data.
Use unchecked indexing.
This results in a large improvement of throughput (hashed bytes
/ second) for long data. Maximum improvement benches at a 70% increase
in throughput for large values (> 256 bytes) but already values of 16
bytes or larger improve.
Introducing unchecked indexing is motivated to reach as good throughput
as possible. Using ptr::copy_nonoverlapping without unchecked indexing
would land the improvement some 20-30 pct units lower.
We use a debug assertion so that the test suite checks our use of
unchecked indexing.
The borrow checker doesn't allow constructing such a type at runtime
using safe code, but there isn't any reason to ban them in the type checker.
Included in this commit is an example of a neat static doubly-linked list.
Feature-gated under the static_recursion gate to be on the safe side, but
there are unlikely to be any reasons this shouldn't be turned on by
default.
I'll be adding more commits to this PR as the weekend progresses. Was hoping to make this a mega-PR, but getting some eyes on this early would be nice too.
r? @steveklabnik
r? @eddyb on the object safety bits
cc @michaelsproul
Part of #24407
This fixes a few soundness bugs in dropck, so to anyone who relied on them,
this is a
[breaking-change]
Fixes#24086.
Fixes#25389.
Fixes#25598.
Fixes#25750.
Fixes#26641.
Fixes#26657.
Fixes#27240.
Fixes#27241.
Hi all.
This is my first contribution to Rust and fixes an issue causing an invalid error message to be presented to the user when using unit struct as length of a repeat expression, issue #27008. The solution is based on suggestions by @oli-obk, but as I'm a complete newbie to this, I have no clue if I got them right :)
The biggest concern I have is that if the `NodeId` I'm returning is the correct one or not (it's not meaningful in this case but I think it would be nice to get it right).
As title!
I should probably be bunching these up a bit more, but I'm not sure when my time is going to disappear on me. Once my schedule stabilises I'll try to start batching them into larger PRs.
Part of #24407.
r? @Manishearth
