about summary refs log tree commit diff
path: root/library
AgeCommit message (Collapse)AuthorLines
2021-07-03Rollup merge of #86807 - tversteeg:patch-1, r=bjorn3Yuki Okushi-1/+0
Fix double import in wasm thread The `unsupported` type is imported two times, as `super::unsupported` and as `crate::sys::unsupported`, throwing an error. Remove `super::unsupported` in favor of the other. As reported in #86802. Fix #86802
2021-07-03Rollup merge of #86803 - ↵Yuki Okushi-2/+2
xfix:remove-unnecessary-ampersand-from-command-args-calls, r=joshtriplett Remove & from Command::args calls in documentation Now that arrays implement `IntoIterator`, using `&` is no longer necessary. This makes examples easier to understand.
2021-07-03Rollup merge of #86308 - bstrie:intrinsafe, r=JohnTitorYuki Okushi-0/+165
Docs: clarify that certain intrinsics are not unsafe As determined by the hardcoded list at https://github.com/rust-lang/rust/blob/003b8eadd7a476c51956fe447894532d6e21937e/compiler/rustc_typeck/src/check/intrinsic.rs#L59-L92
2021-07-03Rollup merge of #85001 - CDirkx:bytestring, r=JohnTitorYuki Okushi-50/+28
Merge `sys_common::bytestring` back into `os_str_bytes` `bytestring` contains code for correctly debug formatting a byte slice (`[u8]`). This functionality is and has historically only been used to provide the debug formatting of byte-based os-strings (on unix etc.). Having this functionality in the separate `bytestring` module was useful in the past to reduce duplication, as [when it was added](https://github.com/rust-lang/rust/pull/46798) `os_str_bytes` was still split into `sys::{unix, redox, wasi, etc.}::os_str`. However, now that is no longer the case, there is not much reason for the `bytestring` functionality to be separate from `os_str_bytes`; I don't think it is very likely that another part of std will need to handle formatting byte strings that are not os-strings in the future (everything should be `utf8`). This is why this PR merges the functionality of `bytestring` directly into the debug implementation in `os_str_bytes`.
2021-07-03Rollup merge of #84029 - drahnr:master, r=petrochenkovYuki Okushi-0/+15
add `track_path::path` fn for usage in `proc_macro`s Adds a way to declare a dependency on external files without including them, to either re-trigger the build of a file as well as covering the use case of including dependencies within the `rustc` invocation, such that tools like `sccache`/`cachepot` are able to handle references to external files which are not included. Ref #73921
2021-07-02Auto merge of #86806 - GuillaumeGomez:rollup-pr5r37w, r=GuillaumeGomezbors-4/+191
Rollup of 5 pull requests Successful merges: - #85749 (Revert "Don't load all extern crates unconditionally") - #86714 (Add linked list cursor end methods) - #86737 (Document rustfmt on nightly-rustc) - #86776 (Skip layout query when computing integer type size during mangling) - #86797 (Stabilize `Bound::cloned()`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-07-02Fix double import in wasm threadThomas Versteeg-1/+0
The `unsupported` type is imported two times, as `super::unsupported` and as `crate::sys::unsupported`, throwing an error. Remove `super::unsupported` in favor of the other.
2021-07-02Rollup merge of #86797 - inquisitivecrystal:bound-cloned, r=jyn514Guillaume Gomez-4/+1
Stabilize `Bound::cloned()` This PR stabilizes the function `Bound::cloned()`. Closes #61356.
2021-07-02Rollup merge of #86714 - iwahbe:add-linked-list-cursor-end-methods, r=AmanieuGuillaume Gomez-0/+190
Add linked list cursor end methods I add several methods to `LinkedList::CursorMut` and `LinkedList::Cursor`. These methods allow you to access/manipulate the ends of a list via the cursor. This is especially helpful when scanning through a list and reordering. For example: ```rust let mut c = ll.back_cursor_mut(); let mut moves = 10; while c.current().map(|x| x > 5).unwrap_or(false) { let n = c.remove_current(); c.push_front(n); if moves > 0 { break; } else { moves -= 1; } } ``` I encountered this problem working on my bachelors thesis doing graph index manipulation. While this problem can be avoided by splicing, it is awkward. I asked about the problem [here](https://internals.rust-lang.org/t/linked-list-cursurmut-missing-methods/14921/4) and it was suggested I write a PR. All methods added consist of ```rust Cursor::front(&self) -> Option<&T>; Cursor::back(&self) -> Option<&T>; CursorMut::front(&self) -> Option<&T>; CursorMut::back(&self) -> Option<&T>; CursorMut::front_mut(&mut self) -> Option<&mut T>; CursorMut::back_mut(&mut self) -> Option<&mut T>; CursorMut::push_front(&mut self, elt: T); CursorMut::push_back(&mut self, elt: T); CursorMut::pop_front(&mut self) -> Option<T>; CursorMut::pop_back(&mut self) -> Option<T>; ``` #### Design decisions: I tried to remain as consistent as possible with what was already present for linked lists. The methods `front`, `front_mut`, `back` and `back_mut` are identical to their `LinkedList` equivalents. I tried to make the `pop_front` and `pop_back` methods work the same way (vis a vis the "ghost" node) as `remove_current`. I thought this was the closest analog. `push_front` and `push_back` do not change the "current" node, even if it is the "ghost" node. I thought it was most intuitive to say that if you add to the list, current will never change. Any feedback would be welcome :smile:
2021-07-02Remove & from Command::args calls in documentationKonrad Borowski-2/+2
Now that arrays implement `IntoIterator`, using `&` is no longer necessary. This makes examples easier to understand.
2021-07-02Auto merge of #85746 - m-ou-se:io-error-other, r=joshtriplettbors-73/+96
Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only*, and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change, since the user couldn't match on these errors anyway. This way, we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`
2021-07-02add track_path::path fn for proc-macro usageBernhard Schuster-0/+15
Ref #73921
2021-07-01Stabilize `Bound::cloned()`Aris Merchant-4/+1
2021-07-02Rollup merge of #86785 - lf-:dead-code, r=Mark-SimulacrumYuki Okushi-29/+0
proc_macro/bridge: Remove dead code Slice type See https://github.com/rust-lang/rust/pull/85390#discussion_r662464868
2021-07-02Rollup merge of #86783 - mark-i-m:mutex-drop-unsized, r=XanewokYuki Okushi-20/+20
Move Mutex::unlock to T: ?Sized r? ``@mbrubeck`` cc https://github.com/rust-lang/rust/issues/81872
2021-07-01Implement changes suggested by @AmanieuIan Wahbe-10/+29
2021-07-01proc_macro/bridge: Remove dead code Slice typeJade-29/+0
See https://github.com/rust-lang/rust/pull/85390#discussion_r662464868
2021-07-01Move Mutex::unlock to T: ?SizedMark Mansi-20/+20
2021-06-30alloc: `RawVec<T, A>::shrink` can be in `no_global_oom_handling`.Miguel Ojeda-1/+0
Found in https://github.com/Rust-for-Linux/linux/pull/402. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2021-06-29Add non-mutable methods to `Cursor`Ian Wahbe-0/+17
2021-06-29add head/tail methods to linked list mutable cursorIan Wahbe-0/+154
2021-06-28Update to new bootstrap compilerMark Rousskov-335/+10
2021-06-28Auto merge of #82624 - ojeda:rwlock-example-deadlock, r=JohnTitorbors-1/+13
RWLock: Add deadlock example Suggested in https://github.com/rust-lang/rust/pull/82596 but it was a bit too late. `@matklad` `@azdavis` `@sfackler`
2021-06-27Auto merge of #86655 - jonas-schievink:const-arguments-as-str, r=kennytmbors-1/+2
Make `fmt::Arguments::as_str` unstably const Motivation: mostly to move "panic!() in const contexts" forward, making use of `as_str` was mentioned in https://github.com/rust-lang/rust/issues/85194#issuecomment-852345377 and seems like the simplest way forward.
2021-06-27Add reference to tracking issue #86302 for const_ptr_writeAlbin Hedman-4/+4
2021-06-27Add reference to issue for const_intrinsic_copy in ptr::writeAlbin Hedman-1/+1
2021-06-27Revert "Revert tests added by PR 81167."Albin Hedman-0/+50
This reverts commit cebfcd3256a6ec8655f0d9f45426d6f42a92da9c.
2021-06-27Revert "Revert effects of PRs 81167 and 83091."Albin Hedman-6/+13
This reverts commit 9d96b0ed8c0f37bc09e737e1ab5880e8f5dd43f2.
2021-06-27Make `fmt::Arguments::as_str` unstably constJonas Schievink-1/+2
2021-06-26Auto merge of #86586 - Smittyvb:https-everywhere, r=petrochenkovbors-47/+47
Use HTTPS links where possible While looking at #86583, I wondered how many other (insecure) HTTP links were in `rustc`. This changes most other `http` links to `https`. While most of the links are in comments or documentation, there are a few other HTTP links that are used by CI that are changed to HTTPS. Notes: - I didn't change any to or in licences - Some links don't support HTTPS :( - Some `http` links were dead, in those cases I upgraded them to their new places (all of which used HTTPS)
2021-06-26Auto merge of #86637 - ehuss:spellings, r=dtolnaybors-15/+15
Fix a few misspellings.
2021-06-25Fix a few misspellings.Eric Huss-15/+15
2021-06-25Restore original ordering of `ErrorKind::Other`.Mara Bos-8/+9
2021-06-26Rollup merge of #86592 - jhpratt:non_exhaustive, r=JohnTitorYuki Okushi-35/+26
Use `#[non_exhaustive]` where appropriate Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`). `@rustbot` label +C-cleanup +T-libs +S-waiting-on-review
2021-06-25Auto merge of #86151 - scottmcm:simple-hash-of, r=joshtriplettbors-16/+50
Add `BuildHasher::hash_one` as unstable Inspired by https://github.com/rust-lang/rust/pull/86140/files#diff-246941135168fbc44fce120385ee9c3156e08a1c3e2697985b56dcb8d728eedeR2416, where I wanted to write a quick test for a `Hash` implementation and it took more of a dance than I'd hoped. It looks like this would be handy in hashtable implementations, too -- a quick look at hashbrown found two places where it needs to do the same dance: https://github.com/rust-lang/hashbrown/blob/6302512a8a514fe5bd442464ebcd78139c82e1e2/src/map.rs#L247-L270 I wanted to get a "seems plausible" from a libs member before making a tracking issue, so random-sampling the intersection of highfive and governance gave me... r? `@joshtriplett` (As always, bikeshed away! And let me know if I missed something obvious again that I should have used instead.)
2021-06-24Auto merge of #86467 - ChrisDenton:win-env-clear, r=JohnTitorbors-0/+15
Windows: Fix `Command::env_clear` so it works if no variables are set Previously, it would error unless at least one new environment variable was added. The missing null presumably meant that Windows was reading random memory in that case. See: [CreateProcessW](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) (scroll down to `lpEnvironment`). Essentially the environment block is a null terminated list of null terminated strings and an empty list is `\0\0` and not `\0`. EDIT: Oh, [CreateEnvironmentBlock](https://docs.microsoft.com/en-gb/windows/win32/api/userenv/nf-userenv-createenvironmentblock) states this much more explicitly. Fixes #31259
2021-06-24Test that `env_clear` works on WindowsChris Denton-0/+9
2021-06-24Use `hash_one` to simplify some other doctestsScott McMurray-16/+6
2021-06-24Add tracking issue and rename to hash_oneScott McMurray-7/+7
2021-06-24Add `BuildHasher::hash_of` as unstableScott McMurray-0/+44
2021-06-24Use `#[non_exhaustive]` where appropriateJacob Pratt-35/+26
Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`.
2021-06-24Rollup merge of #86415 - Kmeakin:iterator-associativity-docs, r=dtolnayYuki Okushi-2/+29
Document associativity of iterator folds. Document the associativity of `Iterator::fold` and `DoubleEndedIterator::rfold` and add examples demonstrating this. Add links to direct users to the fold of the opposite associativity.
2021-06-23Use HTTPS links where possibleSmitty-47/+47
2021-06-23Auto merge of #86386 - ↵bors-1/+2
inquisitivecrystal:better-errors-for-display-traits-v3, r=estebank Better errors for Debug and Display traits Currently, if someone tries to pass value that does not implement `Debug` or `Display` to a formatting macro, they get a very verbose and confusing error message. This PR changes the error messages for missing `Debug` and `Display` impls to be less overwhelming in this case, as suggested by #85844. I was a little less aggressive in changing the error message than that issue proposed. Still, this implementation would be enough to reduce the number of messages to be much more manageable. After this PR, information on the cause of an error involving a `Debug` or `Display` implementation would suppressed if the requirement originated within a standard library macro. My reasoning was that errors originating from within a macro are confusing when they mention details that the programmer can't see, and this is particularly problematic for `Debug` and `Display`, which are most often used via macros. It is possible that either a broader or a narrower criterion would be better. I'm quite open to any feedback. Fixes #85844.
2021-06-23Rollup merge of #86521 - the8472:add-footgun-comments, r=RalfJungDylan DPC-0/+17
Add comments around code where ordering is important due for panic-safety Iterators contain arbitrary code which may panic. Unsafe code has to be careful to do its state updates at the right point between calls that may panic. As requested in https://github.com/rust-lang/rust/pull/86452#discussion_r655153948 r? `@RalfJung`
2021-06-22Add comments around code where ordering is important due for panic-safetyThe8472-0/+17
Iterators contain arbitrary code which may panic. Unsafe code has to be careful to do its state updates at the right point between calls that may panic.
2021-06-22Auto merge of #84910 - eopb:stabilize_int_error_matching, r=yaahcbors-30/+10
stabilize `int_error_matching` closes #22639 > It has been over half a year since https://github.com/rust-lang/rust/pull/77640#pullrequestreview-511263516, and the indexing question is rejected in https://github.com/rust-lang/rust/pull/79728#pullrequestreview-633030341, so I guess we can submit another stabilization attempt? 😉 _Originally posted by `@kennytm` in https://github.com/rust-lang/rust/issues/22639#issuecomment-831738266_
2021-06-22postpone stabilizaton by one releaseEthan Brierley-9/+9
2021-06-22Change Debug unimplemented message per requestAris Merchant-1/+1
2021-06-22Auto merge of #86527 - JohnTitor:rollup-cbu78g4, r=JohnTitorbors-180/+280
Rollup of 11 pull requests Successful merges: - #85054 (Revert SGX inline asm syntax) - #85182 (Move `available_concurrency` implementation to `sys`) - #86037 (Add `io::Cursor::{remaining, remaining_slice, is_empty}`) - #86114 (Reopen #79692 (Format symbols under shared frames)) - #86297 (Allow to pass arguments to rustdoc-gui tool) - #86334 (Resolve type aliases to the type they point to in intra-doc links) - #86367 (Fix comment about rustc_inherit_overflow_checks in abs().) - #86381 (Add regression test for issue #39161) - #86387 (Remove `#[allow(unused_lifetimes)]` which is now unnecessary) - #86398 (Add regression test for issue #54685) - #86493 (Say "this enum variant takes"/"this struct takes" instead of "this function takes") Failed merges: r? `@ghost` `@rustbot` modify labels: rollup