-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 14 pull requests #90119
Rollup of 14 pull requests #90119
Commits on Jul 8, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 734bfde - Browse repository at this point
Copy the full SHA 734bfdeView commit details
Commits on Jul 9, 2021
-
Clarify docs on what IPv4 octal addresses are
The way octal literals are written in IP addresses differs from the way they are written in Rust code, so the way that octal/hex literals in IPs are written is explictly mentioned.
Configuration menu - View commit details
-
Copy full SHA for 69de693 - Browse repository at this point
Copy the full SHA 69de693View commit details -
Now that there can't be a bunch of leading zeros, parsing can be optimized a bit.
Configuration menu - View commit details
-
Copy full SHA for b9b97bb - Browse repository at this point
Copy the full SHA b9b97bbView commit details
Commits on Jul 11, 2021
-
Configuration menu - View commit details
-
Copy full SHA for a331e5f - Browse repository at this point
Copy the full SHA a331e5fView commit details -
Configuration menu - View commit details
-
Copy full SHA for ace518d - Browse repository at this point
Copy the full SHA ace518dView commit details
Commits on Jul 24, 2021
-
Configuration menu - View commit details
-
Copy full SHA for d65ab29 - Browse repository at this point
Copy the full SHA d65ab29View commit details
Commits on Aug 10, 2021
-
Specify maximum IP address length
Co-authored-by: Cheng XU <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 403d269 - Browse repository at this point
Copy the full SHA 403d269View commit details
Commits on Sep 4, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 85d6029 - Browse repository at this point
Copy the full SHA 85d6029View commit details -
Configuration menu - View commit details
-
Copy full SHA for 22c2738 - Browse repository at this point
Copy the full SHA 22c2738View commit details -
Configuration menu - View commit details
-
Copy full SHA for 6e40618 - Browse repository at this point
Copy the full SHA 6e40618View commit details -
Configuration menu - View commit details
-
Copy full SHA for fc5633f - Browse repository at this point
Copy the full SHA fc5633fView commit details -
Configuration menu - View commit details
-
Copy full SHA for b7d9998 - Browse repository at this point
Copy the full SHA b7d9998View commit details
Commits on Oct 18, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 4a37b9c - Browse repository at this point
Copy the full SHA 4a37b9cView commit details -
Configuration menu - View commit details
-
Copy full SHA for 93f80bf - Browse repository at this point
Copy the full SHA 93f80bfView commit details -
Add test for debug logging during incremental compilation
Debug logging during incremental compilation had been broken for some time, until rust-lang#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.
Configuration menu - View commit details
-
Copy full SHA for aefbd40 - Browse repository at this point
Copy the full SHA aefbd40View commit details
Commits on Oct 19, 2021
-
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.
Configuration menu - View commit details
-
Copy full SHA for f2a234e - Browse repository at this point
Copy the full SHA f2a234eView commit details -
Configuration menu - View commit details
-
Copy full SHA for e8b5af1 - Browse repository at this point
Copy the full SHA e8b5af1View commit details -
Configuration menu - View commit details
-
Copy full SHA for 05eb6f3 - Browse repository at this point
Copy the full SHA 05eb6f3View commit details -
Configuration menu - View commit details
-
Copy full SHA for 99b8c01 - Browse repository at this point
Copy the full SHA 99b8c01View commit details -
Configuration menu - View commit details
-
Copy full SHA for 6e98688 - Browse repository at this point
Copy the full SHA 6e98688View commit details
Commits on Oct 20, 2021
-
replace format!("") with String::new()
use array explicitly instead of vec for const content (even if optimizer smart enought to remove allocation)
Configuration menu - View commit details
-
Copy full SHA for aad48f7 - Browse repository at this point
Copy the full SHA aad48f7View commit details -
use array explicitly instead of vec for const content (even if optimi…
…zer smart enought to remove allocation)
Configuration menu - View commit details
-
Copy full SHA for f3fb821 - Browse repository at this point
Copy the full SHA f3fb821View commit details -
Make
From
impls of NonZero integer const.I also changed the feature gate added to `From` impls of Atomic integer to `const_num_from_num` from `const_convert`.
Configuration menu - View commit details
-
Copy full SHA for 2fc7806 - Browse repository at this point
Copy the full SHA 2fc7806View commit details -
Configuration menu - View commit details
-
Copy full SHA for be30e60 - Browse repository at this point
Copy the full SHA be30e60View commit details -
Configuration menu - View commit details
-
Copy full SHA for 457f578 - Browse repository at this point
Copy the full SHA 457f578View commit details -
6
Configuration menu - View commit details
-
Copy full SHA for 0aa68a8 - Browse repository at this point
Copy the full SHA 0aa68a8View commit details -
Configuration menu - View commit details
-
Copy full SHA for 50dc319 - Browse repository at this point
Copy the full SHA 50dc319View commit details -
Add test to ensure that the missing_doc_code_examples is not triggere…
…d on foreign trait implementations
Configuration menu - View commit details
-
Copy full SHA for 69ca324 - Browse repository at this point
Copy the full SHA 69ca324View commit details -
Configuration menu - View commit details
-
Copy full SHA for 86b3dd9 - Browse repository at this point
Copy the full SHA 86b3dd9View commit details -
Co-authored-by: Yuki Okushi <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 39af41e - Browse repository at this point
Copy the full SHA 39af41eView commit details
Commits on Oct 21, 2021
-
Rollup merge of rust-lang#86984 - Smittyvb:ipv4-octal-zero, r=m-ou-se
Reject octal zeros in IPv4 addresses This fixes rust-lang#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 rust-lang#83652, but due to the way it was implemented octal zeros were still allowed.
Configuration menu - View commit details
-
Copy full SHA for 09de34c - Browse repository at this point
Copy the full SHA 09de34cView commit details -
Rollup merge of rust-lang#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!
Configuration menu - View commit details
-
Copy full SHA for fb9232b - Browse repository at this point
Copy the full SHA fb9232bView commit details -
Rollup merge of rust-lang#88644 - eopb:abstractconst_leaf_subst, r=lcnr
`AbstractConst` private fields Calls `subst` in `AbstractConst::root` when `Node` is `Leaf`. r? ``@lcnr``
Configuration menu - View commit details
-
Copy full SHA for 6f0acbc - Browse repository at this point
Copy the full SHA 6f0acbcView commit details -
Rollup merge of rust-lang#89292 - CleanCut:stabilize-cstring_from_vec…
…_with_nul, r=JohnTitor Stabilize CString::from_vec_with_nul[_unchecked] Closes the tracking issue rust-lang#73179. I am keeping this in _draft_ mode until the FCP has ended. This is my first time stabilizing a feature, so I would appreciate any guidance on things I should do differently. Closes rust-lang#73179
Configuration menu - View commit details
-
Copy full SHA for 20687bb - Browse repository at this point
Copy the full SHA 20687bbView commit details -
Rollup merge of rust-lang#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 rust-lang#89776](rust-lang#89776). For some reason the overflow is only observable with optimization turned off, but that is a separate issue.
Configuration menu - View commit details
-
Copy full SHA for d29e98f - Browse repository at this point
Copy the full SHA d29e98fView commit details -
Rollup merge of rust-lang#90029 - tgnottingham:incr-debug-logging-tes…
…t, r=Mark-Simulacrum Add test for debug logging during incremental compilation Debug logging during incremental compilation had been broken for some time, until rust-lang#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.
Configuration menu - View commit details
-
Copy full SHA for a980587 - Browse repository at this point
Copy the full SHA a980587View commit details -
Rollup merge of rust-lang#90031 - durin42:allow-llvm-tests, r=Mark-Si…
…mulacrum 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.
Configuration menu - View commit details
-
Copy full SHA for 632f06d - Browse repository at this point
Copy the full SHA 632f06dView commit details -
Rollup merge of rust-lang#90048 - GuillaumeGomez:line-number-setting,…
… r=jsha Add test for line-number setting The first commit updates the version of the package to be able to have multi-line commands (which looks much nicer for this test). r? ````@jsha````
Configuration menu - View commit details
-
Copy full SHA for 47a1f67 - Browse repository at this point
Copy the full SHA 47a1f67View commit details -
Rollup merge of rust-lang#90071 - cjgillot:no-blocks, r=oli-obk
Remove hir::map::blocks and use FnKind instead The principal tool is `FnLikeNode`, which is not often used and can be easily implemented using `rustc_hir::intravisit::FnKind`.
Configuration menu - View commit details
-
Copy full SHA for afdd0c3 - Browse repository at this point
Copy the full SHA afdd0c3View commit details -
Rollup merge of rust-lang#90074 - klensy:upvar-all, r=wesleywiser
2229 migrations small cleanup This removes needless `format!`'ing of empty string and replaces `vec!` with const strings with const array.
Configuration menu - View commit details
-
Copy full SHA for 371fd4f - Browse repository at this point
Copy the full SHA 371fd4fView commit details -
Rollup merge of rust-lang#90077 - woppopo:const_nonzero_from, r=oli-obk
Make `From` impls of NonZero integer const. I also changed the feature gate added to `From` impls of Atomic integer to `const_num_from_num` from `const_convert`. Tracking issue: rust-lang#87852
Configuration menu - View commit details
-
Copy full SHA for e4cfaa1 - Browse repository at this point
Copy the full SHA e4cfaa1View commit details -
Rollup merge of rust-lang#90097 - GuillaumeGomez:duplicated-sidebar-e…
…ntry-reexported-macro, r=notriddle Add test for duplicated sidebar entries for reexported macro Fixes rust-lang#90015. r? ````@notriddle````
Configuration menu - View commit details
-
Copy full SHA for 759a8ae - Browse repository at this point
Copy the full SHA 759a8aeView commit details -
Rollup merge of rust-lang#90098 - GuillaumeGomez:add-test-foreign-imp…
…l-missing-doc-code-examples, r=jyn514 Add test to ensure that the missing_doc_code_examples is not triggered on foreign trait implementations Fixes rust-lang#76450. r? ````@jyn514````
Configuration menu - View commit details
-
Copy full SHA for 68a5680 - Browse repository at this point
Copy the full SHA 68a5680View commit details -
Rollup merge of rust-lang#90099 - SkiFire13:fix-vec-swap-remove, r=dt…
…olnay Fix MIRI UB in `Vec::swap_remove` Fixes rust-lang#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.
Configuration menu - View commit details
-
Copy full SHA for 3680ecd - Browse repository at this point
Copy the full SHA 3680ecdView commit details