Matthias Krüger [Sat, 23 Oct 2021 03:28:26 +0000 (05:28 +0200)]
Rollup merge of #90117 - calebsander:fix/rsplit-clone, r=yaahc
Make RSplit<T, P>: Clone not require T: Clone
This addresses a TODO comment. The behavior of `#[derive(Clone)]` *does* result in a `T: Clone` requirement. Playground example:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a8b1a9581ff8893baf401d624a53d35b
Add a manual `Clone` implementation, mirroring `Split` and `SplitInclusive`.
`(R)?SplitN(Mut)?` don't have any `Clone` implementations, but I'll leave that for its own pull request.
Matthias Krüger [Sat, 23 Oct 2021 03:28:25 +0000 (05:28 +0200)]
Rollup merge of #90087 - calebcartwright:rustfmt-subtree, r=calebcartwright
Sync rustfmt subtree
There's a large number of small fixes and new features, but nothing too big. Detailed changelog for those interested can be found in https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#1438-2021-10-20
Matthias Krüger [Sat, 23 Oct 2021 03:28:24 +0000 (05:28 +0200)]
Rollup merge of #90070 - llogiq:compiletest-config-edition, r=Mark-Simulacrum
Add edition configuration to compiletest
This allows the compiletest configuration to set a default edition that can still be overridden with header annotations. Doing this will make it far easier for clippy to get our tests to the newest edition.
Matthias Krüger [Sat, 23 Oct 2021 03:28:23 +0000 (05:28 +0200)]
Rollup merge of #89920 - hudson-ayers:location-detail-control, r=davidtwco
Implement -Z location-detail flag
This PR implements the `-Z location-detail` flag as described in https://github.com/rust-lang/rfcs/pull/2091 .
`-Z location-detail=val` controls what location details are tracked when using `caller_location`. This allows users to control what location details are printed as part of panic messages, by allowing them to exclude any combination of filenames, line numbers, and column numbers. This option is intended to provide users with a way to mitigate the size impact of `#[track_caller]`.
Some measurements of the savings of this approach on an embedded binary can be found here: https://github.com/rust-lang/rust/issues/70579#issuecomment-942556822 .
Closes #70580 (unless people want to leave that open as a place for discussion of further improvements).
This is my first real PR to rust, so any help correcting mistakes / understanding side effects / improving my tests is appreciated :)
I have one question: RFC 2091 specified this as a debugging option (I think that is what -Z implies?). Does that mean this can never be stabilized without a separate MCP? If so, do I need to submit an MCP now, or is the initial RFC specifying this option sufficient for this to be merged as is, and then an MCP would be needed for eventual stabilization?
Matthias Krüger [Sat, 23 Oct 2021 03:28:22 +0000 (05:28 +0200)]
Rollup merge of #89468 - FabianWolff:issue-89358, r=jackh726
Report fatal lexer errors in `--cfg` command line arguments
Fixes #89358. The erroneous behavior was apparently introduced by `@Mark-Simulacrum` in https://github.com/rust-lang/rust/commit/a678e3191197f145451c97c6cc884e15cae38186; the idea is to silence individual parser errors and instead emit one catch-all error message after parsing. However, for the example in #89358, a fatal lexer error is created here:
https://github.com/rust-lang/rust/blob/edebf77e0090195bf80c0d8cda821e1bf9d03053/compiler/rustc_parse/src/lexer/mod.rs#L340-L349
This fatal error aborts the compilation, and so the call to `new_parser_from_source_str()` never returns and the catch-all error message is never emitted. I have therefore changed the `SilentEmitter` to silence only non-fatal errors; with my changes, for the rustc invocation described in #89358:
```sh
rustc --cfg "abc\""
```
I get the following output:
```
error[E0765]: unterminated double quote string
|
= note: this error occurred on the command line: `--cfg=abc"`
```
Matthias Krüger [Sat, 23 Oct 2021 03:28:19 +0000 (05:28 +0200)]
Rollup merge of #83233 - jethrogb:split_array, r=yaahc
Implement split_array and split_array_mut
This implements `[T]::split_array::<const N>() -> (&[T; N], &[T])` and `[T; N]::split_array::<const M>() -> (&[T; M], &[T])` and their mutable equivalents. These are another few “missing” array implementations now that const generics are a thing, similar to #74373, #75026, etc. Fixes #74674.
This implements `[T; N]::split_array` returning an array and a slice. Ultimately, this is probably not what we want, we would want the second return value to be an array of length N-M, which will likely be possible with future const generics enhancements. We need to implement the array method now though, to immediately shadow the slice method. This way, when the slice methods get stabilized, calling them on an array will not be automatic through coercion, so we won't have trouble stabilizing the array methods later (cf. into_iter debacle).
An unchecked version of `[T]::split_array` could also be added as in #76014. This would not be needed for `[T; N]::split_array` as that can be compile-time checked. Edit: actually, since split_at_unchecked is internal-only it could be changed to be split_array-only.
Looks like this if `CStr::from_ptr` is allowed to be inlined.
```asm
before:
push rax
call qword ptr [rip + std::ffi::c_str::CStr::from_ptr@GOTPCREL]
mov rcx, rax
cmp rdx, 1
sete dl
test rax, rax
sete al
or al, dl
jne .LBB1_2
mov dl, byte ptr [rcx]
.LBB1_2:
xor al, 1
pop rcx
ret
after:
mov dl, byte ptr [rdi]
test dl, dl
setne al
ret
```
Note that optimization turned this from O(N) to O(1) in terms of performance, as LLVM knows that it doesn't really need to call `strlen` to determine whether a string is empty or not.
bors [Fri, 22 Oct 2021 14:25:23 +0000 (14:25 +0000)]
Auto merge of #90161 - JohnTitor:rollup-1j2qc8m, r=JohnTitor
Rollup of 14 pull requests
Successful merges:
- #87537 (Clarify undefined behaviour in binary heap, btree and hashset docs)
- #88624 (Stabilize feature `saturating_div` for rust 1.58.0)
- #89257 (Give better error for `macro_rules name`)
- #89665 (Ensure that pushing empty path works as before on verbatim paths)
- #89895 (Don't mark for loop iter expression as desugared)
- #89922 (Update E0637 description to mention `&` w/o an explicit lifetime name)
- #89944 (Change `Duration::[try_]from_secs_{f32, f64}` underflow error)
- #89991 (rustc_ast: Turn `MutVisitor::token_visiting_enabled` into a constant)
- #90028 (Reject closures in patterns)
- #90069 (Fix const qualification when executed after promotion)
- #90078 (Add a regression test for issue-83479)
- #90114 (Add some tests for const_generics_defaults)
- #90115 (Add test for issue #78561)
- #90129 (triagebot: Treat `I-*nominated` like `I-nominated`)
Yuki Okushi [Fri, 22 Oct 2021 10:42:51 +0000 (19:42 +0900)]
Rollup merge of #90114 - BoxyUwU:cg_defaults_tests, r=lcnr
Add some tests for const_generics_defaults
I think this covers some of the stuff required for stabilisation report, some of these tests are probably covering stuff we already have but it can't hurt to have more :)
Yuki Okushi [Fri, 22 Oct 2021 10:42:50 +0000 (19:42 +0900)]
Rollup merge of #90078 - JohnTitor:test-83479, r=Mark-Simulacrum
Add a regression test for issue-83479
Add a regression test for https://github.com/rust-lang/rust/issues/83479#issue-841147340, but not close the issue, see https://github.com/rust-lang/rust/issues/83479#issuecomment-947255641.
Yuki Okushi [Fri, 22 Oct 2021 10:42:49 +0000 (19:42 +0900)]
Rollup merge of #90069 - tmiasko:promoted-const-qualif, r=oli-obk
Fix const qualification when executed after promotion
The const qualification was so far performed before the promotion and
the implementation assumed that it will never encounter a promoted.
With `const_precise_live_drops` feature, checking for live drops is
delayed until after drop elaboration, which in turn runs after
promotion. so the assumption is no longer true. When evaluating
`NeedsNonConstDrop` it is now possible to encounter promoteds.
Use type base qualification for the promoted. It is a sound
approximation in general, and in the specific case of promoteds and
`NeedsNonConstDrop` it is precise.
Yuki Okushi [Fri, 22 Oct 2021 10:42:46 +0000 (19:42 +0900)]
Rollup merge of #89922 - JohnTitor:update-e0637, r=jackh726
Update E0637 description to mention `&` w/o an explicit lifetime name
Deal with https://github.com/rust-lang/rust/issues/89824#issuecomment-941598647. Another solution would be splitting the error code into two as (I think) it's a bit unclear to users why they have the same error code.
Yuki Okushi [Fri, 22 Oct 2021 10:42:45 +0000 (19:42 +0900)]
Rollup merge of #89895 - camsteffen:for-loop-head-span, r=davidtwco
Don't mark for loop iter expression as desugared
We typically don't mark spans of lowered things as desugared. This helps Clippy rightly discern when code is (not) from expansion. This was discovered by ``@flip1995`` at https://github.com/rust-lang/rust-clippy/pull/7789#issuecomment-939289501.
Yuki Okushi [Fri, 22 Oct 2021 10:42:42 +0000 (19:42 +0900)]
Rollup merge of #88624 - kellerkindt:master, r=JohnTitor
Stabilize feature `saturating_div` for rust 1.58.0
The tracking issue is #89381
This seems like a reasonable simple change(?). The feature `saturating_div` was added as part of the ongoing effort to implement a `Saturating` integer type (see #87921). The implementation has been discussed [here](https://github.com/rust-lang/rust/pull/87921#issuecomment-899357720) and [here](https://github.com/rust-lang/rust/pull/87921#discussion_r691888556). It extends the list of saturating operations on integer types (like `saturating_add`, `saturating_sub`, `saturating_mul`, ...) by the function `fn saturating_div(self, rhs: Self) -> Self`.
The stabilization of the feature `saturating_int_impl` (for the `Saturating` type) needs to have this stabilized first.
Yuki Okushi [Fri, 22 Oct 2021 10:42:41 +0000 (19:42 +0900)]
Rollup merge of #87537 - Wilfred:improve-min-heap-docs, r=Mark-Simulacrum
Clarify undefined behaviour in binary heap, btree and hashset docs
Previously, it wasn't clear whether "This could include" was referring to logic errors, or undefined behaviour. Tweak wording to clarify this sentence does not relate to UB.
Clarify undefined behaviour for binary heap, btree and hashset
Previously, it wasn't clear whether "This could include" was referring
to logic errors, or undefined behaviour. Tweak wording to clarify this
sentence does not relate to UB.
bors [Thu, 21 Oct 2021 08:04:19 +0000 (08:04 +0000)]
Auto merge of #90119 - JohnTitor:rollup-e5t6khz, r=JohnTitor
Rollup of 14 pull requests
Successful merges:
- #86984 (Reject octal zeros in IPv4 addresses)
- #87440 (Remove unnecessary condition in Barrier::wait())
- #88644 (`AbstractConst` private fields)
- #89292 (Stabilize CString::from_vec_with_nul[_unchecked])
- #90010 (Avoid overflow in `VecDeque::with_capacity_in()`.)
- #90029 (Add test for debug logging during incremental compilation)
- #90031 (config: add the option to enable LLVM tests)
- #90048 (Add test for line-number setting)
- #90071 (Remove hir::map::blocks and use FnKind instead)
- #90074 (2229 migrations small cleanup)
- #90077 (Make `From` impls of NonZero integer const.)
- #90097 (Add test for duplicated sidebar entries for reexported macro)
- #90098 (Add test to ensure that the missing_doc_code_examples is not triggered on foreign trait implementations)
- #90099 (Fix MIRI UB in `Vec::swap_remove`)
Yuki Okushi [Thu, 21 Oct 2021 05:11:13 +0000 (14:11 +0900)]
Rollup merge of #90099 - SkiFire13:fix-vec-swap-remove, r=dtolnay
Fix MIRI UB in `Vec::swap_remove`
Fixes #90055
I find it weird that `Vec::swap_remove` read the last element to the stack just to immediately put it back in the `Vec` in place of the one at index `index`. It seems much more natural to me to just read the element at position `index` and then move the last element in its place. I guess this might also slightly improve codegen.
Yuki Okushi [Thu, 21 Oct 2021 05:11:07 +0000 (14:11 +0900)]
Rollup merge of #90031 - durin42:allow-llvm-tests, r=Mark-Simulacrum
config: add the option to enable LLVM tests
I'm working on some LLVM patches in concert with a Rust patch, and it's
helping me quite a bit to have this as an option. It doesn't seem that
hard, so I figured I'd formalize it in x.py and send it upstream.
Yuki Okushi [Thu, 21 Oct 2021 05:11:06 +0000 (14:11 +0900)]
Rollup merge of #90029 - tgnottingham:incr-debug-logging-test, r=Mark-Simulacrum
Add test for debug logging during incremental compilation
Debug logging during incremental compilation had been broken for some
time, until #89343 fixed it (among other things). Add a test so this is
less likely to break without being noticed. This test is nearly a copy
of the `src/test/ui/rustc-rust-log.rs` test, but tests debug logging in
the incremental compliation code paths.
Yuki Okushi [Thu, 21 Oct 2021 05:11:05 +0000 (14:11 +0900)]
Rollup merge of #90010 - rusticstuff:vecdeque_with_capacity_in_overflow, r=m-ou-se
Avoid overflow in `VecDeque::with_capacity_in()`.
The overflow only happens if alloc is compiled with overflow checks enabled and the passed capacity is greater or equal 2^(usize::BITS-1). The overflow shadows the expected "capacity overflow" panic leading to a test failure if overflow checks are enabled for std in the CI.
Unblocks [CI: Enable overflow checks for test (non-dist) builds #89776](https://github.com/rust-lang/rust/pull/89776).
For some reason the overflow is only observable with optimization turned off, but that is a separate issue.
Yuki Okushi [Thu, 21 Oct 2021 05:11:02 +0000 (14:11 +0900)]
Rollup merge of #87440 - twetzel59:fix-barrier-no-op, r=yaahc
Remove unnecessary condition in Barrier::wait()
This is my first pull request for Rust, so feel free to call me out if anything is amiss.
After some examination, I realized that the second condition of the "spurious-wakeup-handler" loop in ``std::sync::Barrier::wait()`` should always evaluate to ``true``, making it redundant in the ``&&`` expression.
Here is the affected function before the fix:
```rust
#[stable(feature = "rust1", since = "1.0.0")]
pub fn wait(&self) -> BarrierWaitResult {
let mut lock = self.lock.lock().unwrap();
let local_gen = lock.generation_id;
lock.count += 1;
if lock.count < self.num_threads {
// We need a while loop to guard against spurious wakeups.
// https://en.wikipedia.org/wiki/Spurious_wakeup
while local_gen == lock.generation_id && lock.count < self.num_threads { // fixme
lock = self.cvar.wait(lock).unwrap();
}
BarrierWaitResult(false)
} else {
lock.count = 0;
lock.generation_id = lock.generation_id.wrapping_add(1);
self.cvar.notify_all();
BarrierWaitResult(true)
}
}
```
At first glance, it seems that the check that ``lock.count < self.num_threads`` would be necessary in order for a thread A to detect when another thread B has caused the barrier to reach its thread count, making thread B the "leader".
However, the control flow implicitly results in an invariant that makes observing ``!(lock.count < self.num_threads)``, i.e. ``lock.count >= self.num_threads`` impossible from thread A.
When thread B, which will be the leader, calls ``.wait()`` on this shared instance of the ``Barrier``, it locks the mutex in the first line and saves the ``MutexGuard`` in the ``lock`` variable. It then increments the value of ``lock.count``. However, it then proceeds to check if ``lock.count < self.num_threads``. Since it is the leader, it is the case that (after the increment of ``lock.count``), the lock count is *equal* to the number of threads. Thus, the second branch is immediately taken and ``lock.count`` is zeroed. Additionally, the generation ID is incremented (with wrap). Then, the condition variable is signalled. But, the other threads are waiting at the line ``lock = self.cvar.wait(lock).unwrap();``, so they cannot resume until thread B's call to ``Barrier::wait()`` returns, which drops the ``MutexGuard`` acquired in the first ``let`` statement and unlocks the mutex.
The order of events is thus:
1. A thread A calls `.wait()`
2. `.wait()` acquires the mutex, increments `lock.count`, and takes the first branch
3. Thread A enters the ``while`` loop since the generation ID has not changed and the count is less than the number of threads for the ``Barrier``
3. Spurious wakeups occur, but both conditions hold, so the thread A waits on the condition variable
4. This process repeats for N - 2 additional times for non-leader threads A'
5. *Meanwhile*, Thread B calls ``Barrier::wait()`` on the same barrier that threads A, A', A'', etc. are waiting on. The thread count reaches the number of threads for the ``Barrier``, so all threads should now proceed, with B being the leader. B acquires the mutex and increments the value ``lock.count`` only to find that it is not less than ``self.num_threads``. Thus, it immediately clamps ``self.num_threads`` back down to 0 and increments the generation. Then, it signals the condvar to tell the A (prime) threads that they may continue.
6. The A, A', A''... threads wake up and attempt to re-acquire the ``lock`` as per the internal operation of a condition variable. When each A has exclusive access to the mutex, it finds that ``lock.generation_id`` no longer matches ``local_generation`` **and the ``&&`` expression short-circuits -- and even if it were to evaluate it, ``self.count`` is definitely less than ``self.num_threads`` because it has been reset to ``0`` by thread B *before* B dropped its ``MutexGuard``**.
Therefore, it my understanding that it would be impossible for the non-leader threads to ever see the second boolean expression evaluate to anything other than ``true``. This PR simply removes that condition.
Any input would be appreciated. Sorry if this is terribly verbose. I'm new to the Rust community and concurrency can be hard to explain in words. Thanks!
Yuki Okushi [Thu, 21 Oct 2021 05:11:01 +0000 (14:11 +0900)]
Rollup merge of #86984 - Smittyvb:ipv4-octal-zero, r=m-ou-se
Reject octal zeros in IPv4 addresses
This fixes #86964 by rejecting octal zeros in IP addresses, such that `192.168.00.00000000` is rejected with a parse error, since having leading zeros in front of another zero indicates it is a zero written in octal notation, which is not allowed in the strict mode specified by RFC 6943 3.1.1. Octal rejection was implemented in #83652, but due to the way it was implemented octal zeros were still allowed.
bors [Thu, 21 Oct 2021 05:04:39 +0000 (05:04 +0000)]
Auto merge of #90072 - ehuss:empty-rmeta-no-warn, r=Mark-Simulacrum
Don't emit a warning for empty rmeta files.
This avoids displaying a warning when attempting to load an empty rmeta file. Warnings were enabled via #89634 which can cause a lot of noise (for example, running `./x.py check`). rustc generates empty rmeta files for things like binaries, which can happen when checking libraries as unittests.
bors [Thu, 21 Oct 2021 01:38:55 +0000 (01:38 +0000)]
Auto merge of #89998 - camelid:box-default, r=jyn514
rustdoc: Box some fields of `GenericParamDefKind` to reduce size
This change shrinks `GenericParamDef` from 120 to 56 bytes. `GenericParamDef` is
used a lot, so the extra indirection should hopefully be worth the size savings.
bors [Wed, 20 Oct 2021 20:35:58 +0000 (20:35 +0000)]
Auto merge of #7838 - nhamovitz:trailing_zs_arr_wo_repr, r=Manishearth
Warn on structs with a trailing zero-sized array but no `repr` attribute
Closes #2868
changelog: Implement ``[`trailing_empty_array`]``, which warns if a struct is defined where the last field is a zero-sized array but there are no `repr` attributes. Zero-sized arrays aren't very useful in Rust itself, so such a struct is likely being created to pass to C code or in some other situation where control over memory layout matters. Either way, a `repr` attribute is needed.
bors [Wed, 20 Oct 2021 17:57:35 +0000 (17:57 +0000)]
Auto merge of #89978 - cjgillot:qarray, r=Mark-Simulacrum
Merge the two depkind vtables
Knowledge of `DepKind`s is managed using two arrays containing flags (is_anon, eval_always, fingerprint_style), and function pointers (forcing and loading code).
This PR aims at merging the two arrays so as to reduce unneeded indirect calls and (hopefully) increase code locality.
r? `@ghost`
bors [Wed, 20 Oct 2021 14:37:48 +0000 (14:37 +0000)]
Auto merge of #90050 - michaelwoerister:fix-vtable-debug-name-crash-90019, r=wesleywiser
Erase late-bound regions before computing vtable debuginfo name.
Fixes #90019.
The `msvc_enum_fallback()` for computing enum type names needs to access the memory layout of niche enums in order to determine the type name. `compute_debuginfo_vtable_name()` did not properly erase regions before computing type names which made memory layout computation ICE when encountering un-erased regions.
projects / rust.git / log