Clarify guarantees for `Box` allocation
This basically says `Box` does the obvious things for its allocations.
See also: https://users.rust-lang.org/t/alloc-crate-guarantees/24981
This may require a T-libs FCP? Not sure.
r? @sfackler
Update parking_lot to 0.7
Unfortunately this'll dupe parking_lot until the data_structures crate
is published and be updated in rls in conjunction with crossbeam-channel
Added a connection timeout and speed threshold when downloading the Docker cache
This is an attempt to fix one possible cause of #56112. Similar to #52846, this changed the download docker-cache command to fail if it cannot connect or falls below 10 bytes/s after 30 seconds, so it could be retried sooner.
Don't generate minification variables if minification disabled
If the minification is disabled, there is no sense having those variables.
r? @QuietMisdreavus
Allow Self::Module to be mutated.
This only changes `&Self::Module` to `&mut Self::Module` in a couple of places.
`codegen_allocator` and `write_metadata` from `ExtraBackendMethods` mutate the underlying LLVM module. As such, it makes sense for these two functions to receive a mutable reference to the module (as opposed to an immutable one).
I am trying to implement `codegen_allocator` for my backend, and I need to be able to mutate `Self::Module`:
f66e4697ae/src/librustc_codegen_ssa/traits/backend.rs (L41)
Modifying the module in `codegen_allocator`/`write_metadata` is not a problem for the LLVM backend, because [ModuleLlvm](https://github.com/rust-lang/rust/blob/master/src/librustc_codegen_llvm/lib.rs#L357) contains a raw pointer to the underlying LLVM module, so it can easily be mutated through FFI calls.
I am trying to avoid interior mutability and `unsafe` as much as I can. What do you think? Does this change make sense, or is there a reason why this should stay the way it is?
Turn duration consts into associated consts
As suggested in https://github.com/rust-lang/rust/issues/57391#issuecomment-459658236, I'm moving `Duration` constants (`SECOND`, `MILLISECOND` and so on; currently behind unstable `duration_constants` feature) into the `impl Duration` block.
cc @frewsxcv @SimonSapin
Special suggestion for illegal unicode curly quote pairs
Fixes#58436
Did not end up expanding the error message span to include the full string literal since I figured the start of the token was the issue, while the help suggestion span would include up to the closing quotation mark.
The look ahead logic does not affect the reader position, not sure if that is an issue (if eg it should still continue to parse after the closing quote without erroring out).
Remove `LazyTokenStream`.
`LazyTokenStream` was added in #40939. Perhaps it was an effective optimization then, but no longer. This PR removes it, making the code both simpler and faster.
r? @alexcrichton
RangeInclusive internal iteration performance improvement.
Specialize `Iterator::try_fold` and `DoubleEndedIterator::try_rfold` to improve code generation in all internal iteration scenarios.
This changes brings the performance of internal iteration with `RangeInclusive` on par with the performance of iteration with `Range`:
- Single conditional jump in hot loop,
- Unrolling and vectorization,
- And even Closed Form substitution.
Unfortunately, it only applies to internal iteration. Despite various attempts at stream-lining the implementation of `next` and `next_back`, LLVM has stubbornly refused to optimize external iteration appropriately, leaving me with a choice between:
- The current implementation, for which Closed Form substitution is performed, but which uses 2 conditional jumps in the hot loop when optimization fail.
- An implementation using a `is_done` boolean, which uses 1 conditional jump in the hot loop when optimization fail, allowing unrolling and vectorization, but for which Closed Form substitution fails.
In the absence of any conclusive evidence as to which usecase matters most, and with no assurance that the lack of Closed Form substitution is not indicative of other optimizations being foiled, there is no way
to pick one implementation over the other, and thus I defer to the statu quo as far as `next` and `next_back` are concerned.
