Uh oh!
There was an error while loading. Please reload this page.
Rollup of 10 pull requests - #75388
Merged
Merged
Conversation
Renamed remaining references to "undef" to "uninit" when referring to Miri. Impacted directories are: - src/librustc_codegen_llvm/consts.rs - src/librustc_middle/mir/interpret/ - src/librustc_middle/ty/print/pretty.rs - src/librustc_mir/ - src/tools/clippy/clippy_lints/src/consts.rs Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project. Related issue rust-lang#71193
The old implementation only looks at numbers at the end, but not in other places in a name: "u8" and "u16" got sorted properly, but "u8_bla" and "u16_bla" did not.
When we have a tuple struct used with struct we don't want to suggest using
the (valid) struct syntax with numeric field names. Instead we want to
suggest the expected syntax.
Given
```rust
fn main() {
match MyOption::MySome(42) {
MyOption::MySome { x: 42 } => (),
_ => (),
}
}
```
We now emit E0769 "tuple variant `MyOption::MySome` written as struct variant"
instead of E0026 "variant `MyOption::MySome` does not have a field named `x`".Remove unnecessary `unwrap`.
The old code already made the assumption to reinterpret `Ipv6Addr` as `[u16; 8]`. Glibc, Linux, FreeBSD, Win32 all makes this assumption. The main motivation of using union it to better optimize code. ref: * https://docs.microsoft.com/en-us/windows/win32/api/in6addr/ns-in6addr-in6_addr * https://github.com/freebsd/freebsd/blob/1d6e4247415d264485ee94b59fdbc12e0c566fd0/contrib/ntp/lib/isc/include/isc/ipv6.h#L63 * https://github.com/zephyrproject-rtos/zephyr/blob/8b531aa996bba254c03129658490af59597acd78/include/net/net_ip.h#L137 * https://sourceware.org/git/?p=glibc.git;a=blob;f=inet/netinet/in.h;h=f6355c7efe5192b88337b136ef687fe9a5ed648c;hb=HEAD#l216 Co-authored-by: Josh Stone <cuviper@gmail.com> Co-authored-by: Peter Atashian <retep998@gmail.com>
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com> Co-authored-by: Lonami <totufals@hotmail.com>
Even though the description is clear but the solution may not be as straightforward. Adding a suggested fix.
This commit constrains the support added for handling unevaluated consts in polymorphization (introduced in rust-lang#75260) by: - Skipping associated constants as this causes cycle errors. - Skipping promoted constants when they contain `Self` as this ensures `T` is used in constants of the form `<Self as Foo<T>>`. Signed-off-by: David Wood <david@davidtw.co>
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
…Simulacrum Update RELEASES.md for 1.46.0 ### [Rendered](https://github.com/XAMPPRocky/rust/blob/relnotes-1.46.0/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release
Transmute big endian `s6_addr` and `[u16; 8]` The old code already made the assumption to reinterpret `Ipv6Addr` as `[u16; 8]`. Glibc, Linux, FreeBSD, Win32 all makes this assumption. The main motivation of using union it to better optimize code. Godbolt: https://rust.godbolt.org/z/b4bGvo Const is introducing unsafe when transmuting. ref: * https://docs.microsoft.com/en-us/windows/win32/api/in6addr/ns-in6addr-in6_addr * https://github.com/freebsd/freebsd/blob/1d6e4247415d264485ee94b59fdbc12e0c566fd0/contrib/ntp/lib/isc/include/isc/ipv6.h#L63 * https://github.com/zephyrproject-rtos/zephyr/blob/8b531aa996bba254c03129658490af59597acd78/include/net/net_ip.h#L137 * https://sourceware.org/git/?p=glibc.git;a=blob;f=inet/netinet/in.h;h=f6355c7efe5192b88337b136ef687fe9a5ed648c;hb=HEAD#l216
Miri: Renamed "undef" to "uninit" Renamed remaining references to "undef" to "uninit" when referring to Miri. Impacted directories are: - `src/librustc_codegen_llvm/consts.rs` - `src/librustc_middle/mir/interpret/` - `src/librustc_middle/ty/print/pretty.rs` - `src/librustc_mir/` - `src/tools/clippy/clippy_lints/src/consts.rs` Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project. Related issue rust-lang#71193
…xes, r=lcnr polymorphize: constrain unevaluated const handling This PR constrains the support added for handling unevaluated consts in polymorphization (introduced in rust-lang#75260) by: - Skipping associated constants as this causes cycle errors. - Skipping promoted constants when they contain `Self` as this ensures `T` is used in constants of the form `<Self as Foo<T>>`. Due to an oversight on my part, when landing rust-lang#75260 and rust-lang#75255, some tests started failing when polymorphization was enabled that I didn't notice until after landing - this PR fixes the regressions from rust-lang#75260. r? @lcnr
…k, r=oli-obk move stack size check to const_eval machine This is consistent with how we enforce the step limit. In particular, we do not want this limit checked for Miri-the-tool.
…t-sort, r=GuillaumeGomez Rustdoc: Fix natural ordering to look at all numbers. The old implementation only looks at numbers at the end, but not in other places in a name: `u8` and `u16` got sorted properly, but `u8_bla` and `u16_bla` did not. 
…, r=oli-obk
Tweak conditions for E0026 and E0769
When we have a tuple struct used with struct we don't want to suggest using the (valid) struct syntax with numeric field names. Instead we want to suggest the expected syntax.
Given
```rust
fn main() {
match MyOption::MySome(42) {
MyOption::MySome { x: 42 } => (),
_ => (),
}
}
```
We now emit E0769 "tuple variant `MyOption::MySome` written as struct variant" instead of E0026 "variant `MyOption::MySome` does not have a field named `x`".Tiny cleanup, remove unnecessary `unwrap` Remove unnecessary `unwrap`.
unused_delims: trim expr improves rustfix output.
Add sample fix for E0749 Even though the description is clear but the solution may not be as straightforward. Adding a suggested fix from documentation side. r? @GuillaumeGomez However, this suggestion should be shown in rustc itself for easy fix, the documentation should also reflect on the changes in rustc. Currently, ``` error[E0749]: negative impls cannot have any items --> test.rs:6:5 | 6 | type Foo = i32; // error! | ^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0749`. ``` rustc should tell the user to remove it.
JohnTitor
commented
Aug 11, 2020
MemberAuthor
bors
commented
Aug 11, 2020
Collaborator
📌 Commit 5320028 has been approved by |
bors
commented
Aug 11, 2020
Collaborator
⌛ Testing commit 5320028 with merge 6ccb1f6a720e2f9371869c96890f7f6f22476d82... |
bors
commented
Aug 11, 2020
Collaborator
💔 Test failed - checks-azure |
JohnTitor
commented
Aug 11, 2020
MemberAuthor
@bors retry |
bors
commented
Aug 11, 2020
Collaborator
bors
commented
Aug 11, 2020
Collaborator
☀️ Test successful - checks-actions, checks-azure |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
s6_addrand[u16; 8]#75085 (Transmute big endians6_addrand[u16; 8])unwrap#75353 (Tiny cleanup, remove unnecessaryunwrap)Failed merges:
r? @ghost