bors [Thu, 2 Jun 2022 13:20:19 +0000 (13:20 +0000)]
Auto merge of #97293 - est31:remove_box, r=oli-obk
Add #[rustc_box] and use it inside alloc
This commit adds an alternative content boxing syntax, and uses it inside alloc.
```Rust
#![feature(box_syntax)]
fn foo() {
let foo = box bar;
}
```
is equivalent to
```Rust
#![feature(rustc_attrs)]
fn foo() {
let foo = #[rustc_box] Box::new(bar);
}
```
The usage inside the very performance relevant code in
liballoc is the only remaining relevant usage of box syntax
in the compiler (outside of tests, which are comparatively easy to port).
box syntax was originally designed to be used by all Rust
developers. This introduces a replacement syntax more tailored
to only being used inside the Rust compiler, and with it,
lays the groundwork for eventually removing box syntax.
[Earlier work](https://github.com/rust-lang/rust/pull/87781#issuecomment-894714878) by `@nbdd0121` to lower `Box::new` to `box` during THIR -> MIR building ran into borrow checker problems, requiring the lowering to be adjusted in a way that led to [performance regressions](https://github.com/rust-lang/rust/pull/87781#issuecomment-894872367). The proposed change in this PR lowers `#[rustc_box] Box::new` -> `box` in the AST -> HIR lowering step, which is way earlier in the compiler, and thus should cause less issues both performance wise as well as regarding type inference/borrow checking/etc. Hopefully, future work can move the lowering further back in the compiler, as long as there are no performance regressions.
bors [Thu, 2 Jun 2022 10:39:24 +0000 (10:39 +0000)]
Auto merge of #97644 - Dylan-DPC:rollup-xaeio91, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #96894 (Apply track_caller to closure on `expect_non_local()`)
- #97023 (Diagnose anonymous lifetimes errors more uniformly between async and regular fns)
- #97397 (Stabilize `box_into_pin`)
- #97587 (Migrate more diagnostics to use the `#[derive(SessionDiagnostic)]`)
- #97603 (Arc make_mut doc comment spelling correction.)
- #97635 (Fix file metadata documentation for Windows)
Dylan DPC [Thu, 2 Jun 2022 09:13:26 +0000 (11:13 +0200)]
Rollup merge of #97635 - rgwood:patch-1, r=ChrisDenton
Fix file metadata documentation for Windows
I noticed that the documentation for `fs::symlink_metadata()` and `fs::metadata()` is incorrect; [the underlying code](https://github.com/rust-lang/rust/blob/481db40311cdd241ae4d33f34f2f75732e44d8e8/library/std/src/sys/windows/fs.rs#L334) calls [`GetFileInformationByHandle()`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileinformationbyhandle) on Windows, not [`GetFileAttributesEx()`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileattributesexw). There are currently [no uses of `GetFileAttributesEx()` in this repo](https://github.com/rust-lang/rust/search?q=GetFileAttributesEx).
Dylan DPC [Thu, 2 Jun 2022 09:13:23 +0000 (11:13 +0200)]
Rollup merge of #97397 - JohnTitor:stabilize-box-into-pin, r=Mark-Simulacrum
Stabilize `box_into_pin`
FCP has been completed: https://github.com/rust-lang/rust/issues/62370#issuecomment-1012162279
Also, adds notes as per https://github.com/rust-lang/rust/issues/62370#issuecomment-1004108116
Closes #62370
Dylan DPC [Thu, 2 Jun 2022 09:13:22 +0000 (11:13 +0200)]
Rollup merge of #97023 - cjgillot:uniform-anon, r=estebank
Diagnose anonymous lifetimes errors more uniformly between async and regular fns
Async fns and regular fns are desugared differently. For the former, we create a generic parameter at HIR level. For the latter, we just create an anonymous region for typeck.
I plan to migrate regular fns to the async fn desugaring.
Before that, this PR attempts to merge the diagnostics for both cases.
bors [Thu, 2 Jun 2022 07:58:29 +0000 (07:58 +0000)]
Auto merge of #96737 - ChrisDenton:win-manifest, r=wesleywiser
Add Windows application manifest to rustc-main
Windows allows setting some runtime options using a manifest file. The format of the XML file is documented here: https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests
The manifest file in this PR does three things:
* Declares which Windows versions we support. This may help avoid unnecessary compatibility shims.
* Uses the UTF-8 code page. While Rust itself uses UTF-16 APIs, other code may rely on the code page.
* Makes the application long path aware (if also enabled by the user). This allows for the current directory to be longer than `PATH_MAX`.
These changes only affect the `rustc` process and not any other DLLs or compiled programs.
Yuki Okushi [Wed, 1 Jun 2022 21:44:29 +0000 (06:44 +0900)]
Rollup merge of #97613 - jsha:implementation-is-on-local-type, r=GuillaumeGomez
rustdoc: Improve calculation of "Impls on Foreign Types"
The existing code to calculate whether an implementation was on a "Foreign Type" was duplicated across the sidebar generation and the page generation. It also came to the wrong conclusion for some cases where both the trait and the "for" type were re-exports.
This PR extracts the logic into a method of `Impl`, breaks it into a multi-line method so it can be commented, and adds a case for when the trait and the "for" type came from the same crate. This fixes some cases - like the platform-specific integer types (`__m256`, `__m128`, etc). But it doesn't fix all cases. See the screenshots below.
The remaining types (`CString`, `NulError`, etc) are all from the `alloc` crate, while the `Clone` trait is from the `core` crate. Since `CString` and `Clone` are both re-exported by `std`, they are logically local to each other, but I couldn't figure out a good way to detect that in this code. I figure this is still a good step forward.
Yuki Okushi [Wed, 1 Jun 2022 21:44:27 +0000 (06:44 +0900)]
Rollup merge of #97166 - nnethercote:move-conditions-out, r=estebank
Move conditions out of recover/report functions.
`Parser` has six recover/report functions that are passed a boolean, and
nothing is done if the boolean has a particular value.
This PR moves the tests outside the functions. This has the following effects.
- The number of lines of code goes down.
- Some `use` items become shorter.
- Avoids the strangeness whereby 11 out of 12 calls to
`maybe_recover_from_bad_qpath` pass `true` as the second argument.
- Makes it clear at the call site that only one of
`maybe_recover_from_bad_type_plus` and `maybe_report_ambiguous_plus` will be
run.
bors [Wed, 1 Jun 2022 20:06:14 +0000 (20:06 +0000)]
Auto merge of #97612 - ehuss:update-cargo, r=ehuss
Update cargo
5 commits in 39ad1039d9e3e1746177bf5d134af4c164f95528..38472bc19f2f76e245eba54a6e97ee6821b3c1db
2022-05-25 00:50:02 +0000 to 2022-05-31 02:03:24 +0000
- Emit warning upon encountering multiple packages with the same name (rust-lang/cargo#10701)
- Guide new users to add use `super::*;` to `mod test` (rust-lang/cargo#10706)
- Document how to debug change detection events (rust-lang/cargo#10708)
- fix(publish): add more check when use `publish -p <SPEC>` (rust-lang/cargo#10677)
- fix key formatting when switching to a dotted `WorkspaceSource` (rust-lang/cargo#10705)
bors [Wed, 1 Jun 2022 17:25:29 +0000 (17:25 +0000)]
Auto merge of #97624 - matthiaskrgr:rollup-rtcqjx9, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #96271 (suggest `?` when method is missing on `Result<T, _>` but found on `T`)
- #97264 (Suggest `extern crate foo` when failing to resolve `use foo`)
- #97592 (rustdoc: also index impl trait and raw pointers)
- #97621 (update Miri)
bors [Wed, 1 Jun 2022 14:44:20 +0000 (14:44 +0000)]
Auto merge of #97622 - JohnTitor:rollup-4qoxrjn, r=JohnTitor
Rollup of 9 pull requests
Successful merges:
- #94647 (Expose `get_many_mut` and `get_many_unchecked_mut` to HashMap)
- #97216 (Ensure we never consider the null pointer dereferencable)
- #97399 (simplify code of finding arg index in `opt_const_param_of`)
- #97470 (rustdoc: add more test coverage)
- #97498 (Corrected EBNF grammar for from_str)
- #97562 (Fix comment in `poly_project_and_unify_type`)
- #97580 (Add regression test for #71546)
- #97611 (Tweak insert docs)
- #97616 (Remove an unnecessary `Option`)
Yuki Okushi [Wed, 1 Jun 2022 14:36:52 +0000 (23:36 +0900)]
Rollup merge of #97611 - azdavis:master, r=Dylan-DPC
Tweak insert docs
For `{Hash, BTree}Map::insert`, I always have to take a few extra seconds to think about the slight weirdness about the fact that if we "did not" insert (which "sounds" false), we return true, and if we "did" insert, (which "sounds" true), we return false.
This tweaks the doc comments for the `insert` methods of those types (as well as what looks like a rustc internal data structure that I found just by searching the codebase for "If the set did") to first use the "Returns whether _something_" pattern used in e.g. `remove`, where we say that `remove` "returns whether the value was present".
Yuki Okushi [Wed, 1 Jun 2022 14:36:49 +0000 (23:36 +0900)]
Rollup merge of #97498 - ijchen:master, r=Mark-Simulacrum
Corrected EBNF grammar for from_str
Hello! This is my first time contributing to an open-source project. I'm excited to have the chance to contribute to the rust community 🥳
I noticed an issue with the documentation for `from_str` in `f32` and `f64`. It states that "All strings that adhere to the following [EBNF](https://www.w3.org/TR/REC-xml/#sec-notation) grammar when lowercased will result in an `Ok` being returned. I believe this is incorrect for the string `"."`, which is valid for the given EBNF grammar, but does not result in an `Ok` being returned ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=09f891aa87963a56d3b0d715d8cbc2b4)). I have simplified the grammar in a way which fixes that, but is otherwise identical.
Previously, the `Number` part of the EBNF grammar had an option for `'.' Digit*`, which would include the string `"."`. This is not valid, and does not return an Ok as stated. The corrected version removes this, and still allows for the `'.' Digit+` case with the already existing `Digit* '.' Digit+` case.
Yuki Okushi [Wed, 1 Jun 2022 14:36:47 +0000 (23:36 +0900)]
Rollup merge of #97399 - SparrowLii:arg_index, r=oli-obk
simplify code of finding arg index in `opt_const_param_of`
From the FIXME in the impl of `opt_const_param_of`. Part of the code is simplified by blending two iterator statements and using `let...else` statement.
Yuki Okushi [Wed, 1 Jun 2022 14:36:45 +0000 (23:36 +0900)]
Rollup merge of #94647 - Urgau:hash-map-many-mut, r=Amanieu
Expose `get_many_mut` and `get_many_unchecked_mut` to HashMap
This pull-request expose the function [`get_many_mut`](https://docs.rs/hashbrown/0.12.0/hashbrown/struct.HashMap.html#method.get_many_mut) and [`get_many_unchecked_mut`](https://docs.rs/hashbrown/0.12.0/hashbrown/struct.HashMap.html#method.get_many_unchecked_mut) from `hashbrown` to the standard library `HashMap` type. They obviously keep the same API and are added under the (new) `map_many_mut` feature.
- `get_many_mut`: Attempts to get mutable references to `N` values in the map at once.
- `get_many_unchecked_mut`: Attempts to get mutable references to `N` values in the map at once, without validating that the values are unique.
bors [Wed, 1 Jun 2022 01:49:04 +0000 (01:49 +0000)]
Auto merge of #97435 - Patryk27:bump-compiler-builtins, r=Dylan-DPC
library/std: Bump compiler_builtins
Some neat changes include faster float conversions & fixes for AVR 🙂
(note that's it's my first time upgrading `compiler_builtins`, so I'm not 100% sure if bumping `library/std/Cargo.toml` is enough; certainly seems to be so, though.)
est31 [Sun, 22 May 2022 21:10:27 +0000 (23:10 +0200)]
Add #[rustc_box]
This commit adds an alternative content boxing syntax,
and uses it inside alloc.
The usage inside the very performance relevant code in
liballoc is the only remaining relevant usage of box syntax
in the compiler (outside of tests, which are comparatively
easy to port).
box syntax was originally designed to be used by all Rust
developers. This introduces a replacement syntax more tailored
to only being used inside the Rust compiler, and with it,
lays the groundwork for eventually removing box syntax.
bors [Tue, 31 May 2022 23:24:39 +0000 (23:24 +0000)]
Auto merge of #97600 - matthiaskrgr:rollup-yivyeu5, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #97316 (Put a bound on collection misbehavior)
- #97578 (alloc: remove repeated word in comment)
- #97593 (:arrow_up: rust-analyzer)
- #97596 (Fixup feature name to be more consistent with others)
Matthias Krüger [Tue, 31 May 2022 21:11:35 +0000 (23:11 +0200)]
Rollup merge of #97578 - ojeda:checkpatch, r=JohnTitor
alloc: remove repeated word in comment
Linux's `checkpatch.pl` reports:
```txt
#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+ // - Elements are :Copy so it's OK to to copy them, without doing
```
Matthias Krüger [Tue, 31 May 2022 21:11:34 +0000 (23:11 +0200)]
Rollup merge of #97316 - CAD97:bound-misbehavior, r=dtolnay
Put a bound on collection misbehavior
As currently written, when a logic error occurs in a collection's trait parameters, this allows *completely arbitrary* misbehavior, so long as it does not cause undefined behavior in std. However, because the extent of misbehavior is not specified, it is allowed for *any* code in std to start misbehaving in arbitrary ways which are not formally UB; consider the theoretical example of a global which gets set on an observed logic error. Because the misbehavior is only bound by not resulting in UB from safe APIs and the crate-level encapsulation boundary of all of std, this makes writing user unsafe code that utilizes std theoretically impossible, as it now relies on undocumented QOI (quality of implementation) that unrelated parts of std cannot be caused to misbehave by a misuse of std::collections APIs.
In practice, this is a nonconcern, because std has reasonable QOI and an implementation that takes advantage of this freedom is essentially a malicious implementation and only compliant by the most langauage-lawyer reading of the documentation.
To close this hole, we just add a small clause to the existing logic error paragraph that ensures that any misbehavior is limited to the collection which observed the logic error, making it more plausible to prove the soundness of user unsafe code.
This is not meant to be formal; a formal refinement would likely need to mention that values derived from the collection can also misbehave after a logic error is observed, as well as define what it means to "observe" a logic error in the first place. This fix errs on the side of informality in order to close the hole without complicating a normal reading which can assume a reasonable nonmalicious QOI.
bors [Tue, 31 May 2022 17:59:41 +0000 (17:59 +0000)]
Auto merge of #97570 - JakobDegen:dse-test, r=tmiasko
Fix TLS access mir opt test and remove stale files
Thanks `@pietroalbini` for noticing that the TLS test was not doing what it was supposed to. Switched to `PreCodegen` because `SimplifyCfg` does not run on opt level 0.
Tracking issue: #89792.
Feature for `from_ptr_range` as a `const fn`: `slice_from_ptr_range_const`.
Feature for `from_mut_ptr_range` as a `const fn`: `slice_from_mut_ptr_range_const`.
bors [Tue, 31 May 2022 12:14:51 +0000 (12:14 +0000)]
Auto merge of #97521 - SkiFire13:clarify-vec-as-ptr, r=Dylan-DPC
Clarify the guarantees of Vec::as_ptr and Vec::as_mut_ptr when there's no allocation
Currently the documentation says they return a pointer to the vector's buffer, which has the implied precondition that the vector allocated some memory. However `Vec`'s documentation also specifies that it won't always allocate, so it's unclear whether the pointer returned is valid in that case. Of course you won't be able to read/write actual bytes to/from it since the capacity is 0, but there's an exception: zero sized read/writes. They are still valid as long as the pointer is not null and the memory it points to wasn't deallocated, but `Vec::as_ptr` and `Vec::as_mut_ptr` don't specify that's not the case. This PR thus specifies they are actually valid for zero sized reads since `Vec` is implemented to hold a dangling pointer in those cases, which is neither null nor was deallocated.
Miguel Ojeda [Tue, 31 May 2022 10:28:57 +0000 (12:28 +0200)]
alloc: remove repeated word in comment
Linux's `checkpatch.pl` reports:
```txt
#42544: FILE: rust/alloc/vec/mod.rs:2692:
WARNING: Possible repeated word: 'to'
+ // - Elements are :Copy so it's OK to to copy them, without doing
```
bors [Tue, 31 May 2022 09:34:00 +0000 (09:34 +0000)]
Auto merge of #97526 - Nilstrieb:unicode-is-printable-fastpath, r=joshtriplett
Add unicode fast path to `is_printable`
Before, it would enter the full expensive check even for normal ascii characters. Now, it skips the check for the ascii characters in `32..127`. This range was checked manually from the current behavior.
I ran the `tracing` test suite in miri, and it was really slow. I looked at a profile, and miri spent most of the time in `core::char::methods::escape_debug_ext`, where half of that was dominated by `core::unicode::printable::is_printable`. So I optimized it here.
Nilstrieb [Sun, 29 May 2022 17:21:57 +0000 (19:21 +0200)]
Add unicode fast path to `is_printable`
Before, it would enter the full expensive check even for normal ascii
characters. Now, it skips the check for the ascii characters in
`32..127`. This range was checked manually from the current behavior.
bors [Tue, 31 May 2022 06:53:02 +0000 (06:53 +0000)]
Auto merge of #97574 - Dylan-DPC:rollup-jq850l6, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #97089 (Improve settings theme display)
- #97229 (Document the current aliasing rules for `Box<T>`.)
- #97371 (Suggest adding a semicolon to a closure without block)
- #97455 (Stabilize `toowned_clone_into`)
- #97565 (Add doc alias `memset` to `write_bytes`)
- #97569 (Remove `memset` alias from `fill_with`.)
Dylan DPC [Tue, 31 May 2022 05:57:37 +0000 (07:57 +0200)]
Rollup merge of #97569 - thomcc:fill_with_isnt_memset, r=Amanieu
Remove `memset` alias from `fill_with`.
In https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Unsafe.20and.20Safe.20versions.20of.20APIs.20both.20getting.20the.20same.20alias/near/284413029 `@Amanieu` pointed out that we had this, which is not really right.
In our guidelines we say that we will "not add an alias for a function that's only somewhat similar or related", which applies here. Memset doesn't take a closure, not even conceptually.
Dylan DPC [Tue, 31 May 2022 05:57:36 +0000 (07:57 +0200)]
Rollup merge of #97565 - lukas-code:patch-1, r=thomcc
Add doc alias `memset` to `write_bytes`
I were looking for `memset` in rust, but the docs only pointed me to `slice::fill`.
With only the old aliases, one might write code like this, which is incorrect if the memory is uninitialized.
``` Rust
core::slice::from_raw_parts(ptr, len).fill(0)
```
Dylan DPC [Tue, 31 May 2022 05:57:33 +0000 (07:57 +0200)]
Rollup merge of #97229 - Nilstrieb:doc-box-noalias, r=dtolnay
Document the current aliasing rules for `Box<T>`.
Currently, `Box<T>` gets `noalias`, meaning it has the same rules as `&mut T`. This is sparsely documented, even though it can have quite a big impact on unsafe code using box. Therefore, these rules are documented here, with a big warning that they are not normative and subject to change, since we have not yet committed to an aliasing model and the state of `Box<T>` is especially uncertain.
If you have any suggestions and improvements, make sure to leave them here. This is mostly intended to inform people about what is currently going on (to prevent misunderstandings such as [Jon Gjengset's Box aliasing](https://www.youtube.com/watch?v=EY7Wi9fV5bk)).
This is supposed to _only document current UB_ and not add any new guarantees or rules.
bors [Tue, 31 May 2022 01:17:00 +0000 (01:17 +0000)]
Auto merge of #97566 - compiler-errors:rollup-qfxw4j8, r=compiler-errors
Rollup of 6 pull requests
Successful merges:
- #89685 (refactor: VecDeques Iter fields to private)
- #97172 (Optimize the diagnostic generation for `extern unsafe`)
- #97395 (Miri call ABI check: ensure type size+align stay the same)
- #97431 (don't do `Sized` and other return type checks on RPIT's real type)
- #97555 (Source code page: line number click adds `NaN`)
- #97558 (Fix typos in comment)
Michael Goulet [Mon, 30 May 2022 22:57:30 +0000 (15:57 -0700)]
Rollup merge of #97555 - GuillaumeGomez:line-number-click, r=notriddle
Source code page: line number click adds `NaN`
When you click on the parent element of the line numbers in the source code pages, it'll add `NaN` (like in https://doc.rust-lang.org/nightly/src/alloc/lib.rs.html#NaN). This PR fixes this bug.
Michael Goulet [Mon, 30 May 2022 22:57:29 +0000 (15:57 -0700)]
Rollup merge of #97431 - compiler-errors:issue-97413, r=oli-obk
don't do `Sized` and other return type checks on RPIT's real type
Fixes an ICE where we're doing `Sized` check against the RPIT's real type, instead of against the opaque type. This differs from what we're doing in MIR typeck, which causes ICE #97226.
This regressed in #96516 -- this adjusts that fix to be a bit more conservative. That PR was backported and thus the ICE is also present in stable. Not sure if it's worth to beta and/or stable backport, probably not the latter but I could believe the former.
r? `@oli-obk`
cc: another attempt to fix this ICE #97413. I believe this PR addresses the root cause.
projects / rust.git / log