[WIP] Use `Into::into` in operator `?` #60796

cuviper · 2019-05-13T20:37:48Z

#38751 proposes using into for ?, and while commenters suggested problems with inference, I couldn't find any evidence where this was actually attempted -- so here we go!

rust-highfive · 2019-05-13T20:37:52Z

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

cuviper · 2019-05-13T20:38:11Z

So yes, it did break inference in quite a few places in librustc itself -- mostly where type-inferred closures are involved using ? within and on their result. These are possible to annotate, as shown here in followup commits, but might be painful for the ecosystem. Maybe the compiler can do better about inferring the identity case? It seems like it must be doing that for From already.

In librustc_metadata, a stranger error arises:

error[E0277]: `?` couldn't convert the error to `!`
   --> src/librustc_metadata/encoder.rs:106:33
    |
106 |         self.emit_usize(seq.len)?;
    |                                 ^
    |                                 |
    |                                 the trait `std::convert::From<()>` is not implemented for `!`
    |                                 in this expansion of `desugaring of `?``
    |                                 in this macro invocation
    |
    = note: the trait is implemented for `()`. Possibly this error has been caused by changes to Rust's type-inference algorithm (see: https://github.com/rust-lang/rust/issues/48950 for more info). Consider whether you meant to use the type `()` here instead.
    = note: required because of the requirements on the impl of `std::convert::Into<!>` for `()`
    = note: required by `std::convert::Into::into`

rust/src/librustc_metadata/encoder.rs

Lines 104 to 112 in 6968e77

    
           impl<'a, 'tcx, T> SpecializedEncoder<LazySeq<T>> for EncodeContext<'a, 'tcx> { 
        
               fn specialized_encode(&mut self, seq: &LazySeq<T>) -> Result<(), Self::Error> { 
        
                   self.emit_usize(seq.len)?; 
        
                   if seq.len == 0 { 
        
                       return Ok(()); 
        
                   } 
        
                   self.emit_lazy_distance(seq.position, LazySeq::<T>::min_size(seq.len)) 
        
               } 
        
           }

AFAICT it should be both getting and returning Self::Error -- which is ! -- so I'm not sure where () is coming from. Perhaps this is some lurking issue with the never type?

cuviper · 2019-05-13T22:24:50Z

I found the same From<()> error in the commit message of b2cf9a0 -- cc @SimonSapin. It does go away if I opt that crate into #![feature(never_type)], so I've done that now, if only as a workaround for testing purposes.

cuviper · 2019-05-14T20:11:47Z

Now that I have a green check mark, I'm moving to S-waiting-on-team to evaluate feasibility, please.

Centril · 2019-05-14T21:17:01Z

I'd like to a see a crater run to see what sort of breakage we are talking about.

Centril · 2019-05-17T20:05:35Z

@bors try

bors · 2019-05-17T20:05:47Z

⌛ Trying commit a96f3b2 with merge 4605628...

[WIP] Use `Into::into` in operator `?` #38751 proposes using `into` for `?`, and while commenters suggested problems with inference, I couldn't find any evidence where this was actually attempted -- so here we go!

estebank · 2019-05-17T19:39:14Z

src/libcore/tests/result.rs

@@ -198,7 +198,7 @@ pub fn test_unwrap_or_default() {
 #[test]
 fn test_try() {
    fn try_result_some() -> Option<u8> {
-        let val = Ok(1)?;
+        let val = Ok::<_, NoneError>(1)?;


This is a huge ergonomic regression 😟

Personally I'm not too bothered by this as Ok(1)? instead of Some(1)? is a silly thing to do; I don't know why Ok(1)? works in the first place...

I guess inference can tell that the only possible From for NoneError is the blanket identity impl<T> From<T> for T, versus now inferring some T: Into<NoneError>.

bors · 2019-05-17T21:57:16Z

💔 Test failed - checks-travis

rust-highfive · 2019-05-17T21:57:17Z

The job dist-x86_64-linux of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_fold:end:services

travis_fold:start:git.checkout
travis_time:start:0e1ddec8
$ git clone --depth=2 --branch=try https://github.com/rust-lang/rust.git rust-lang/rust
---
[01:45:07]    Compiling strsim v0.7.0
[01:45:08]    Compiling hex v0.3.2
[01:45:08]    Compiling ansi_term v0.11.0
[01:45:08] error[E0282]: type annotations needed
[01:45:08]   --> /cargo/registry/src/git.luolix.top-1ecc6299db9ec823/ansi_term-0.11.0/src/ansi.rs:30:39
[01:45:08]    |
[01:45:08] 29 |             let mut write_char = |c| {

[01:45:08]    |                 -------------- consider giving `write_char` a type
[01:45:08] 30 |                 if written_anything { write!(f, ";")?; }
[01:45:08]    |                                       ^^^^^^^^^^^^^^^
[01:45:08]    |                                       |
[01:45:08]    |                                       cannot infer type
[01:45:08]    |                                       cannot infer type
[01:45:08]    |                                       in this expansion of `desugaring of `?``
[01:45:08] 
[01:45:08] error: aborting due to previous error
[01:45:08] 
[01:45:08] For more information about this error, try `rustc --explain E0282`.
[01:45:08] For more information about this error, try `rustc --explain E0282`.
[01:45:08] error: Could not compile `ansi_term`.
[01:45:10] error: build failed
[01:45:10] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--manifest-path" "/checkout/src/tools/cargo/Cargo.toml" "--features" "rustc-workspace-hack/all-static" "--message-format" "json"
[01:45:10] expected success, got: exit code: 101
[01:45:10] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap dist --host x86_64-unknown-linux-gnu --target x86_64-unknown-linux-gnu
---
travis_time:end:00e5df01:start=1558129959406603950,finish=1558129959431110558,duration=24506608
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:11588250
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:18753af9
travis_time:start:18753af9
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0e41aa2a
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

cuviper · 2019-05-17T22:02:02Z

Yeah... I'm thinking this won't go anywhere unless we can improve inference.

If that's feasible, I'm willing to explore it, but I could use some pointers.

bors · 2019-05-19T04:51:49Z

☔ The latest upstream changes (presumably #60949) made this pull request unmergeable. Please resolve the merge conflicts.

jonas-schievink · 2019-06-18T15:51:23Z

Triage: Should we just close this? The required inference changes would probably need to be discussed by T-compiler outside of this issue, and might even need an RFC (it doesn't seem clear how these changes would even look like).

Centril · 2019-06-18T20:41:51Z

I would be interested in cratering this PR to see what the fuller outcome is.

JohnCSimon · 2019-07-20T01:08:43Z

Ping from triage @cuviper This PR looks like conflicts just need to be resolved.

cuviper · 2019-07-22T17:03:36Z

Triage: Should we just close this?

Yeah, that's fine. At least now we have rough experimental data for #38751.

cuviper added 3 commits May 13, 2019 12:12

Use Into::into in operator ?

4c44226

Fix new ? inference errors in librustc

002cfdb

Fix new ? inference errors in librustc_mir

6968e77

rust-highfive assigned varkor May 13, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 13, 2019

Centril added T-lang Relevant to the language team, which will review and decide on the PR/issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. labels May 13, 2019

This comment has been minimized.

Sign in to view

cuviper added 2 commits May 13, 2019 15:20

Use never_type in librustc_metadata to fix Into<!>

ea5bc7a

Fix new ? inference errors in librustc_driver

3615780

ui: bless try Into changes

c50bee0

This comment has been minimized.

Sign in to view

Annotate the type in core::tests::result::test_try

a96f3b2

cuviper added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 14, 2019

cuviper mentioned this pull request May 17, 2019

Explain that ? converts the error type using From #60924

Merged

estebank reviewed May 17, 2019

View reviewed changes

bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label May 17, 2019

cuviper closed this Jul 22, 2019

cuviper mentioned this pull request Jul 22, 2019

can the ? operator use into rather than from? #38751

Closed

RustyYato mentioned this pull request Apr 25, 2020

Tracking issue for ? operator and try blocks (RFC 243, question_mark & try_blocks features) #31436

Open

12 tasks

memoryruins mentioned this pull request May 17, 2023

std incorrectly states that ? uses Into on the underlying error type #111655

Closed

waynr mentioned this pull request Oct 18, 2023

? can not use assiciated type constraints usable by .into() #55984

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Use `Into::into` in operator `?` #60796

[WIP] Use `Into::into` in operator `?` #60796

cuviper commented May 13, 2019

rust-highfive commented May 13, 2019

cuviper commented May 13, 2019

This comment has been minimized.

cuviper commented May 13, 2019

This comment has been minimized.

cuviper commented May 14, 2019

Centril commented May 14, 2019

Centril commented May 17, 2019

bors commented May 17, 2019

estebank May 17, 2019

Centril May 18, 2019

cuviper May 18, 2019

bors commented May 17, 2019

rust-highfive commented May 17, 2019

cuviper commented May 17, 2019

bors commented May 19, 2019

jonas-schievink commented Jun 18, 2019

Centril commented Jun 18, 2019

JohnCSimon commented Jul 20, 2019

cuviper commented Jul 22, 2019

[WIP] Use Into::into in operator ? #60796

[WIP] Use Into::into in operator ? #60796

Conversation

cuviper commented May 13, 2019

rust-highfive commented May 13, 2019

cuviper commented May 13, 2019

This comment has been minimized.

cuviper commented May 13, 2019

This comment has been minimized.

cuviper commented May 14, 2019

Centril commented May 14, 2019

Centril commented May 17, 2019

bors commented May 17, 2019

estebank May 17, 2019

Choose a reason for hiding this comment

Centril May 18, 2019

Choose a reason for hiding this comment

cuviper May 18, 2019

Choose a reason for hiding this comment

bors commented May 17, 2019

rust-highfive commented May 17, 2019

cuviper commented May 17, 2019

bors commented May 19, 2019

jonas-schievink commented Jun 18, 2019

Centril commented Jun 18, 2019

JohnCSimon commented Jul 20, 2019

cuviper commented Jul 22, 2019

[WIP] Use `Into::into` in operator `?` #60796

[WIP] Use `Into::into` in operator `?` #60796