Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize `!` in Rust 1.41.0 #65355

Merged
merged 5 commits into from Nov 21, 2019

Conversation

@Centril
Copy link
Member

Centril commented Oct 13, 2019

This PR stabilizes the never_type (written !). The type represents computations that we know diverge in the type system and therefore has no values / inhabitants / elements / members.

The current nightly version is 1.40.0 which will become stable on 2019-12-19.

Tracking issue: #35121.
Closes #57012.
Closes #58184.
Original stabilization report: #57012 (comment)

Additional notes:

  • In #62661 we reserved impl<T> From<!> for T so this concern should be resolved.
  • The type inference fallback change is moved to #![feature(never_type_fallback)] (#65992).
  • You can find all of the tests referencing never_type in this PR which also reorganizes these tests whereas they were more scattered before.

r? @nikomatsakis

@Centril

This comment has been minimized.

Copy link
Member Author

Centril commented Oct 13, 2019

Dear language team and the community at large.
Hereby, I propose (which is the fourth time around for us) that we do stabilize never_type.

@rfcbot merge

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Oct 13, 2019

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rust-highfive

This comment was marked as outdated.

Copy link
Collaborator

rust-highfive commented Oct 13, 2019

The job x86_64-gnu-llvm-6.0 of your PR failed (pretty log, 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.
2019-10-13T03:13:00.4426675Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-10-13T03:13:00.4508641Z ##[command]git config gc.auto 0
2019-10-13T03:13:00.4584844Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-10-13T03:13:00.4649414Z ##[command]git config --get-all http.proxy
2019-10-13T03:13:00.4808132Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/65355/merge:refs/remotes/pull/65355/merge
---
2019-10-13T04:14:06.4179008Z .................................................................................................... 1600/9170
2019-10-13T04:14:13.5286137Z .................................................................................................... 1700/9170
2019-10-13T04:14:26.0382248Z ....................i...............i............................................................... 1800/9170
2019-10-13T04:14:33.6010758Z .................................................................................................... 1900/9170
2019-10-13T04:14:49.1721332Z ..........iiiii..................................................................................... 2000/9170
2019-10-13T04:14:59.2897568Z .................................................................................................... 2200/9170
2019-10-13T04:15:01.9927800Z .................................................................................................... 2300/9170
2019-10-13T04:15:07.9101691Z .................................................................................................... 2400/9170
2019-10-13T04:15:30.2623801Z .................................................................................................... 2500/9170
---
2019-10-13T04:18:35.0837605Z ..........i...............i......................................................................... 4800/9170
2019-10-13T04:18:46.7265147Z .................................................................................................... 4900/9170
2019-10-13T04:18:53.3428747Z .................................................................................................... 5000/9170
2019-10-13T04:19:04.6110586Z .................................................................................................... 5100/9170
2019-10-13T04:19:10.6502483Z ..........ii.ii..................................................................................... 5200/9170
2019-10-13T04:19:22.0790238Z .................................................................................................... 5400/9170
2019-10-13T04:19:32.8684493Z ............................................................................i....................... 5500/9170
2019-10-13T04:19:40.8980459Z .................................................................................................... 5600/9170
2019-10-13T04:19:47.2392674Z .................................................................................................... 5700/9170
2019-10-13T04:19:47.2392674Z .................................................................................................... 5700/9170
2019-10-13T04:19:58.6347488Z .........................................................................ii...i..ii...........i..... 5800/9170
2019-10-13T04:20:25.3537647Z .................................................................................................... 6000/9170
2019-10-13T04:20:35.5667238Z .................................................................................................... 6100/9170
2019-10-13T04:20:35.5667238Z .................................................................................................... 6100/9170
2019-10-13T04:20:44.7317922Z .........................................................................................i..ii...... 6200/9170
2019-10-13T04:21:15.1454621Z .................................................................................................... 6400/9170
2019-10-13T04:21:19.3977176Z ................................................i................................................... 6500/9170
2019-10-13T04:21:21.6381067Z .................................................................................................... 6600/9170
2019-10-13T04:21:24.1745734Z .....................i.............................................................................. 6700/9170
---
2019-10-13T04:26:11.7624314Z  finished in 5.672
2019-10-13T04:26:11.7811177Z Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2019-10-13T04:26:11.9473816Z 
2019-10-13T04:26:11.9473947Z running 153 tests
2019-10-13T04:26:15.3298008Z i....iii......iii..iiii....i.............................i..i..................i....i............ii. 100/153
2019-10-13T04:26:17.3617714Z i.i..iiii..............i.........iii.i.......ii......
2019-10-13T04:26:17.3619198Z 
2019-10-13T04:26:17.3625079Z  finished in 5.581
2019-10-13T04:26:17.3804669Z Check compiletest suite=codegen-units mode=codegen-units (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2019-10-13T04:26:17.5459699Z 
---
2019-10-13T04:26:19.7321250Z  finished in 2.350
2019-10-13T04:26:19.7505179Z Check compiletest suite=assembly mode=assembly (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2019-10-13T04:26:19.9149814Z 
2019-10-13T04:26:19.9150759Z running 9 tests
2019-10-13T04:26:19.9570585Z iiiiiiiii
2019-10-13T04:26:19.9627579Z 
2019-10-13T04:26:19.9628174Z  finished in 0.161
2019-10-13T04:26:19.9628814Z Check compiletest suite=incremental mode=incremental (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2019-10-13T04:26:20.1015146Z 
---
2019-10-13T04:26:38.9323874Z  finished in 19.001
2019-10-13T04:26:38.9519315Z Check compiletest suite=debuginfo mode=debuginfo-gdb+lldb (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2019-10-13T04:26:39.1171130Z 
2019-10-13T04:26:39.1171895Z running 123 tests
2019-10-13T04:27:04.6459449Z .iiiii...i.....i..i...i..i.i.i..i.ii..i.i.....i..i....ii..........iiii..........i...ii...i.......ii. 100/123
2019-10-13T04:27:09.5405896Z i.i.i......iii.i.....ii
2019-10-13T04:27:09.5407594Z 
2019-10-13T04:27:09.5407831Z  finished in 30.588
2019-10-13T04:27:09.5421388Z Uplifting stage1 rustc (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2019-10-13T04:27:09.5421984Z Copying stage2 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
---
2019-10-13T04:40:30.4244864Z 
2019-10-13T04:40:30.4245838Z    Doc-tests core
2019-10-13T04:40:35.6350642Z 
2019-10-13T04:40:35.6352086Z running 2403 tests
2019-10-13T04:40:47.4712479Z ......iiiii......................................................................................... 100/2403
2019-10-13T04:41:12.3052341Z ...................................................................................................i 300/2403
2019-10-13T04:41:26.2230499Z .................................................................................................... 400/2403
2019-10-13T04:41:26.2230499Z .................................................................................................... 400/2403
2019-10-13T04:41:37.4243834Z ..............................................i..i.................iiii............................. 500/2403
2019-10-13T04:41:59.1920078Z .................................................................................................... 700/2403
2019-10-13T04:42:10.3613817Z .................................................................................................... 800/2403
2019-10-13T04:42:21.3705023Z .................................................................................................... 900/2403
2019-10-13T04:42:32.5757776Z .................................................................................................... 1000/2403
---
2019-10-13T04:46:40.9971741Z ............................................... 300/763
2019-10-13T04:46:40.9996806Z thread '<unnamed>' panicked at 'explicit panic', src/libstd/io/stdio.rs:854:13
2019-10-13T04:46:41.1007912Z .................................................................................................... 400/763
2019-10-13T04:46:43.1695229Z .................................................................................................... 500/763
2019-10-13T04:46:43.1977811Z ....................thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:1165:5
2019-10-13T04:46:43.2001998Z ....thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:1165:5
2019-10-13T04:46:43.2017173Z .thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:1165:5
2019-10-13T04:46:43.2040318Z ......thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:1165:5
2019-10-13T04:46:43.4597330Z ............................................thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:1165:5
2019-10-13T04:46:43.4613243Z ...thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:1165:5
2019-10-13T04:46:43.4630343Z ..thread '<unnamed>' panicked at '.called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:1165:5
2019-10-13T04:46:43.4646736Z ....thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: RecvError', src/libcore/result.rs:1165:5
2019-10-13T04:46:45.5294513Z ......................thread '<unnamed>' panicked at 'explicit panic', src/libstd/sync/mutex.rs:629:13
2019-10-13T04:46:45.5305214Z ..thread '<unnamed>' panicked at 'test panic in inner thread to poison mutex', src/libstd/sync/mutex.rs:584:13
2019-10-13T04:46:45.5324123Z ...thread '<unnamed>' panicked at 'test panic in inner thread to poison mutex', src/libstd/sync/mutex.rs:561:13
2019-10-13T04:46:45.5336264Z .thread '<unnamed>' panicked at 'explicit panic', src/libstd/sync/mutex.rs:689:13
---
2019-10-13T04:46:54.8929032Z 
2019-10-13T04:46:54.8930559Z running 994 tests
2019-10-13T04:47:17.8059561Z i................................................................................................... 100/994
2019-10-13T04:47:30.4096365Z .................................................................................................... 200/994
2019-10-13T04:47:39.3976504Z ...................iii......i......i...i......i..................................................... 300/994
2019-10-13T04:47:45.4715311Z .................................................................................................... 400/994
2019-10-13T04:47:53.9518276Z .....................................i..i.................................ii........................ 500/994
2019-10-13T04:48:09.8863884Z .................................................................................................... 700/994
2019-10-13T04:48:09.8863884Z .................................................................................................... 700/994
2019-10-13T04:48:18.6082476Z ....................iiii............................................................................ 800/994
2019-10-13T04:48:34.7064011Z .................................................................................................... 900/994
2019-10-13T04:48:42.9202638Z ..........................................iiii................................................
2019-10-13T04:48:42.9206605Z 
2019-10-13T04:48:42.9251989Z  finished in 202.282
2019-10-13T04:48:42.9269421Z Testing term stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2019-10-13T04:48:43.1469536Z    Compiling term v0.0.0 (/checkout/src/libterm)
---
2019-10-13T05:04:15.3672928Z Rustbook (x86_64-unknown-linux-gnu) - edition-guide
2019-10-13T05:04:15.7360416Z Building stage0 tool linkchecker (x86_64-unknown-linux-gnu)
2019-10-13T05:04:15.9041817Z    Compiling linkchecker v0.1.0 (/checkout/src/tools/linkchecker)
2019-10-13T05:04:18.0840236Z     Finished release [optimized] target(s) in 2.34s
2019-10-13T05:04:18.9843902Z std/convert/trait.TryFrom.html:22: broken link - std/convert/enum.Infallible.html
2019-10-13T05:04:18.9845224Z std/convert/trait.TryFrom.html:23: broken link - std/convert/enum.Infallible.html
2019-10-13T05:04:21.8448674Z core/convert/trait.TryFrom.html:22: broken link - core/convert/enum.Infallible.html
2019-10-13T05:04:21.8449942Z core/convert/trait.TryFrom.html:23: broken link - core/convert/enum.Infallible.html
2019-10-13T05:04:26.6786459Z thread 'main' panicked at 'found some broken links', src/tools/linkchecker/main.rs:41:9
2019-10-13T05:04:26.6806036Z 
2019-10-13T05:04:26.6806999Z 
2019-10-13T05:04:26.6808205Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/linkchecker" "/checkout/obj/build/x86_64-unknown-linux-gnu/doc"
2019-10-13T05:04:26.6808623Z expected success, got: exit code: 101
---
2019-10-13T05:04:26.6872029Z == clock drift check ==
2019-10-13T05:04:26.6900778Z   local time: Sun Oct 13 05:04:26 UTC 2019
2019-10-13T05:04:26.9689232Z   network time: Sun, 13 Oct 2019 05:04:26 GMT
2019-10-13T05:04:26.9690217Z == end clock drift check ==
2019-10-13T05:04:28.3184217Z ##[error]Bash exited with code '1'.
2019-10-13T05:04:28.3230742Z ##[section]Starting: Checkout
2019-10-13T05:04:28.3233229Z ==============================================================================
2019-10-13T05:04:28.3233285Z Task         : Get sources
2019-10-13T05:04:28.3233334Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

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)

@Centril Centril force-pushed the Centril:almost-is-never-enough branch from d7992cb to 48604a6 Oct 13, 2019
@Centril Centril added the I-nominated label Oct 13, 2019
@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Oct 14, 2019

Centril. In #57012 (comment) you cancelled an existing FCP for this exact same proposal and replaced it with this one, with no explanation. I have trouble thinking of a legitimate reason to do this. The only effective differences are teams and concerns.

You chose to only include T-lang in this FCP, whereas the previous FCP had both T-lang and T-libs. (This is despite having a “Redefine core::convert::Infallible as !” commit in this PR. The libs team has previously discussed this very change as desirable but potentially causing breakage.)

You get a blank slate in terms of registered blocking concerns, which the previous FCP had two remaining: #57012 (comment)

  • indirect-coherence-breakage seems to be fixed by #62661

  • You do not even attempt to address or even discuss my fallback concern. You only mention unspecific “previous language team consensus” in passing. As far as I know, such consensus happened before the concern was formally raised or the underlying issue was known.

Because I happen to be in T-libs and not T-lang, I currently cannot formally register this concern again. I cannot imagine this is a coincidence rather than blatant abuse of the FCP process to force through your preferred outcome.


To reiterate the concern:

The proposed fallback change introduces Undefined Behavior in some previously-valid stable unsafe code. The affected code pattern was found to be common among users of a popular crate (https://crates.io/crates/objc).

This change was previously in Nightly, and got reverted (#50121) after we found miscompilations: #48950 (comment), #48950 (comment). Nothing on the Rust side has changed since on this front.

Given that stability is one of the main goals of the Rust project, I feel it is not acceptable to silently change language semantics from under the feet of crate maintainers and introduce UB without having something to help them find out if they’re affected.

Finally, the fallback change is not necessary to stabilize the never type. (It’s the other way around.) The two do not have to be bundled together.

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Oct 14, 2019

@rfcbot concern fallback

Thanks for raising this issue Simon. Because of your comment, I've taken a closer look at the fallback issue; previously I had been sitting out of this and letting other contributors handle it. I had not understood the extent of the breakage it introduced until now. This seems like a very egregiously breaking change to me:

  • This breakage causes undefined behavior in user code, not just a compilation error.
  • This breakage has known examples which crater could not catch because they were in platform specific code.
  • It would be unreasonable, in my opinion, to claim that the current fallback behavior was unspecified in a way that unsafe code could not rely on.
  • This breakage is not strictly necessary to unblock the most important component of this change (stabilizing !).

Previously, not following closely, I had understood the fallback issue to only be a matter of introducing type errors. But this is a much more serious breakage than that, and I don't think there has been enough work in proposing a plan to communicate this breakage and help the community prevent introducing UB as a result of this change.

I'm personally still in favor of merging the proposal in #58184 as soon as possible. It does not seem appropriate to me to block #58184 while doing nothing to resolve the very valid concerns that have been blocking a more extensive stabilization.

@Centril

This comment has been minimized.

Copy link
Member Author

Centril commented Oct 14, 2019

(This is despite having a “Redefine core::convert::Infallible as !” commit in this PR. The libs team has previously discussed this very change as desirable but potentially causing breakage.)

I believe the libs team has already decided that Infallible should be redefined as ! but if you insist that enum Infallible {} should remain the definition, then I will remove that commit.

Because I happen to be in T-libs and not T-lang, I currently cannot formally register this concern again. I cannot imagine this is a coincidence rather than blatant abuse of the FCP process to force through your preferred outcome.

It's definitely not a coincidence not including T-libs but it's definitely also not an abuse of the FCP process not to include a team that isn't supposed to make decisions about how the type system behaves. You can always make your case as a community member and as you've seen parts of the language team seems to have agreed with you.

It would be unreasonable, in my opinion, to claim that the current fallback behavior was unspecified in a way that unsafe code could not rely on.

I think RFC 1122 clearly suggests otherwise.


The following comments include the discussion re. the fallback change:

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Oct 14, 2019

Whether or not T-libs should be part of this decision, I still see no reason to cancel that FCP and start a new one except trying to sweep a registered concern under the rug without addressing it.


Thank you for taking the time to find links to relevant comments. There was indeed a lot of discussion, but I don’t see in it the team reaching any consensus.

In fact, much of the discussion revolved around a lint that was meant to catch some regressions known at the time to be caused by the fallback change. But it became apparent later that miscompilations in users of the objc crate were an entirely different category of regression, not caught by that lint.

To reiterate my position:

  • I am not arguing that ! is not a better fallback than () for new code

  • I am not arguing that we should not make this change at all, or that that RFC 1122 does not allow making it at all

  • I am requesting the fallback change be blocked on:

    • Some tooling (whether a rustc lint or something else) to help maintainers figure out whether they or their dependencies are affected by a soundness regression in the same category as some uses of the objc crate
      • (Note that a warning is not enough since Cargo silences them in dependencies by default.)
    • Communication from the Rust project about this tooling and change
    • Some transition period after having the tool available and announced and before making the change in Nightly. (When this was first in Nightly I spent a couple days in a debugger before figuring out what was going on.)

    I feel that this request is supported by RFC 1122:

    Changes that alter dynamic semantics versus typing rules

    In some cases, fixing a bug may not cause crates to stop compiling, but rather will cause them to silently start doing something different than they were doing before. In cases like these, the same principle of using mitigation measures to lessen the impact (and ease the transition) applies, but the precise strategy to be used will have to be worked out on a more case-by-case basis. This is particularly relevant to the underspecified areas of the language described in the next section.

  • I am noting that the never type does not require the fallback change, and suggesting (#58184) that it be stabilized separately without blocking unnecessarily.

@Centril

This comment has been minimized.

Copy link
Member Author

Centril commented Oct 14, 2019

@SimonSapin

  • Some tooling (whether a rustc lint or something else) to help maintainers figure out whether they or their dependencies are affected by a soundness regression in the same category as some uses of the objc crate

    • (Note that a warning is not enough since Cargo silences them in dependencies by default.)
  • Communication from the Rust project about this tooling and change

  • Some transition period after having the tool available and announced and before making the change in Nightly. (When this was first in Nightly I spent a couple days in a debugger before figuring out what was going on.)

I'm fine with all of these points but I'm not personally going to invest my own time in the non-trivial effort that this will require (especially doing all of them).

  • I am noting that the never type does not require the fallback change, and suggesting (#58184) that it be stabilized separately without blocking unnecessarily.

Me and @cramertj have previously noted that we disagree with this because we think the inference fallback change will simply then not happen (if for no other reason than the substantial effort required due to the requirements you've set up). I also believe that one of the core motivations for stabilizing ! is language consistency and the benefits that the fallback change brings. I don't think it's sufficiently motivated to stabilize the type without the fallback change.

Meanwhile I will split out some of the categorization work done in this PR to another one so it doesn't bit-rot.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Oct 14, 2019

I do realize that these mitigations would require significant effort, and I’m also not volunteering. I still feel that this is the bar to meet when making unsound a category of programs that are currently valid and sound on the Stable channel.

As to the risk of the change not happening because no-one is willing to spend that effort, wouldn’t that be a sign that no-one feels that it’s important enough?

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Oct 14, 2019

@SimonSapin

The breakage to objc as a result of the fallback change is concerning, and I appreciate that you're working to hold us to our backwards compatibility commitments, as well as to ensure that real-world users don't suffer as a result of this change to what is ultimately a rather niche corner of the language. You're requesting that we do something better than "just change it", and I agree that having the kinds of migration tooling you suggest in #65355 (comment) would allow us to make this transition more confidently.

However, it is not currently a high enough priority for me to personally invest the time to implement the tooling. It isn't a blocker to any of my work, and I don't see it becoming one. I don't feel like the issues caused by this fallback change are more widespread nor more interesting than other kinds of inference changes that we've successfully made in the past. I do believe, however, that fallback to ! will ultimately result in a better language and better user experience, and I believe the cost that we're paying now with this transition is the correct tradeoff to deliver a better language.

I feel like your position on this issue is valid and reasonable, and I feel like you've already had to go to quite the lengths to keep it in our minds (how many issues have we had for stabilizing never_type now? it must be a half dozen at least). I haven't seen any new arguments being made across these issues, so I think the right step now is for the lang team to meet and make a decision on this issue. It sounds like from @withoutboats's comment above that they agree with your concerns, and I think that everyone on the language team understands the issues you've raised. I feel like a decision made amongst the lang team is going to be one that takes all perspectives into account, and that continuing to debate this topic across various GH threads is unproductive at this point. Do you agree, or are there other steps you'd like to see us take to make sure that we've understood your perspective?

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Oct 14, 2019

I would like to give my position:

First of all, we had discussed in several lang team meetings whether this question of fallback was ultimately a lang team or libs team call. Ultimately, I believe it is pretty squarely a lang team decision, though one where I think libs team feedback is important and welcome.

We had talked some time ago about whether it would make sense to cancel the FCP and re-label the issue with T-lang, so as to clarify which team was responsible for deciding this particular aspect, though I don't believe we ever had a firm place to do so. From a purely technical POV, I think such a move is fine. However, I wouldn't have wanted it to come as a surprise, and I would've preferred to approach the problem via discussion first. In my role as lang team lead, I apologize for that, @SimonSapin.

As for the merits of the concern itself, I am glad that boats recreated the concern, as I didn't feel like we had personally concluded this. I could imagine that in lang team meetings, though, I didn't make that fully clear; I'll admit I was somewhat relying on Simon's concern to "hold the place" for my own misgivings. I still think it's not clear we can "get away" with this change, for the reasons previously enumerated. (Recently, I've been wondering if we ought to consider it for an edition boundary.)

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Oct 14, 2019

As for the merits of the concern itself, I am glad that boats recreated the concern, as I didn't feel like we had personally concluded this

To clarify this: What I had in mind here is mostly to prepare a summary document, which includes the pros and cons, and discuss that in a meeting. The same as any other concern, ultimately. I do think we have to reach some kind of final decision here and we can't hold off forever on doing so (as we've been doing).

One more clarification: I don't really think it's unreasonable of @Centril to feel that there was a consensus amongst the lang team. I think the situation was somewhat ambiguous myself, which is an interesting procedural point. (I'd like it if we made it more clear when "resloving" concerns in a final way.)

@mark-i-m

This comment has been minimized.

Copy link
Member

mark-i-m commented Oct 14, 2019

I do believe, however, that fallback to ! will ultimately result in a better language and better user experience, and I believe the cost that we're paying now with this transition is the correct tradeoff to deliver a better language

Just as a casual observer, it seems that the difficulty of the decision stems from the extremes here: it would be really good to make the fallback work, as that would unlock a lot of great optimizations and APIs, but it would be really bad to cause UB in stable programs, which would greatly undermine rust's safety guarantee (not just its stability guarantees).

Recently, I've been wondering if we ought to consider it for an edition boundary.

NLL seems to set a precedence for this.

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Oct 14, 2019

which would greatly undermine rust's safety guarantee (not just its stability guarantees).

To clarify, the only undefined behavior resulting from this change is in unsafe code that was making assumptions about what type variables would fall back to. AFAIK this is not something we previously documented before, but was admittedly clearly observable.

NLL seems to set a precedence for this.

NLL is going to be the only option in the 2015 edition as well as the 2018 edition, and the old borrowchecker is being removed. The edition provided a convenient mechanism for testing out NLL and MIR borrowchecking on new or actively-maintained code, but it was never the plan to keep around the old borrowchecker permanently.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Oct 14, 2019

I don't feel like the issues caused by this fallback change are more widespread nor more interesting than other kinds of inference changes that we've successfully made in the past.

Did those other changes silently introduce UB in previously-sound programs? I feel this is an entirely different category of change, compared to making some programs fail to compile until they add a type annotation.

To clarify, the only undefined behavior resulting from this change is in unsafe code that was making assumptions about what type variables would fall back to.

For what it’s worth this assumption was never made knowingly. The unsafe code is in a library (objc), and only some (mis)uses of that library are affected. The library even documents unambiguous use. (let () = send_msg!(…); instead of send_msg!(…);)

I've been wondering if we ought to consider it for an edition boundary.

I proposed that. #57012 (comment) claims it would be impractical.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Oct 14, 2019

First of all, we had discussed in several lang team meetings whether this question of fallback was ultimately a lang team or libs team call. Ultimately, I believe it is pretty squarely a lang team decision, though one where I think libs team feedback is important and welcome.

This sounds totally reasonable. And maybe the outcome will be that the lang team collectively decides to make the change without mitigation.

What I find unacceptable is one team member unilaterally resetting a decision-making tool, pretending that a concern discussed at length does not exist, and claiming team consensus that as far as I can tell doesn’t exist.

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Oct 14, 2019

claiming team consensus that as far as I can tell doesn’t exist.

FWIW, my perception (prior to reading @withoutboats's comment above) was also that the lang team was unified on this issue. I agree with your other points, though-- the fallback concern is certainly important to address. I don't want to view this new FCP as an opportunity to forget about the fallback issue.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Oct 14, 2019

Can I ask what this perception was based on? A few team members arguing one way in a comment thread while others do not comment on that particular topic is not team consensus IMO.

If a decision was made in a synchronous meeting, there should be some communication about it.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Oct 14, 2019

As I wrote earlier, I think that lang team consensus was in an "ambiguous" state. We definitely had meetings where we expressed a desire to make this change. Clearly some of us (e.g., @withoutboats) had not deeply engaged on the issue. I know that I personally harbored some doubts though I don't think I fully expressed them, in part because (as I wrote) I was relying on the existing concern to carry them for the moment. The end result is that I could easily see where one would feel that consensus was reached.

I have been wanting to move us to a procedure where whenever contentious questions arise (whether they be from a lang team member or not), we prepare a kind of "document" where we summarize the pros/cons and so forth. This document can also record the resulting consensus, and include a spot for "dissents" -- i.e., a space for lang team members (or other major stakeholders) to document their reasons for disagreeing with the consensus (note that disagreeing with the consensus doesn't mean that one blocks the final decision).

One advantage of this process is that it records the pros/cons for posterity, and provides a document for people to point to later to avoid repeated debate. But I see now it might also have the side-effect of helping us to clarify when a decision has been reached, and what the considerations were at the time.

In any case, ignoring the procedural hiccups here, I think that preparing such a document is the right way forward in this particular case as well. I would be happy to help in preparing such a document.

@Centril Centril force-pushed the Centril:almost-is-never-enough branch from 2379e7b to 238d03b Nov 21, 2019
@oli-obk

This comment has been minimized.

Copy link
Contributor

oli-obk commented Nov 21, 2019

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 21, 2019

📌 Commit 238d03b has been approved by oli-obk

Centril added a commit to Centril/rust that referenced this pull request Nov 21, 2019
…li-obk

Stabilize `!` in Rust 1.41.0

This PR stabilizes the `never_type` (written `!`). The type represents computations that we know diverge in the type system and therefore has no values / inhabitants / elements / members.

The current nightly version is 1.40.0 which will become stable on 2019-12-19.

Tracking issue: rust-lang#35121.
Closes rust-lang#57012.
Closes rust-lang#58184.
Original stabilization report: rust-lang#57012 (comment)

Additional notes:

- In rust-lang#62661 we reserved `impl<T> From<!> for T` so this concern should be resolved.
- The type inference fallback change is moved to `#![feature(never_type_fallback)]` (rust-lang#65992).
- You can find all of the tests referencing `never_type` in this PR which also reorganizes these tests whereas they were more scattered before.

r? @nikomatsakis
bors added a commit that referenced this pull request Nov 21, 2019
Rollup of 5 pull requests

Successful merges:

 - #65355 (Stabilize `!` in Rust 1.41.0)
 - #65730 (Suggest to add lifetime constraint at explicit ouput of functions)
 - #66468 (Cleanup Miri SIMD intrinsics)
 - #66515 (Reduce size of `hir::Expr` by boxing more of `hir::InlineAsm`)
 - #66602 (Revert "Update Source Code Pro and include italics")

Failed merges:

r? @ghost
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 21, 2019

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

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Nov 21, 2019

⌛️ Testing commit 238d03b with merge 35ef33a...

@bors bors merged commit 238d03b into rust-lang:master Nov 21, 2019
4 of 5 checks passed
4 of 5 checks passed
homu Testing commit 238d03b3a32e7415becbcf22748286880ce21e3f with merge 35ef33a89dfd8ff8c8a7b3c58fa7136bbcb2f1ed...
Details
pr #20191121.18 succeeded
Details
pr (Linux mingw-check) Linux mingw-check succeeded
Details
pr (Linux x86_64-gnu-llvm-6.0) Linux x86_64-gnu-llvm-6.0 succeeded
Details
pr (Linux x86_64-gnu-tools) Linux x86_64-gnu-tools succeeded
Details
@Centril Centril deleted the Centril:almost-is-never-enough branch Nov 21, 2019
@Aaron1011

This comment has been minimized.

Copy link
Contributor

Aaron1011 commented Nov 21, 2019

I was starting to think that this would ! happen 😄

flip1995 added a commit to Manishearth/rust-clippy that referenced this pull request Nov 22, 2019
Stablized in rust-lang/rust#65355
flip1995 added a commit to Manishearth/rust-clippy that referenced this pull request Nov 22, 2019
Stablized in rust-lang/rust#65355
bors added a commit to rust-lang/rust-clippy that referenced this pull request Nov 23, 2019
Rustup to rustc 1.41.0-nightly (35ef33a8 2019-11-21)

I don't have the right fix for the fmtstr tests, and I'm also hitting problems caused by messense/rustc-test#3

List of rustups:
- rust-lang/rust#66271 (syntax: Keep string literals in ABIs and `asm!` more precisely)
- rust-lang/rust#65355 (Stabilize `!` in Rust 1.41.0)
- rust-lang/rust#66515 (Reduce size of `hir::Expr` by boxing more of `hir::InlineAsm`)
- rust-lang/rust#66389 (Specific labels when referring to "expected" and "found" types)
- rust-lang/rust#66074 ([mir-opt] Turn on the `ConstProp` pass by default)

changelog: none
bors added a commit to rust-lang/rust-clippy that referenced this pull request Nov 23, 2019
Rustup to rustc 1.41.0-nightly (35ef33a8 2019-11-21)

I don't have the right fix for the fmtstr tests, and I'm also hitting problems caused by messense/rustc-test#3

List of rustups:
- rust-lang/rust#66271 (syntax: Keep string literals in ABIs and `asm!` more precisely)
- rust-lang/rust#65355 (Stabilize `!` in Rust 1.41.0)
- rust-lang/rust#66515 (Reduce size of `hir::Expr` by boxing more of `hir::InlineAsm`)
- rust-lang/rust#66389 (Specific labels when referring to "expected" and "found" types)
- rust-lang/rust#66074 ([mir-opt] Turn on the `ConstProp` pass by default)

changelog: none
bors added a commit to rust-lang/rust-clippy that referenced this pull request Nov 23, 2019
Rustup to rustc 1.41.0-nightly (35ef33a8 2019-11-21)

I don't have the right fix for the fmtstr tests, and I'm also hitting problems caused by messense/rustc-test#3

List of rustups:
- rust-lang/rust#66271 (syntax: Keep string literals in ABIs and `asm!` more precisely)
- rust-lang/rust#65355 (Stabilize `!` in Rust 1.41.0)
- rust-lang/rust#66515 (Reduce size of `hir::Expr` by boxing more of `hir::InlineAsm`)
- rust-lang/rust#66389 (Specific labels when referring to "expected" and "found" types)
- rust-lang/rust#66074 ([mir-opt] Turn on the `ConstProp` pass by default)

changelog: none
@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Nov 25, 2019

I think this may be causing a regression perhaps? #66757

@comex

This comment has been minimized.

Copy link
Contributor

comex commented Nov 28, 2019

I’m only a bystander, but the fallback change seems to me like an “obvious” candidate to be edition-gated. It’s a small language change that doesn’t affect most code, but causes rather nasty breakage in the code it does affect. In that respect, it’s comparable to adding a new keyword, or to other 2018 edition changes. And the compiler is apparently already capable of selecting the old or new behavior on a crate-by-crate basis.

One downside of using an edition is that the next edition isn’t planned to happen for years, thanks to a desire for stability. But it seems like that may be motivating people to just go ahead and make the same breaking changes without an edition – which would be a perverse outcome.

@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Nov 28, 2019

I proposed this in #57012 (comment), see also the following comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.