| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
I don't see why MC should fail on well-formed code, so it might be a
better idea to just add a `delay_span_bug` there (anyone remember the
`cat_expr Errd` bug from the 1.0 days?).
However, I don't think this is a good idea to backport a new delay_span_bug
into stable and this code is going away soon-ish anyway.
|
|
This looks like a typo introduced in #51686.
Fixes #52213.
|
|
|
|
CVE number has not yet been assigned, patch made by steveklabnik.
|
|
|
|
|
|
|
|
|
|
- rust-lang/cargo#5577 - revert rust-lang/cargo#5461 (Support crate renames in `cargo metadata`)
- rust-lang/cargo#5567 - Copy `--all-features` request to all workspace members
|
|
|
|
|
|
|
|
This reverts commit d6ba1b9b021c408fcad60ee52acf8af5e1b2eb00, reversing
changes made to 8de5353f75dcde04abe947e0560dc5edd861cf3a.
|
|
If a struct pattern has a field error return an error.
|
|
`PointerKind` is included in `LoanPath` and hence forms part of the
equality check; this led to having two unequal paths that both
represent `*x`, depending on whether the `*` was inserted
automatically or explicitly. Bad mojo. The `note` field, in contrast,
is intended more-or-less primarily for this purpose of adding extra
data.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
behavior when NaN is involved.
|
|
|
|
|
|
|
|
|
|
Fixes #50595.
This bug currently affects stable. Why I think we can go for hard error:
- It will in stable for at most one cycle and there is no legitimate
reason to abuse it, nor any known uses in the wild.
- It only affects `bin` crates (which have a `main`), so there is
little practical difference between a hard error or a deny lint, both
are a one line fix.
The fix was to just unshadow a variable. Thanks @nikomatsakis for the
mentoring!
r? @nikomatsakis
|
|
|
|
|
|
|
|
A high impact bug because a lot of common traits use a `Self`
substitution by default. Should be backported to beta.
There was a check for this which wasn't catching all cases, it was made
more robust.
Fixes #49376
Fixes #50626
r? @petrochenkov
|
|
https://github.com/rust-lang-nursery/stdsimd/commit/a19ca1cd91cf97777af8268a6136bd2e4648e189
|
|
|
|
Save the index of all fields regardless of their visibility. Problems
could occur later when attempting to index fields in error recovery if
they are not inserted.
|
|
We use a new MemFlags bitflags type to merge some store code paths.
|
|
Fixes #50371.
|
|
[beta] Process backports
* #50622: rustc: leave space for fields of uninhabited types to allow partial initialization.
* #50643: typeck: Fix ICE with struct update syntax
r? @alexcrichton
|
|
If check_expr_struct_fields fails, do not continue to record update.
If we continue to record update, the struct may cause us to ICE later
on indexing a field that may or may not exist.
|
|
initialization.
|
|
Regression fixes:
- rust-lang/cargo#5510 `cargo rustc` broken for tests in project with bins
- rust-lang/cargo#5523 (#50640) shared proc-macro dependency built incorrectly
|
|
This commit is spawned out of a performance regression investigation in #50496.
In tracking down this regression it turned out that the `expand_statements`
function in the compiler was taking quite a long time. Further investigation
showed two key properties:
* The function was "fast" on glibc 2.24 and slow on glibc 2.23
* The hottest function was memmove from glibc
Combined together it looked like glibc gained an optimization to the memmove
function in 2.24. Ideally we don't want to rely on this optimization, so I
wanted to dig further to see what was happening.
The hottest part of `expand_statements` was `Drop for Drain` in the call to
`splice` where we insert new statements into the original vector. This *should*
be a cheap operation because we're draining and replacing iterators of the exact
same length, but under the hood memmove was being called a lot, causing a
slowdown on glibc 2.23.
It turns out that at least one of the optimizations in glibc 2.24 was that
`memmove` where the src/dst are equal becomes much faster. [This program][prog]
executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24, exhibiting
how glibc 2.24 is optimizing `memmove` if the src/dst are equal.
And all that brings us to what this commit itself is doing. The change here is
purely to `Drop for Drain` to avoid the call to `ptr::copy` if the region being
copied doesn't actually need to be copied. For normal usage of just `Drain`
itself this check isn't really necessary, but because `Splice` internally
contains `Drain` this provides a nice speed boost on glibc 2.23. Overall this
should fix the regression seen in #50496 on glibc 2.23 and also fix the
regression on Windows where `memmove` looks to not have this optimization.
Note that the way `splice` was called in `expand_statements` would cause a
quadratic number of elements to be copied via `memmove` which is likely why the
tuple-stress benchmark showed such a severe regression.
Closes #50496
[prog]: https://gist.github.com/alexcrichton/c05bc51c6771bba5ae5b57561a6c1cd3
|
|
[beta] Prepare the 1.27.0 beta release
This commit prepares the 1.27.0 beta release by doing:
* Update the release channel to `beta`
* Update Cargo's submodule
* Update `stdsimd`'s submodule
* Update the bootstrap compiler to the freshly minted 1.26.0 stable release
|
|
This commit prepares the 1.27.0 beta release by doing:
* Update the release channel to `beta`
* Update Cargo's submodule
* Update `stdsimd`'s submodule
* Update the bootstrap compiler to the freshly minted 1.26.0 stable release
* Don't attempt to verify clippy/miri build
|
|
Prevent infinite recursion of modules
Fixes #50196.
r? @QuietMisdreavus
|
|
Various edition preview fixes
Implement a bunch of things discussed in the meeting.
|
|
Use ManuallyDrop instead of Option in BinaryHeap Hole implementation
The Option is always Some until drop, where it becomes None. Make this more explicit and avoid unwraps by using ManuallyDrop.
This change should be performance-neutral as LLVM already optimizes the unwraps away in the inlined code. However I've seen this pattern copied from here to other crates where it is not optimized away, so I think it would be good to change it.
|
