- 23 6月, 2020 20 次提交
-
-
由 Manish Goregaokar 提交于
Account for multiple impl/dyn Trait in return type when suggesting `'_` Make `impl` and `dyn` Trait lifetime suggestions a bit more resilient. Follow up to #72804. r? @nikomatsakis
-
由 Manish Goregaokar 提交于
Clean up E0689 explanation r? @Dylan-DPC
-
由 Manish Goregaokar 提交于
A way forward for pointer equality in const eval r? @varkor on the first commit and @RalfJung on the second commit cc #53020
-
由 Manish Goregaokar 提交于
move leak-check to during coherence, candidate eval Implementation of MCP https://github.com/rust-lang/compiler-team/issues/295. I'd like to do a crater run on this. Note to @rust-lang/lang: This PR is a breaking change (bugfix). It causes tests like the following to go from a future-compatibility warning #56105 to a hard error: ```rust trait Trait {} impl Trait for for<'a, 'b> fn(&'a u32, &'b u32) {} impl Trait for for<'c> fn(&'c u32, &'c u32) {} // now rejected, used to warn ``` I am not aware of any instances of this code in the wild, but that is why we are doing a crater run. The reason for this change is that those two types are, in fact, the same type, and hence the two impls are overlapping. There will still be impls that trigger #56105 after this lands, however -- I hope that we will eventually just accept those impls without warning, for the most part. One example of such an impl is this pattern, which is used by wasm-bindgen and other crates as well: ```rust trait Trait {} impl<T> Trait for fn(&T) { } impl<T> Trait for fn(T) { } // still accepted, but warns ```
-
由 Manish Goregaokar 提交于
Improve compiler error message for wrong generic parameter order - Added optional "help" parameter that shows a help message on the compiler error if required. - Added a simple ordered parameter as a sample help. @varkor will make more changes as required. Let me know if I'm heading in the right direction. Fixes #68437 r? @varkor
-
由 bors 提交于
impl ToSocketAddrs for (String, u16) This adds a convenience impl of `ToSocketAddrs for (String, u16)`. When authoring HTTP services it's common to take command line options for `host` and `port` and parse them into `String` and `u16` respectively. Consider the following program: ```rust #[derive(Debug, StructOpt)] struct Config { host: String, port: u16, } async fn main() -> io::Result<()> { let config = Config::from_args(); let stream = TcpStream::connect((&*config.host, config.port))?; // &* is not ideal // ... } ``` Networking is a pretty common starting point for people new to Rust, and seeing `&*` in basic examples can be confusing. Even as someone that has experience with networking in Rust I tend to forget that `String` can't be passed directly there. Instead with this patch we can omit the `&*` conversion and pass `host` directly: ```rust #[derive(Debug, StructOpt)] struct Config { host: String, port: u16, } async fn main() -> io::Result<()> { let config = Config::from_args(); let stream = TcpStream::connect((config.host, config.port))?; // no more conversions! // ... } ``` I think should be an easy and small ergonomics improvement for networking. Thanks!
-
由 Esteban Küber 提交于
-
由 bors 提交于
Revert PR #72389 - "Explain move errors that occur due to method calls involving `self" r? @petrochenkov
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
The bug was revealed by the behavior of the old-lub-glb-hr-noteq1.rs test. The old-lub-glb-hr-noteq2 test shows the current 'order dependent' behavior of coercions around higher-ranked functions, at least when running with `-Zborrowck=mir`. Also, run compare-mode=nll.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
Motivation: - we want to use leak-check sparingly, first off - these calls were essentially the same as doing the check during subtyping
-
由 Aaron Hill 提交于
None of the tools seem to need syn 0.15.35, so we can just build syn 1.0. This was causing an issue with clippy's `compile-test` program: since multiple versions of `syn` would exist in the build directory, we would non-deterministically pick one based on filesystem iteration order. If the pre-1.0 version of `syn` was picked, a strange build error would occur (see https://github.com/rust-lang/rust/pull/73594#issuecomment-647671463) To prevent this kind of issue from happening again, we now panic if we find multiple versions of a crate in the build directly, instead of silently picking the first version we find.
-
由 Aaron Hill 提交于
-
由 Aaron Hill 提交于
This reverts commit 372cb9b6, reversing changes made to 5c61a8dc.
-
由 bors 提交于
Update cargo 3 commits in 79c769c3d7b4c2cf6a93781575b7f592ef974255..089cbb80b73ba242efdcf5430e89f63fa3b5328d 2020-06-11 22:13:37 +0000 to 2020-06-15 14:38:34 +0000 - Support linker with -Zdoctest-xcompile. (rust-lang/cargo#8359) - Fix doctests not running with --target=HOST. (rust-lang/cargo#8358) - Allow passing a registry index url directly to `cargo install` (rust-lang/cargo#8344)
-
- 22 6月, 2020 15 次提交
-
-
由 Niko Matsakis 提交于
Revert the code that states that upcasting traits requires full equality and change to require that the source type is a subtype of the target type, as one would expect. As the comment states, this was an old bug that we didn't want to fix yet as it interacted poorly with the old leak-check. This fixes the old-lub-glb-object test, which was previously reporting too many errors (i.e., in the previous commit).
-
由 Niko Matsakis 提交于
In particular, it no longer occurs during the subtyping check. This is important for enabling lazy normalization, because the subtyping check will be producing sub-obligations that could affect its results. Consider an example like for<'a> fn(<&'a as Mirror>::Item) = fn(&'b u8) where `<T as Mirror>::Item = T` for all `T`. We will wish to produce a new subobligation like <'!1 as Mirror>::Item = &'b u8 This will, after being solved, ultimately yield a constraint that `'!1 = 'b` which will fail. But with the leak-check being performed on subtyping, there is no opportunity to normalize `<'!1 as Mirror>::Item` (unless we invoke that normalization directly from within subtyping, and I would prefer that subtyping and unification are distinct operations rather than part of the trait solving stack). The reason to keep the leak check during coherence and trait evaluation is partly for backwards compatibility. The coherence change permits impls for `fn(T)` and `fn(&T)` to co-exist, and the trait evaluation change means that we can distinguish those two cases without ambiguity errors. It also avoids recreating #57639, where we were incorrectly choosing a where clause that would have failed the leak check over the impl which succeeds. The other reason to keep the leak check in those places is that I think it is actually close to the model we want. To the point, I think the trait solver ought to have the job of "breaking down" higher-ranked region obligation like ``!1: '2` into into region obligations that operate on things in the root universe, at which point they should be handed off to polonius. The leak check isn't *really* doing that -- these obligations are still handed to the region solver to process -- but if/when we do adopt that model, the decision to pass/fail would be happening in roughly this part of the code. This change had somewhat more side-effects than I anticipated. It seems like there are cases where the leak-check was not being enforced during method proving and trait selection. I haven't quite tracked this down but I think it ought to be documented, so that we know what precisely we are committing to. One surprising test was `issue-30786.rs`. The behavior there seems a bit "fishy" to me, but the problem is not related to the leak check change as far as I can tell, but more to do with the closure signature inference code and perhaps the associated type projection, which together seem to be conspiring to produce an unexpected signature. Nonetheless, it is an example of where changing the leak-check can have some unexpected consequences: we're now failing to resolve a method earlier than we were, which suggests we might change some method resolutions that would have been ambiguous to be successful. TODO: * figure out remainig test failures * add new coherence tests for the patterns we ARE disallowing
-
由 Niko Matsakis 提交于
In the new leak check, instead of getting a list of placeholders to track, we look for any placeholder that is part of a universe which was created during the snapshot. We are looking for the following error patterns: * P1: P2, where P1 != P2 * P1: R, where R is in some universe that cannot name P1 This new leak check is more precise than before, in that it accepts this patterns: * R: P1, even if R cannot name P1, because R = 'static is a valid sol'n * R: P1, R: P2, as above Note that this leak check, when running during subtyping, is less efficient than before in some sense because it is going to check and re-check all the universes created since the snapshot. We're going to move when the leak check runs to try and correct that.
-
由 Niko Matsakis 提交于
This reverts commit 2e01db4b396a1e161f7a73933fff34bc9421dba0.
-
由 Niko Matsakis 提交于
Also, update the affected tests. This seems strictly better but it is actually more permissive than I initially intended. In particular it accepts this ``` forall<'a, 'b> { exists<'intersection> { 'a: 'intersection, 'b: 'intersection, } } ``` and I'm not sure I want to accept that. It implies that we have a `'empty` in the new universe intoduced by the `forall`.
-
由 bors 提交于
Rollup of 6 pull requests Successful merges: - #71660 (impl PartialEq<Vec<B>> for &[A], &mut [A]) - #72623 (Prefer accessible paths in 'use' suggestions) - #73502 (Add E0765) - #73580 (deprecate wrapping_offset_from) - #73582 (Miri: replace many bug! by span_bug!) - #73585 (Do not send a notification for P-high stable regressions) Failed merges: - #73581 (Create 0766 error code) r? @ghost
-
由 Dylan DPC 提交于
Do not send a notification for P-high stable regressions This is kind of a hack to only match nightly and beta regressions, but not stable regressions. See my tests [on the playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6ff8a809162118aa2951f2ff12400067). r? @spastorino cc @Mark-Simulacrum
-
由 Dylan DPC 提交于
Miri: replace many bug! by span_bug! r? @oli-obk
-
由 Dylan DPC 提交于
deprecate wrapping_offset_from As per https://github.com/rust-lang/rust/issues/41079#issuecomment-433140733 which seems like a consensus. r? @Amanieu
-
由 Dylan DPC 提交于
Add E0765
-
由 Dylan DPC 提交于
Prefer accessible paths in 'use' suggestions This PR addresses issue https://github.com/rust-lang/rust/issues/26454, where `use` suggestions are made for paths that don't work. For example: ```rust mod foo { mod bar { struct X; } } fn main() { X; } // suggests `use foo::bar::X;` ```
-
由 Dylan DPC 提交于
impl PartialEq<Vec<B>> for &[A], &mut [A] https://github.com/rust-lang/rfcs/issues/2917
-
由 LeSeulArtichaut 提交于
Add comment to clarify the pattern
-
由 bors 提交于
Upgrade Chalk Things done in this PR: - Upgrade Chalk to `0.11.0` - Added compare-mode=chalk - Bump rustc-hash in `librustc_data_structures` to `1.1.0` to match Chalk - Removed `RustDefId` since the builtin type support is there - Add a few more `FIXME(chalk)`s for problem spots I hit when running all tests with chalk - Added some more implementation code for some newer builtin Chalk types (e.g. `FnDef`, `Array`) - Lower `RegionOutlives` and `ObjectSafe` predicates - Lower `Dyn` without the region - Handle `Int`/`Float` `CanonicalVarKind`s - Uncomment some Chalk tests that actually work now - Remove the revisions in `src/test/ui/coherence/coherence-subtyping.rs` since they aren't doing anything different r? @nikomatsakis
-
- 21 6月, 2020 5 次提交
-
-
由 Dan Aloni 提交于
This fixes an issue with the following sample: mod foo { mod inaccessible { pub struct X; } pub mod avail { pub struct X; } } fn main() { X; } Instead of suggesting both `use crate::foo::inaccessible::X;` and `use crate::foo::avail::X;`, it should only suggest the latter. It is done by trimming the list of suggestions from inaccessible paths if accessible paths are present. Visibility is checked with `is_accessible_from` now instead of being hard-coded. - Some tests fixes are trivial, and others require a bit more explaining, here are my comments: src/test/ui/issues/issue-35675.stderr: Only needs to make the enum public to have the suggestion make sense. src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't help because its constructor is not visible, so the attempted constructor does not work. In that case, it's better not to suggest it. The case where the constructor is public is covered in `issue-26545.rs`.
-
由 Guillaume Gomez 提交于
-
由 Ralf Jung 提交于
-
由 bors 提交于
Enable LLVM zlib Compilers may generate ELF objects with compressed sections (although rustc currently doesn't do this). Currently, when linking these with `rust-lld`, you'll get this error: `rust-lld: error: ...: contains a compressed section, but zlib is not available` This enables zlib when building LLVM.
-
由 Guillaume Gomez 提交于
-