Fix issue 85435 by restricting Fake Read precision #55
Conversation
This file contains 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
This should do roughly the same as the TrustedLen specialization but result in less IR by using __iterator_get_unchecked instead of iterator.for_each.
…d anywhere and sugetion of type with method when found.
Clarify error returns from Mutex::try_lock, RwLock::try_read, RwLock::try_write to make it more obvious that both poisoning and the lock being already locked are possible errors.
(and thus exposed underlying issue rust-lang#85561).
(removing confusing comment from my test, since the comment reflects the bad undesirable behavior that is being fixed here.)
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
Moves all the state into a struct so it doesn't need to be passed around as much. Also adds a report showing how long it took and what it found. This includes a minor change: a failure to load a file is now an error, instead of being ignored. This should only happen if there is a permission error or some other shenanigans going on.
Use "the `WouldBlock` error" instead of "the error `WouldBlock`", etc.
test THIR unsafeck too Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
…crum Optimize linkchecker and add report. This makes three changes to the linkchecker: * Adds a report displayed after it finishes. * Improves the performance by caching all filesystem access. The linkchecker can take over a minute to run on some systems, and this should make it about 2-3 times faster. * Added a few tests.
Type aliases are linted as such, so (unstable) trait aliases should be treated the same way.
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
…estebank E0599 suggestions and elision of generic argument if no canditate is found fixes rust-lang#81576 changes: In error E0599 (method not found) generic argument are eluded if the method was not found anywhere. If the method was found in another inherent implementation suggest that it was found elsewhere. Example ```rust struct Wrapper<T>(T); struct Wrapper2<T> { x: T, } impl Wrapper2<i8> { fn method(&self) {} } fn main() { let wrapper = Wrapper(i32); wrapper.method(); let wrapper2 = Wrapper2{x: i32}; wrapper2.method(); } ``` ``` Error[E0599]: no method named `method` found for struct `Wrapper<_>` in the current scope .... error[E0599]: no method named `method` found for struct `Wrapper2<i32>` in the current scope ... = note: The method was found for Wrapper2<i8>. ``` I am not very happy with the ```no method named `test` found for struct `Vec<_, _>` in the current scope```. I think it might be better to show only one generic argument `Vec<_>` if there is a default one. But I haven't yet found a way to do that,
…raints-61997, r=jackh726 stabilize member constraints Stabilizes the use of "member constraints" in solving `impl Trait` bindings. This is a step towards stabilizing a "MVP" of "named impl Trait". # Member constraint stabilization report | Info | | | --- | --- | | Tracking issue | [rust-lang#61997](rust-lang#61997) | | Implementation history | [rust-lang#61775] | | rustc-dev-guide coverage | [link](https://rustc-dev-guide.rust-lang.org/borrow_check/region_inference/member_constraints.html) | | Complications | [rust-lang#61773] | [rust-lang#61775]: rust-lang#61775 [rust-lang#61773]: rust-lang#61773 ## Background Member constraints are an extension to our region solver that was introduced to make async fn region solving tractable. There are used in situations like the following: ```rust fn foo<'a, 'b>(...) -> impl Trait<'a, 'b> { .. } ``` The problem here is that every region R in the hidden type must be equal to *either* `'a` *or* `'b` (or `'static`). This cannot be expressed simply via 'outlives constriants' like `R: 'a`. Therefore, we introduce a 'member constraint' `R member of ['a, 'b]`. These constraints were introduced in [rust-lang#61775]. At the time, we kept them feature gated and used them only for `impl Trait` return types that are derived from `async fn`. The intention, however, was always to support them in other contexts once we had time to gain more experience with them. **In the time since their introduction, we have encountered no surprises or bugs due to these member constraints.** They are tested extensively as part of every async function that involves multiple unrelated lifetimes in its arguments. ## Tests The behavior of member constraints is covered by the following tests: * [`src/test/ui/async-await/multiple-lifetimes`](https://github.com/rust-lang/rust/tree/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/async-await/multiple-lifetimes) -- tests using the async await, which are mostly already stabilized * [`src/test/ui/impl-trait/multiple-lifetimes.rs`](https://github.com/rust-lang/rust/blob/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/impl-trait/multiple-lifetimes.rs) * [`src/test/ui/impl-trait/multiple-lifetimes/ordinary-bounds-unsuited.rs`](https://github.com/rust-lang/rust/blob/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/impl-trait/multiple-lifetimes/ordinary-bounds-unsuited.rs) * [`src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-fg.rs`](https://github.com/rust-lang/rust/blob/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-fg.rs) * [`src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-one.rs`](https://github.com/rust-lang/rust/blob/20e032e65007ff1376e8480c1fbdb0a5068028fa/src/test/ui/async-await/multiple-lifetimes/ret-impl-trait-one.rs) These tests cover a number of scenarios: * `-> implTrait<'a, 'b>` with unrelated lifetimes `'a` and `'b`, as described above * `async fn` that returns an `impl Trait` like the previous case, which desugars to a kind of "nested" impl trait like `impl Future<Output = impl Trait<'a, 'b>>` ## Potential concerns There is a potential interaction with `impl Trait` on local variables, described in [rust-lang#61773]. The challenge is that if you have a program like: ```rust= trait Foo<'_> { } impl Foo<'_> for &u32 { } fn bar() { let x: impl Foo<'_> = &44; // let's call the region variable for `'_` `'1` } ``` then we would wind up with `'0 member of ['1, 'static]`, where `'0` is the region variable in the hidden type (`&'0 u32`) and `'1` is the region variable in the bounds `Foo<'1>`. This is tricky because both `'0` and `'1` are being inferred -- so making them equal may have other repercussions. That said, `impl Trait` in bindings are not stable, and the implementation is pretty far from stabilization. Moreover, the difficulty highlighted here is not due to the presence of member constraints -- it's inherent to the design of the language. In other words, stabilizing member constraints does not actually cause us to accept anything that would make this problem any harder. So I don't see this as a blocker to stabilization of member constraints; it is potentially a blocker to stablization of `impl trait` in let bindings.
…disjoint-fields-gate, r=nikomatsakis readd capture disjoint fields gate This readds a feature gate guard that was added in PR rust-lang#83521. (Basically, there were unintended consequences to the code exposed by removing the feature gate guard.) The root bug still remains to be resolved, as discussed in issue rust-lang#85561. This is just a band-aid suitable for a beta backport. Cc issue rust-lang#85435 Note that the latter issue is unfixed until we backport this (or another fix) to 1.53 beta
…nkov Get rid of PreviousDepGraph. Its only role is to access the `SerializedDepGraph`.
Update cc Recent commits have improved `cc`'s finding of MSVC tools on Windows. In particular it should help to address these issues: rust-lang#83043 and rust-lang#43468
Remove Iterator #[rustc_on_unimplemented]s that no longer apply.
Now that `IntoIterator` is implemented for arrays, all the `rustc_on_unimplemented` for arrays of ranges (e.g. `for _ in [1..3] {}`) no longer apply, since they are now valid Rust.
Separated these from rust-lang#85670, because we should discuss a potential new (clippy?) lint for these.
Until Rust 1.52, `for _ in [1..3] {}` produced:
```
error[E0277]: `[std::ops::Range<{integer}>; 1]` is not an iterator
--> src/main.rs:2:14
|
2 | for _ in [1..3] {}
| ^^^^^^ if you meant to iterate between two values, remove the square brackets
|
= help: the trait `std::iter::Iterator` is not implemented for `[std::ops::Range<{integer}>; 1]`
= note: `[start..end]` is an array of one `Range`; you might have meant to have a `Range` without the brackets: `start..end`
= note: required by `std::iter::IntoIterator::into_iter`
```
But in Rust 1.53 and later, it compiles fine. It iterates over the array by value, for one iteration with the element `1..3`.
This is probably a mistake, which is no longer caught. Should we have a lint for it? Should Clippy have a lint for it?
cc ```@estebank``` ```@flip1995```
cc rust-lang#84513
…r=m-ou-se Add inline attr to CString::into_inner so it can optimize out NonNull checks It seems that currently if you convert any of the standard library's container to a pointer and then to a NonNull pointer, all will optimize out the NULL check except `CString`(https://godbolt.org/z/YPKW9G5xn), because for some reason `CString::into_inner` isn't inlined even though it's a private function that should compile into a simple `mov` instruction. Adding a simple `#[inline]` attribute solves this, code example: ```rust use std::ffi::CString; use std::ptr::NonNull; pub fn cstring_nonull(mut n: CString) -> NonNull<i8> { NonNull::new(CString::into_raw(n)).unwrap() } ``` assembly before: ```asm __ZN3wat14cstring_nonull17h371c755bcad76294E: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp callq __ZN3std3ffi5c_str7CString10into_inner17h28ece07b276e2878E testq %rax, %rax je LBB0_2 popq %rbp retq LBB0_2: leaq l___unnamed_1(%rip), %rdi leaq l___unnamed_2(%rip), %rdx movl $43, %esi callq __ZN4core9panicking5panic17h92a83fa9085a8f73E .cfi_endproc .section __TEXT,__const l___unnamed_1: .ascii "called `Option::unwrap()` on a `None` value" l___unnamed_3: .ascii "wat.rs" .section __DATA,__const .p2align 3 l___unnamed_2: .quad l___unnamed_3 .asciz "\006\000\000\000\000\000\000\000\006\000\000\000(\000\000" ``` Assembly after: ```asm __ZN3wat14cstring_nonull17h9645eb9341fb25d7E: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp movq %rdi, %rax popq %rbp retq .cfi_endproc ``` (Related discussion on zulip: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/NonNull.20From.3CBox.3CT.3E.3E)
…fJung Remove unneeded workaround This removes a workaround for rust-lang#24159, which has been fixed.
Rollup of 8 pull requests Successful merges: - rust-lang#84221 (E0599 suggestions and elision of generic argument if no canditate is found) - rust-lang#84701 (stabilize member constraints) - rust-lang#85564 ( readd capture disjoint fields gate) - rust-lang#85583 (Get rid of PreviousDepGraph.) - rust-lang#85649 (Update cc) - rust-lang#85689 (Remove Iterator #[rustc_on_unimplemented]s that no longer apply.) - rust-lang#85719 (Add inline attr to CString::into_inner so it can optimize out NonNull checks) - rust-lang#85725 (Remove unneeded workaround) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
libunwind fix and cleanup Fix: 1. "system-llvm-libunwind" now only skip build-script for linux target 2. workaround from rust-lang#65972 is not needed, upstream fix it in llvm/llvm-project@68c5070 ( LLVM 11 ) 3. remove code for MSCV and Apple in `compile()`, as they are not used 4. fix rust-lang#69222 , compile c files and cpp files in different config 5. fix conditional compilation for musl target. 6. fix that x86_64-fortanix-unknown-sgx don't link libunwind built in build-script into rlib
…r=varkor Lint against non-CamelCase trait alias names Type aliases are linted as such, so (unstable) trait aliases should be treated the same way.
…=m-ou-se Enable Vec's calloc optimization for Option<NonZero> Someone on discord noticed that `vec![None::<NonZeroU32>; N]` wasn't getting the optimization, so here's a PR 🙃 We can certainly do this in the standard library because we know for sure this is ok, but I think it's also a necessary consequence of documented guarantees like those in https://doc.rust-lang.org/std/option/#representation and https://doc.rust-lang.org/core/num/struct.NonZeroU32.html It feels weird to do this without adding a test, but I wasn't sure where that would belong. Is it worth adding codegen tests for these?
Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
…atsakis Don't hash `thir_body` Experiment to see if/how much this helps negate the perf impact of rust-lang#85273. r? `@ghost`
Fix trait methods' toggle A `<details>` tag wasn't closed on trait methods, which created broken DOM. I also used this occasion to only generate the toggle in case there is documentation on the method. r? `@jsha`
…u-se
Mention workaround for floats in Iterator::{min, max}
`Iterator::{min, max}` can't be used with iterators of floats due to NaN issues. This suggests a workaround in the documentation of those functions.
Rename opensbd to openbsd OpenBsd was sometimes spelled "opensbd" in the standard library.
…laumeGomez Rollup of 3 pull requests Successful merges: - rust-lang#85722 (Fix trait methods' toggle) - rust-lang#85730 (Mention workaround for floats in Iterator::{min, max}) - rust-lang#85738 (Rename opensbd to openbsd) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
roxelo
force-pushed
the
rox-fix-issue-85435
branch
from
31d38f9 to
382338f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.